The prompt
Score 10 of 10, Excellent
Use it when You are testing a prototype or a live flow with users and need realistic tasks, neutral moderator wording and a note-taking sheet.
- {{prototype_description}}
- {{learning_goals}}
- {{participants}}
- {{session_length}}
- {{session_format}}
- {{moderator}}
Full prompt and why it works
System prompt
You help product teams plan usability tests. You write tasks that participants can attempt without being told how, and moderator wording that never leads them.
User message
<prototype> {{prototype_description}} </prototype> <test_plan> What we want to learn: {{learning_goals}} Participants: {{participants}} Session length: {{session_length}} Format (remote or in person, moderated or not): {{session_format}} </test_plan> Write a usability test script for the prototype above, for {{moderator}} to run sessions from and note-takers to fill in, so the team can see where people get stuck before we build further. Use these sections: 1. Introduction for the moderator to read aloud, under 120 words: thanks, we are testing the design and not the person, please think aloud, there are no wrong answers, consent to record. 2. Warm-up: 3 questions about how the participant does this kind of work today. 3. Tasks: 4 to 6, each with a realistic scenario the participant reads, the success criterion the moderator watches for (the screen or result they reach), a time limit, and 2 neutral follow-up prompts. 4. Wrap-up: 3 questions, including one 1-to-5 rating with a reason. 5. Note-taking sheet: a table with the columns Task, Completed (yes, with help, no), Time, Where they hesitated, Quotes. The whole session must fit in {{session_length}}. Tasks state a goal in the participant's words and never name the button, menu or label to use, because naming it tells them where to click. <example> Leading: "Use the Filters menu to find last month's invoices." Neutral: "Your manager asks how much you spent with your top supplier last month. Find that out." </example> Use follow-up prompts that are open, such as "What were you expecting there?", rather than ones that suggest an answer, like "Was that confusing?". Do not write tasks for screens the prototype description does not include. If a learning goal cannot be tested with this prototype, say so at the top rather than writing a task for it.
Variables
- {{prototype_description}}
- What the prototype covers: the screens or steps, what works and what is only a picture.
- {{learning_goals}}
- What you want to find out, for example "whether people find bulk edit and understand what it changes".
- {{participants}}
- Who you are testing with, for example "five office managers who order supplies monthly".
- {{session_length}}
- How long each session is, for example 45 minutes.
- {{session_format}}
- For example "remote, moderated, over video call".
- {{moderator}}
- Who runs the sessions, for example "our product designer".
Why it works
- An example. A leading task and a neutral one side by side show the difference the whole script depends on.
- What to avoid. Tasks never name the button or menu to use, because that turns a test of the design into a test of reading instructions.
- If unsure. Goals this prototype cannot answer are flagged at the top instead of padded out with tasks that test nothing.