How to write usability tasks without giving away the path

A usability test task serves as the starting point for an observation. If the statement names the button to be used, the researcher loses the chance to discover if the person would find that button. If essential information is missing, the test might measure the ability to guess the scenario.

Start with the user's goal

Imagine a meal subscription app. The team wants to evaluate the temporary pause of the service.

A statement like “click on Subscription, then on Pause” describes the solution. An alternative would be: “You are traveling next week and don't want to receive meals during that period. Adjust your subscription for this situation”.

The second text leaves the discovery of the path to the participant. But a piece of information might still be missing: when should delivery resume? Add fictitious dates when they are necessary to complete the task.

Separate scenario, task, and follow-up question

The scenario explains the situation. The task asks for the action. The follow-up question investigates the experience. Mixing the three in a long paragraph increases the chance of the person forgetting part of the instruction.

A possible structure for the example:

• Scenario: the person will be away from home between two dates.
• Task: adjust deliveries for this period.
• Follow-up question: explain what they expect to happen after the change.

The last question helps identify only apparent success. Someone might reach the expected screen and believe they have permanently canceled the service.

Write a success criterion for the researcher

The criterion doesn't need to appear in full in the statement. It serves to evaluate the attempt consistently.

In the example, success might mean suspending deliveries during the interval and maintaining subsequent resumption. Reaching the settings page would only be an intermediate step.

In UXTap prototype tests, it's possible to define goals by screen or by path. Check if the configuration represents the real objective. A rule that is too narrow might treat a valid path as an error; a rule that is too broad might count an incomplete attempt as success.

Review your usability tasks

Review menu names, labels, and internal expressions present in the text. Do not eliminate a natural word just because it also appears in the interface. The goal is to preserve how a person would describe their need.

Read aloud. If the text sounds like a training instruction, rewrite it. If it sounds like a guessing game, add context.

Also avoid adjectives that anticipate evaluation: “use the new and simple process” already suggests the expected answer. Describe the situation without praising or criticizing the product.

Prepare a pilot that can fail

Ask someone outside the project to perform the task. Do not immediately correct every attempt. Observe if the doubt comes from the statement, the interface, or missing data.

Also test the termination. In UXTap, visual tasks can offer abandonment according to the configuration. This exit should represent a terminated attempt, allowing investigation of the reason, without forcing the person to click until they get it right.

If the pilot requires additional explanations, incorporate the necessary information into the study and repeat the review.

Rewriting workshop: from command to scenario

Use a fictitious address update task to review your script. The first draft could be: “Go to My Account, choose Personal Data, and edit the address”. It gives away names and sequence. A person might obey without understanding where they would look for this feature on their own.

A second version, “update your data”, removes the clues but leaves a doubt: what data and for what reason? The person needs to invent a need. A more precise formulation would be: “You are moving before the next delivery. Prepare the service to receive the next order at the address provided for this test”. Provide a fictitious address in an easy-to-consult location.

The team must decide an additional question: does the change apply to the registration or to an already issued order? If the product has both features, clarify in the scenario what needs to happen with the next delivery. This information belongs to the objective; hiding this difference does not make the task more neutral, only ambiguous.

To review another statement, make three markings: words that describe the situation, information necessary to execute, and expressions that reveal navigation. Preserve the first two categories and examine the third. Ask someone unfamiliar with the screen to explain the objective in their own words.

Separate observation criteria from displayed text

The researcher's script can be more detailed than the participant's instruction. In the example, record that the task ends when the new address is associated with the intended delivery. Note valid alternative paths, intermediate states, and situations where the prototype does not allow continuation.

Prepare a follow-up question that clarifies the result: “Which address do you believe will be used for the next delivery?”. A visual confirmation might be interpreted differently than the team imagined. Reaching the expected screen and understanding the effect of the change are related, but distinct, observations.

Avoid inserting expressions like “the button is hidden” or “the process is simple” into the scenario. Also, do not ask why the person ignored an action before checking if they noticed it. Prefer to ask them to report what they were looking for and what they expected to happen. This preserves space for explanations different from the initial hypothesis.

Manage the sequence of tasks

One task can teach the solution for the next. Finding the settings to change the address might make it easier to locate the password change later. If you want to evaluate the initial discovery of both, consider separating the activities among participants or recording the order as a study condition.

When the dependency is intentional, maintain the necessary state. A task that asks to track an order only makes sense if that order exists in the scenario. Prevent a previous failure from hindering all subsequent observations; prepare an independent starting point when the research question allows.

In unmoderated tests, add instructions about fictitious data, completion, and material limits. These guidelines do not need to reveal paths. Their function is to prevent the participant from exposing real information or getting stuck due to a technical limitation. Review the execution along with the UX research plan.

Turn a task into a reusable pattern

Save the scenario, success criterion, and pilot observations. This makes it easier to repeat the research after a change without silently altering the difficulty.

Your next step is to choose an existing statement and remove navigation instructions from it. Add only the necessary data, check the goal in UXTap, and make a complete attempt. A well-written task opens space to observe choices the team doesn't yet know.

With the revised statement, follow the Figma testing guide and choose one of the UXTap prototype modes to observe the complete attempt.

Frequently asked questions about statements

Can I use a word that also appears in the menu?

Yes, when it is part of the natural language of the need. Do not replace “password” with a riddle just because there is a menu with that name. The problem is giving away the sequence or artificially choosing the interface vocabulary when the participant would use another description.

Does the task need to have only one solution?

No. An objective can be solved by different paths. Define which results truly meet the need and configure the study accordingly. If the research requires a specific sequence, describe this restriction in the analysis; it changes what you are evaluating.

Should I explain a task that the person didn't understand?

In the pilot, investigate the doubt to correct the text. In the main data collection, an additional explanation alters the condition of the attempt. Record the intervention if it occurs. In an unmoderated study, revise the statement before continuing data collection if incomprehension compromises the objective.

Create your UXTap account to prepare your first study.