Product planning
Ask beta users for feedback on a specific workflow
Ask what the person tried to do, what happened and what they did next. Tie the questions to one workflow and a particular attempt so you can trace the answer to a problem. A general opinion question may need follow-up before it explains what went wrong.
Workflow being studied: [ ] Build or version used: [ ] Participant (anonymous label): [ ] Date of attempt: [ ] Task attempted: [ ] Result: [ ] Where they got stuck: [ ] Workaround used: [ ] What they wanted to happen next: [ ] Did they finish the task: [yes / no / partly] Pattern across participants: [ ] Follow-up needed: [ ] Decision made and by whom: [ ]
Questions that cannot explain a problem
A satisfaction rating alone does not tell you what caused it. Follow a score or a short answer with a question about what happened. Connect the questions to something the participant tried, and label predictions about imagined features as guesses. Watch for leading wording, such as asking how much someone liked a step. Include people who stopped partway so incomplete attempts appear in your findings. Ask for the date of the attempt and the version if known; a date alone may not identify the build.
Review these beta questions. Mark any that ask for satisfaction or opinion without asking what happened. For each remaining question, name the concrete problem its answer could reveal. Flag leading wording and questions that ask users to imagine features.
Test the questions on one person first
Send the questions to one beta user or a colleague and check whether the answers reveal what happened. Reword any question that draws a vague reply. Decide in advance how you will group answers by task and obstacle. Plan how you will tell participants what happened with their feedback, and record any resulting change in your decision log.