Best practices for writing tasks and descriptions
Last updated: April 19, 2026
A mission is a task (i.e. a prototype or a website test) that your participants have to complete.
To create a mission, you have to define the task, a description, and the expected path(s) inside the prototype or website.
- Task: Defines the user’s goal.
- Description: Gives a general instruction or additional context.
- Expected path: The flow you want participants to go through. It serves as the benchmark against which success is measured. You can add as many paths as needed. Learn more about setting paths
Participants can’t go back to the previous block and edit their answers or redo their tasks. For this reason, it’s important that your prompts are very clear on what you expect participants to do.
To get the most accurate results, there are recommended best practices when drafting your mission tasks and descriptions.
Define an action in the task
The mission goal is defined in the task. Because a mission is an exercise that needs to be completed, the task usually describes an action to be taken by participants. Use verbs to give instructions, and avoid using adjectives.
Tasks should be kept as concise as possible. Anything that’s a detail or accessory should be included in the description instead.
Include additional information in the description
The mission description should give general instruction to the tester about the task they have to do.
Don’t overwhelm participants with a lot of information and details. If you find yourself writing more than 140–280 characters in your descriptions, check if you’re either giving too many details, or creating a mission that should be split into two or more different blocks.
Think of your description as a tweet—it gives a general purpose, without going into too much detail.
Write clearly and concisely
Use language that’s clear and easy to understand.
Keep in mind your participants when writing tasks—who they are, and how familiar they are with your product. Unless you’re testing your UI copy, avoid slang or internal jargon.
The first example would be unclear for people who aren’t familiar with Maze.
Avoid leading words
Avoid telling participants the exact steps they need to take to complete the mission. This will create biases and may severely influence your results.
Remember that you’re testing whether users will be able to use your product as it is. It’s vital to approximate real-life situations as much as possible—in a live product, there are no detailed instructions on how to use your product.