Product feedback sessions: a plan and a script for testing early designs
How product feedback sessions differ from discovery interviews, with a plan, a 30-minute script and the questions to ask about each screen.
You have a rough design and you want to know whether it works before anyone builds it. A discovery interview will not tell you that. A product feedback session will. This guide covers how the two differ, how to plan a round of sessions, and the script we reuse at Mobility Labs, with the details swapped for each project.
How it differs from discovery
Discovery and product feedback answer different questions, and mixing them up wastes both.
| Discovery interview | Product feedback session | |
|---|---|---|
| Answers | What do people do, and why? | Can people use this design, and does it fit their work? |
| When | Before there is a design | Once there are rough wireframes |
| You bring | Questions | Mockups, tasks and questions |
| You ask about | The last time they did the work | What they see and expect on each screen |
| You leave with | Goals, frustrations and scenarios for a persona | A list of changes to the design |
Start with discovery if you are not sure who you are building for or what they need. Our persona interview questions guide has a script for that. Run feedback sessions once you have something for people to react to.
The questions change too. In discovery, "Would you use a feature that…?" gets a polite yes, because there is nothing to judge it against. With a screen in front of someone, "Would you print this page? What would you want to print?" is a fair question, because they can point at what they mean. Even then, treat the answer as a signal, not a promise.
Write the plan first
A written plan helps with either kind of research. Without one, each conversation drifts somewhere different and the notes will not line up. For a round of feedback sessions, decide five things before you book anyone.
- What you need to decide. Name the two or three design questions this round should settle. If an answer would not change anything, cut the question.
- Who you will talk to. Three to five people of each customer or visitor type is plenty. Find real potential users, not stand-ins. The people who know the audience can usually name them.
- How rough the design should be. Use low-fidelity wireframes. With no styling, people talk about what the product does instead of its colors. Say up front that some content may be temporary.
- Which tasks they will try. Write each task as something the person would really want to do, then list the screens it touches.
- How you will run it. Book 30 minutes, remote or in person, whichever suits them. Talk to one person at a time when you can, because in a group the loudest answer tends to become everyone's. Record with permission and share the results with everyone on the project.
The script
Copy this, then replace everything in brackets. Keep the wording close from session to session so the answers can be compared.
Introduction
- Tell me a bit about your role, your involvement with [topic] and your experience at your organization.
- We have 30 minutes to review some early designs, and I will try to stick to that.
- I will ask what you are seeing, how you read certain wording and what you would do to finish a task.
- You can ask questions or add comments at any time. The designs are rough on purpose, and we are testing them, not you.
- The goal today is to learn how you would use [tool].
Current process
- How do you handle [task] today?
- Have you looked for [information] before? How did you go about it?
Keep this part short. You want enough context to understand their reactions, not a full discovery interview.
Each screen
Share your screen and say: "I am going to show you early mockups and ask what you would do on each page." Pick from these for each screen rather than asking them all.
- What is the first thing you notice on this screen?
- What is the first thing you would do here?
- What would you expect to happen if you clicked [control]?
- How would you [task]?
- What do you think [label] means?
- What would you expect to find under [heading]?
- Would you share or print this? What would you want to include?
- Can you think of anything else that would be helpful?
Overall
- What did you think of the prototype overall?
- What are your top likes and dislikes from what you saw today?
- How does this compare to the tools you use now?
Wrap-up
- Is there anything we missed that you want to talk about, whether it is what you saw today or the concept overall?
- Thank you.
During the session
Ask people to think out loud, and remind them if they go quiet. If something on a mockup does not work, tell them they did not break it. When they ask what something does, ask what they think it does first, because their guess is the finding. If you are talking to several types of people, tell each person whose point of view you want, such as "Think about this as a provider visiting the site."
After the sessions
Sum up the round in one short document while it is fresh, using four headings.
- What people liked. Separate what everyone liked from what one person liked.
- What people disliked or worried about. Include anything they expected to find and could not.
- What to consider for later. Good requests that do not belong in this version.
- Links to the recordings or notes. So anyone on the project can check.
Then change the wireframes. If the changes are large, run another round on the new version before anyone builds it.
Where personas fit
A persona makes each step easier. It tells you who to recruit, it gives you realistic tasks, and it gives the team a shared way to weigh one person's comment: does this match the person we are designing for? If a session contradicts the persona, note it, and update the persona when you have the evidence. If you do not have one yet, make a persona before your next round.
Raj Patel
Practice manager, independent primary care clinic
“The doctors see 24 patients a day. If your tool adds a click per patient, that's 72 clicks they'll hate me for.”
- Job title
- Practice manager
- Company size
- 3 physicians, 14 staff
- Industry
- Primary care
- Reports to
- The three physician partners
Summary
Raj runs the business side of a clinic that has resisted being bought by the hospital system. He handles billing, staffing, the phones, and the electronic record vendor relationship. Each physician partner has a veto and a different tolerance for change. He buys rarely, pilots with one doctor first, and keeps a folder of every promise a vendor made.
Goals
- Get claims paid in under 30 days
- Cut the phone volume by moving refills and scheduling online
- Keep the clinic independent by keeping overhead low
Challenges
- A record system that charges for every integration
- Physicians who want change but not on their patients
- Patients over 70 who will not use a portal and patients under 30 who will not call
Buying criteria
- A signed business associate agreement before any patient data moves
- A working integration with the clinic's record system, demonstrated live
- Pricing by provider that stays flat for three years
- A pilot with one physician before the practice commits
Objections
- "Dr. Alvarez will never use it"
- "We can't afford a second system to keep in sync"
- "The hospital's offer includes this for free"
Where they get information
- The medical group management association's forums
- The clinic's billing consultant
- Practice managers at two neighboring clinics he texts weekly
Based on
Illustrative composite. Drawn from published independent-practice surveys and from patterns Mobility Labs has seen in healthcare projects. Not a research persona: no practice managers were interviewed for this profile.