Prototype Evaluation & Usability Testing

Prototype Evaluation & Usability Testing

Building a prototype is only half the job. The other half — the half that separates a guess from a validated design — is evaluation. Evaluation answers the question that no amount of internal review can answer definitively: can real users actually work with this design? As a systems analyst you are not just a builder; you are a detective who gathers evidence about whether the proposed solution will work before the development team writes a single line of production code.

This lesson covers the two most practical evaluation techniques for analysts: the structured walkthrough and the think-aloud usability test, and then the disciplined process of iterating on findings to close the loop.

Structured Walkthroughs

A structured walkthrough (also called a cognitive walkthrough or expert review) is an inspection technique: a small group of reviewers — analysts, developers, domain experts, or experienced designers — steps through the prototype screen by screen, asking a consistent set of questions at each step. No real end-users are required, which makes it fast and cheap.

At each screen the panel asks four questions:

1. Will the user know what to do next? Is the action obvious from the current screen?
2. Will the user notice the correct control? Is the button, link, or field visible and discoverable?
3. Will the user understand the feedback? If they act, does the system response make sense?
4. Does the result match the user's goal? Did the action move the user forward?

In a logistics firm's booking prototype, a walkthrough panel reviewing the "schedule a pickup" flow might discover at step 2 that the Confirm button is below the fold on a 13-inch laptop — users will not scroll because nothing signals that there is more content below. That finding surfaces in thirty minutes without recruiting a single driver or dispatcher.

Think-Aloud Usability Testing

A think-aloud test puts a real representative user in front of the prototype and asks them to narrate their thoughts as they work through a predefined set of tasks. The analyst or a colleague acts as the facilitator — silent except to prompt the participant to keep talking. A second team member takes notes or timestamps a screen recording.

The classic think-aloud protocol, developed by Jakob Nielsen and refined over decades, requires only five to eight participants to uncover roughly 80 % of major usability problems. For a clinic appointment-booking system, five patients using a mid-fidelity prototype of the booking flow will surface navigation confusion, unclear field labels, and missing confirmation messages far more reliably than any document review.

Running a think-aloud session — six steps:

1. Define tasks. Write realistic task scenarios without leading language. Bad: "click Register". Good: "You need to book a blood-test appointment for next Tuesday morning."
2. Brief the participant. Explain you are testing the system, not the person. Encourage candid speech; silence is data too.
3. Observe, do not help. If the user is stuck, note the sticking point. Intervene only if the session has completely stalled and you need to move on.
4. Probe gently. Use neutral probes: "What are you thinking right now?" or "What did you expect to happen?"
5. Note verbatim quotes. Quotes anchor findings to real user language when you report back to stakeholders.
6. Debrief. After the tasks, ask two or three open questions: "Was anything confusing?" and "What would you change?"

Analysing and Prioritising Findings

Raw session notes are not yet actionable. After testing, the team performs an affinity sort: each observed problem is written on a card (or a sticky note in a tool such as Miro), and cards are grouped by theme — navigation, labelling, error handling, performance perception, and so on. Within each group, items are ranked by the severity scale established during the walkthrough.

The output is a usability findings report — typically a short table with columns: ID, description, location in prototype, severity, frequency (how many participants hit the same issue), and a recommended fix. This table feeds directly back into the requirements specification: a finding rated severity-3 or above becomes a new or revised functional or non-functional requirement.

Iterating on Findings

Evaluation is not a one-off gate; it is a cycle. After each round of testing the team makes targeted changes to the prototype, then re-tests the specific flows that were problematic. Two or three rapid iteration cycles — each taking only a few days with a low-to-mid fidelity prototype — typically resolve the majority of critical and major issues before high-fidelity work begins.

For an online store checkout redesign, a typical cadence looks like this: the first walkthrough surfaces a confusing guest-checkout path; the analyst updates the prototype, then runs three think-aloud sessions with representative shoppers; two participants struggle with the promo-code field; the analyst adjusts placement and label; a final round of two sessions confirms the fix. Total elapsed time: four days. Total cost: facilitator time plus a handful of gift cards.

Connecting Evaluation Back to the Analyst Role

Usability testing is not solely a UX designer responsibility. As the analyst you own the requirements baseline. When a usability finding reveals that a user cannot complete a core task, that is a requirements failure — the design did not satisfy the need. Your job is to translate the finding into a revised or new requirement, update the specification document, and ensure traceability from the test observation all the way through to the acceptance criterion that the QA team will eventually validate.

The deliverables you produce in this phase — the findings log, the severity-ranked issue table, the updated wireframes or prototype, and the revised requirement IDs — all flow into the design specification and form the evidence trail that justifies every change to the agreed scope.