<✦>aicodedesign.Start building

USER TESTING

Test the task, not just the screen

A practical test script for finding the moments where a convincing prototype stops helping a real person.

AI Code Design editorial · October 6, 2026

Choose a task with a visible ending

“Explore my app” makes a weak test because almost any click can look successful. Try: “A friend recommended a book called The Quiet Garden by Alex Rivers. Save it with a note, mark it finished, then show only books you still want to read.” This is a fictional scenario, not a claim about a real published book. You can observe whether the task was completed and where the person needed help.

Before inviting a tester

Tell the person this is a prototype, explain what works, and ask permission to take notes. Use fictional information. Do not record audio or video without their agreement. Explain that you are testing the design rather than their ability. Start from the same known state for each session and avoid exposing previous testers’ entries.

Run a short observation session

  1. Ask what they think the page helps them do before they interact.
  2. Give the task without naming the button to click.
  3. Observe the first action, hesitation, wrong turns, and recovery.
  4. Ask what they expected when the result differs.
  5. Finish by asking what felt uncertain and what they would do next.

Resist explaining every pause. If they are completely blocked, offer help and record that help was needed. A task completed with coaching is useful evidence, but it is different from independent completion.

Use a small evidence table

RecordExample format
Task and contextSave and retrieve a fictional recommendation; mobile viewport.
Observed behaviorWrite what the person actually did or said.
InterpretationYour explanation, clearly labeled as a hypothesis.
ChangeA specific label, layout, rule, or recovery improvement.
RecheckRepeat the task; record whether the same difficulty remains.

The table is a template, not a report of research we performed. A few sessions can reveal problems worth investigating; they do not establish market demand or a population-wide conversion rate.

Run the reliability checks separately

Keyboard through every control and check that focus remains visible and sensible after a change. Submit blank and whitespace-only titles. Add long text. Try a duplicate with different capitalization. Filter to a state with no results. Reload after saving. Export and restore the list. Restore an invalid file and confirm the existing list remains intact. Check a narrow screen for sideways scrolling.

These checks answer whether specified behavior works under chosen conditions. Observing people answers whether the behavior is understandable and useful. You need both; neither replaces a fuller accessibility or security assessment for a real product.

Let the result change the next step

If people cannot find a saved book, do not immediately add recommendations or cover artwork. Investigate retrieval, status labels, and filter visibility first. Choose one change tied to an observation and repeat the task. Preserve the before state and write why you changed it.

Use the Passport testing section to keep observations, hypotheses, fixes, and limitations together. Your portfolio can then show how evidence shaped the design, rather than just displaying the final screen.

Put the idea into practice.

Enter the project studio