Usability Testing: Watching People Use the Product

The people who build a product know too much about it.

They know where features live, what labels mean, and which workaround succeeds. New users do not share that internal map.

Usability testing observes representative people attempting realistic tasks so the team can see where the design fails to communicate.

It studies behavior and reasoning, not whether participants can be persuaded to say they like the interface.

A concrete example: finding export

A team asks participants to export a monthly report.

Several people open Share, while the product places export under Reports. They eventually succeed only after searching menus.

The finding is not "users are wrong." Their repeated behavior suggests the navigation model does not match their expectation.

Define the research question

A useful study begins with questions such as:

• Can a new customer complete setup?
• Do people understand permission choices?
• Can support staff locate an order quickly?
• Where does account recovery fail?

"Test the whole app" is too broad to produce focused tasks or decisions.

Representative participants

Participants should resemble relevant users in experience, goals, context, and access needs.

A developer testing an accounting workflow may not reveal problems faced by a small-business owner. Experienced customers and first-time users may need separate sessions.

Five convenient colleagues are not automatically representative.

Realistic tasks

Give participants a goal, not a sequence of interface instructions.

Weak task:

Click Reports, choose Export, and select CSV.

Better task:

You need to send last month's transactions to your accountant. Show how you would obtain the file.

The second task reveals whether the interface communicates a path.

Avoid leading language

Task wording can accidentally reveal labels or expected actions.

If the button says "Invite member," asking someone to "invite a member" makes discovery easier than their real situation. Use natural context and avoid repeating interface terms unless the user would genuinely know them.

Neutral moderation protects the evidence.

Think-aloud method

Participants may be asked to explain what they are looking for and what they expect.

This reveals mental models:

• "I think this will save automatically."
• "I do not know whether this person can see the file."
• "I expect billing under account settings."

Thinking aloud can slow behavior, so observations should account for that artificiality.

Do not teach during the task

Watching someone struggle is uncomfortable, but immediate rescue removes the evidence.

The moderator can encourage the participant to continue and intervene for safety or after a defined stopping point. Help given should be recorded because success after coaching is not independent success.

The product is being tested, not the participant.

Observe behavior and signals

Record:

• task completion,
• wrong turns,
• hesitation,
• repeated actions,
• requests for help,
• error recovery,
• time where useful,
• and participant comments.

Facial expression alone is ambiguous. Combine observed actions with what the participant explains.

Success is not binary

A participant may finish but experience severe friction.

Distinguish:

• direct success,
• success with hesitation,
• success after an error,
• success with assistance,
• and failure.

This richer view prevents a difficult workflow from being declared usable merely because the final screen appeared.

Moderated and unmoderated studies

Moderated sessions allow follow-up questions and observation of reasoning.

Unmoderated studies can reach more people quickly but provide less opportunity to clarify unexpected behavior. They require especially clear tasks and reliable recording.

The method should match the question, maturity, and available participants.

Remote and in-person

Remote testing reflects many real work contexts and reaches geographically distributed users.

In-person testing can reveal physical environment, device handling, and contextual details more easily. Either can be effective when setup and participant comfort are handled well.

The format is less important than representative behavior and disciplined observation.

Prototype testing

Usability testing does not require finished software.

Paper sketches and clickable prototypes can answer:

• Can people find the path?
• Do labels make sense?
• Is the information order useful?

Early tests make major changes cheaper. High-fidelity prototypes are needed when timing, input, scrolling, or system feedback matters.

Accessibility participation

Include people who use assistive technology or have relevant access needs.

Automated accessibility checks cannot reveal every practical barrier. Sessions may examine:

• screen-reader navigation,
• keyboard workflow,
• magnification,
• voice input,
• captions,
• or cognitive load.

Accommodations should support the participant without altering the product behavior under study.

Sample size

Small studies can reveal repeated serious issues, especially in focused workflows.

They cannot estimate precise population percentages reliably. Larger samples may be needed to compare variants or measure prevalence.

Run iterative studies as the design changes rather than expecting one session count to certify usability forever.

Findings and severity

A useful finding includes:

• observed evidence,
• affected task and participants,
• user impact,
• likely contributing design,
• and uncertainty.

Severity may consider frequency, impact, persistence, and recoverability. One rare issue that causes irreversible data loss can outrank a common minor hesitation.

Recommendations

Do not jump from one participant's suggestion directly to implementation.

Users are excellent evidence about goals, confusion, and consequences. The team still needs to identify the underlying problem and evaluate solutions across users and constraints.

Several design options may address the same observed friction.

Combining methods

Usability testing explains why behavior happens in a small observed sample.

Analytics can show where many users abandon a flow. Support messages expose recurring pain. Surveys capture reported attitudes.

Combining evidence creates a stronger picture than treating one method as complete.

Ethical handling

Participants should understand:

• what is recorded,
• how data will be used,
• whether sensitive tasks are involved,
• and that they can stop.

Avoid real passwords, financial details, or private records. Compensate participants fairly and store recordings with appropriate access and retention.

Knowledge check

1. Why are product-team members often poor substitutes for representative users?
2. What makes a task realistic rather than leading?
3. Why should moderators avoid teaching during the task?
4. How can a participant succeed while still revealing a usability problem?
5. How do analytics and usability sessions provide different evidence?

The one idea to remember

Usability testing watches representative people pursue realistic goals without being coached through the interface. Their behavior reveals mismatched mental models and friction that internal familiarity and opinion cannot reliably expose.