Revising a design from user feedback
Turn what testers actually struggled with into specific, testable design changes: instead of guessing.
- Separating what happened from what you hoped: Revising well starts with recording what testers actually did, not what you wanted them to do.
- Writing a specific, checkable goal: A change you can test ('cut setup to under 2 minutes') has to be specific, which this skill depends on.
Prerequisites are inferred: pending teacher review.
Re-learn the skill with worked practice and clear examples.
Revising from feedback means turning a specific usability problem into one testable change, then re-testing to confirm it helped. Usability is how easy and error-free a design is to actually use.
Usability testing of a glucose-meter app shows that 6 of 8 testers could not find how to log a reading. Which revision best fits this feedback?
Reviewed- A.Add three brand-new features users didn't ask about
- B.Make the 'Log a reading' button bigger and put it on the main screen, then re-test the same task
- C.Change the app's color theme to look more modern
- D.Remove the testers who got confused and ship it
Show the worked solution ▾
Answer: B. Make the 'Log a reading' button bigger and put it on the main screen, then re-test the same task
- Step 1: Restate the problem: The specific problem is that most testers can't find how to log a reading: a usability problem.
- Step 2: Match a single change to it: Making that exact button bigger and obvious targets the problem, and re-testing the same task checks whether it helped.
Why it's right: It changes one thing that directly targets the reported problem and re-tests the same task, which is exactly how an iteration confirms a revision worked.
- A: Adding unrelated features doesn't fix the 'can't find logging' problem and muddies the next test.
- C: A color theme doesn't address whether testers can find the logging button.
- D: Dropping confused testers hides the problem instead of fixing it.
Aligned to Biomedical Innovation: usability iteration · reading level ~grade 9
- A medical-device team keeps a revision log: each row is one tested problem, the single change made, and the before/after result of re-testing.
Fill these in as you work through the lesson.
- Feedback (what a tester reports or does while using your design):
- Usability (how easy and error-free a design is to actually use):
- Iteration (one round of build, test, change, test again):
- Prototype (an early working version you test, not the final product):
Strong revision starts from a specific about a real problem, makes one you can re-test, and then again to check if it helped.
- A tester says 'I didn't like it.' What would you ask to turn that into something you can act on?
- Why is changing one thing at a time better than changing five things at once before re-testing?
- How do you tell whether a revision actually worked?
Five testers try your app. Four of them tap the wrong button to start. Write the specific problem, one change you would make, and how you would re-test to see if the change worked.