Usability
Running a heuristic walkthrough in the week before freeze
When a freeze date is close, a usability walkthrough has to answer a narrow question: which friction will still hurt first-time users if we ship this build? That framing keeps the session from drifting into a redesign wishlist.
Pick tasks that match launch promises
Start from the store listing and marketing claims. If the listing promises “book in three taps,” that booking path is mandatory. Secondary settings screens can wait unless they block account recovery.
We usually limit a late-stage pass to five to seven tasks. More than that and notes become shallow. Fewer, and you miss recovery paths that only appear after an error.
Choose devices your audience actually owns
Lab flagships hide layout clipping and slow network behavior. For Thai consumer apps we keep mid-range Android devices and at least one older iPhone in the rotation. Low-memory conditions often surface cart-loss bugs that never appear on a reviewer’s laptop emulator.
Write notes for triage, not for theatre
Each finding should name the task, the step, what the reviewer expected, and what happened. Screenshots help; long prose does not. Severity should reflect user impact and frequency, not how clever the observation feels.
- Blocker: cannot complete a launch-critical task
- High: recoverable with confusion or repeated attempts
- Medium: friction that slows confident users
- Low: polish that can wait until the next train
Leave time for a live readout
A shared document alone rarely moves a sprint. Schedule a short walkthrough so product and engineering hear the same examples. That conversation is where “we will fix it next month” becomes an explicit, accepted risk — or gets pulled into the freeze.