To create a mission, you have to define the task, a description, and the expected path(s) inside the prototype or website.
- The task defines the user's goal
- The description gives a general instruction
- The expected path is the flow you want testers 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
Your testers won't be able to go back to the previous block and edit their answers/missions. For this reason, it's important that your prompts are very clear on what you expect testers to do.
To get the most accurate results, there are certain best practices to follow when drafting your mission tasks and descriptions.
Define an action in the task
The task should define the mission goal. Because a mission is an exercise that needs to be completed, the task usually describes an action to be taken by testers. Use verbs to give instructions, and avoid using adjectives.
Tasks should be kept as concise as possible. Anything that is a detail 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 testers 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 spliy 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 is clear and easy to understand.
Keep in mind your testers 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 are not familiar with Maze.
Avoid leading words
Avoid telling testers 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 scenarios as much as possible: in a live product, there are no detailed instructions on how to use your product.