How do I decide which prototype problem to fix first?
Quick answer
Start with what someone actually did or said, not your guess about why. For each issue, note whether it changed a decision, blocked comprehension, or disrupted the experience you intended. Prioritize the issue with the clearest, most consequential effect—not simply the easiest fix or the most comments. Then turn it into one revision question you can investigate in the next test.
The question, the details, the next step.
I have several notes from people trying my prototype. How do I choose what to tackle first instead of fixing everything?
Separate each note into three parts: the observation, its effect, and your interpretation. For example: “They reread the instruction twice” is an observation; “they may not know which piece to move” is an interpretation. Keeping those apart helps you avoid treating a guess as a confirmed problem.
Then ask what the moment affected:
- Decision: Did it change what the person chose or tried?
- Comprehension: Did it prevent them from understanding what to do or what was happening?
- Intended experience: Did it disrupt a quality you deliberately want, such as a calm pace or a feeling of discovery?
Give each issue a short description and a concrete example from the session. An issue that blocks a key decision or understanding usually deserves attention before a minor polish issue. But keep your prototype’s goal in view: a confusing detail may matter less if it is outside what this version is meant to test.
What if one person struggled with something, while several people made smaller comments about another part?
Don’t decide by counting comments alone. Compare the likely effect and how well you understand the observation. One person’s clear inability to complete an important step may matter more than several preferences about wording. On the other hand, a single unclear reaction might be a one-off, especially if you cannot tell what caused it.
Use a simple triage sheet. Record how many sessions showed the issue, but also note whether it changed a decision, blocked comprehension, or disrupted the intended experience. Mark your confidence in the interpretation as low, medium, or high. Those labels are organizing aids, not proof or a precise score.
If the effect seems important but your explanation is uncertain, the next step may be a test that clarifies the cause—not a large redesign based on a hunch.
Can you show me how that works with a specific example?
Hypothetical example: imagine a card-game prototype intended to feel easy to learn. In one session, a player pauses at the setup card, puts a token in the wrong place, then asks what the instruction means. In two other sessions, players say the card title could sound more exciting.
The setup observation may affect comprehension and the next decision: the player cannot confidently begin. The title comment is a preference unless you have evidence that it changes understanding or the intended experience. So I would investigate the setup first—not assume the wording is the cause.
A useful next-test question could be: “Will a clearer placement cue help a new player set up the game without asking where the token goes?” For the next version, change only the cue you want to examine if practical, then watch what people do before explaining it. This makes the test about a specific uncertainty rather than whether the whole prototype feels better.
How do I turn my priority into a useful revision question and keep the next test focused?
Write the question so it names the observed moment, the change you are considering, and the behavior that would help you judge it. Avoid questions like “Is this better?” because they do not say what “better” means.
Copyable format: “Will [specific change] help [intended user] [observable action or understanding] at [specific moment]?”
For example: “Will adding a labeled starting space help a first-time player place the token correctly during setup without prompting?” Treat the example as a hypothesis, not a guaranteed fix. A test can show that the difficulty remains or that another part of the instruction is involved.
Before testing, decide what you will observe and what result would make you reconsider the change. Keep the other issues on the sheet for later; choosing one question now does not mean the others are unimportant. It means your next iteration has a clear purpose.
A practical checklist
Write each issue as an observable moment, separate from your explanation of its cause.
Note whether it affected a decision, comprehension, or the intended experience.
Record how often it appeared and how confident you are about its cause.
Prioritize clear, consequential obstacles over preference-only polish.
Write one testable revision question with an observable outcome.
Keep other issues on the triage sheet rather than silently discarding them.
A few more useful answers
Should I always fix an issue that blocks comprehension first?
Not automatically. Check whether it blocks an important part of what this prototype is meant to test, and whether the observation is clear enough to act on. If the cause is uncertain, make the next test about clarifying it.
Should I change several things before the next test?
You can, but changes to several parts may make it harder to interpret what happened. When practical, focus the next iteration on the question you most need answered.
What if feedback conflicts?
Keep the differing observations separate and note the context in which each occurred. Use a focused follow-up test to learn what conditions or interpretations may explain the difference.