Wireframes, prototypes and usability tests¶

Exercise wireframes-prototypes-tests-annex.pdf · PDF

A volunteer sits in front of four grey screens of NoteBox, a small notes app. The task: "You want your friend Anna to see your shopping list." The room stays silent. The volunteer opens the note and hovers over Save. Then stops. The share action is behind a button called Options. Would you have spotted that bad name yourself? You could not: you already know where Share is.

That was a usability test. It took three minutes and four grey screens, before anyone chose a colour or wrote a line of code. This page shows you how to do the same to your own app: sketch it cheaply, make it clickable, watch a real person try it, and have it inspected.

The architect¶

Remember the building from the Accessibility page? This is the same building, one step earlier. Nobody pours concrete first. An architect draws a floor plan, builds a scale model, walks the future tenants through it, and has an inspector check it against the building code. Moving a wall on paper costs a minute. Moving it in concrete costs a month.

A wireframe is a sketch of one screen: boxes and real words, with no styling.

A user flow is the path through the screens for one task: the screens, and the actions between them.

A prototype is a set of screens linked so that someone can click through them.

flowchart LR
    F["<b>User flow</b><br>the route"] --> W["<b>Wireframes</b><br>the floor plans"]
    W --> P["<b>Prototype</b><br>the scale model"]
    P --> T["<b>Test</b><br>tenants walk through"]
    T -->|"move a wall: it costs a minute"| W
    T -->|"when it works"| C["<b>Code</b><br>the building"]

Fidelity is how close a sketch is to the finished product. Low fidelity means grey boxes. High fidelity means your design system applied. You start low on purpose.

Wireframes: four rules¶

• Grey boxes. No colour, one font, no images: just a box with the word "image".
• Real words. "Send invite", not "Button". "Email", not "Lorem ipsum". The words are the interface. If you do not know what the button says, you do not know what it does.
• The right control. The two questions still apply to a grey box.
• Five minutes per screen. If it takes longer, you are decorating.

Build them from a kit of ready pieces (title, field, list row, image placeholder, text lines, buttons, tab bar) with auto layout, and they are quick to rearrange. The handout's Figma file has one.

Look at a finished wireframe. What can you criticise? Structure, order, labels. What can you not criticise? Colours, fonts, icons. That is the point.

User flows: a task, not a tour¶

A flow starts from something a person wants: "I want Anna to see my list", not "the share feature". This is the notation:

Here is sharing a note in NoteBox:

flowchart LR
    S(["<b>Start</b><br>I want Anna to see my list"]) --> A["<b>1 Notes</b><br>title, search, three rows"]
    A -->|"tap the note"| B["<b>2 Note</b><br>title, text, Options, Save"]
    B -->|"tap Options"| C["<b>3 Share</b><br>email, message, Send invite"]
    C -->|"type the email,<br>tap Send invite"| D["<b>4 Notes</b><br>toast: Invite sent"]
    D --> E(["<b>End</b><br>the toast confirms it"])

Count: four screens and four actions (tap, tap, type, tap). Efficiency is visible in a flow before anything is built, because every action costs the user something.

Notice the end. How does the user know it worked? A toast, a new row, a "Sent" screen. A flow with no end is a flow with no feedback.

Once the happy path works, draw the unhappy one:

flowchart LR
    C["<b>3 Share</b>"] -->|"tap Send invite"| Q{"<b>Is the email<br>valid?</b>"}
    Q -->|"yes"| D["<b>4 Notes</b><br>toast: Invite sent"]
    Q -->|"no"| X["<b>3 Share</b><br>inline message<br>under the email"]
    X -->|"fix the email"| Q

From your app to a prototype¶

Start from your app's command list, and pick the one task your app exists for.

Three things that often go wrong:

• You start with the login screen. Is logging in what your app is for? Wireframe the task, and assume the user is already in.
• One giant screen does everything. Count the arrows of the flow: each one that changes what you see is a screen.
• Colours and logos appear. Take them away, kindly. They come later.

Make it click¶

In Figma, open the Prototype tab (Shift+E). Then:

1. Select a button and drag its dot to the destination frame. Choose On click and Navigate to.
2. To go back, add an interaction with the action Back. You draw no arrow, because Back returns to wherever you came from.
3. Select the first frame and set it as the Flow starting point. Without it, the prototype may start on the wrong screen.
4. Play it with Shift+Space.

One rule catches people out: links only work between top-level frames of the same page. A screen dragged inside another frame cannot be a destination.

Testing with real users¶

A usability test is a session where a real person tries a real task while you watch.

A heuristic evaluation has experts guess what will go wrong. A usability test shows you. The two find different things, so do both.

The usual method is think-aloud, described by Clayton Lewis at IBM in 1982: the person says what they look at, what they expect and what surprises them. You get their reasoning, not only their taps.

Write a good task¶

The task must give a goal, not the route, and not ask for an opinion.

Three rules for the designer¶

Do not help. Do not explain. Do not defend.

If they ask "where is it?", answer "what would you try?". The app will ship without you sitting next to it. And if you help, you have tested yourself.

When a polite user says "it's fine, very clear", ignore the compliment. Did they hesitate anywhere? Write that down. And when someone gets lost, remember: the user did what the screen suggested, so change the screen.

What to write down¶

The three words of ISO 9241-11 become three things you can measure:

It works best with three people, who rotate:

Why someone new? "I tested it myself and it works" means nothing: you know where everything is, so you are the one person who cannot test it.

How many users?¶

Nielsen and Landauer (1993) found that, with their average figures, 5 users reveal about 85 % of the problems, and the sixth mostly repeats what you saw. So three rounds of five are better than one round of fifteen: you fix between rounds. For a class project, two or three users are already worth a lot. If three out of three miss the button, you do not need a fourth.

The inspector: an accessibility audit¶

The tenants have walked through. Now the inspector checks the building code.

An accessibility audit checks an interface against accessibility rules such as WCAG, by hand and with tools.

By hand, on the wireframe¶

Do not wait until the end: target sizes, labels and order are decided in the wireframe. Even in grey, check these:

By machine, on a real page¶

These tools read real HTML, so they do not run on a Figma file. Your app meets them in Unit 3, but you can try them today on any web page.

To run Lighthouse, open the page in Chrome or Chromium and press F12. Open the Lighthouse tab, tick only Accessibility, and press Analyze page load. Read the score, then open the findings. In Firefox there is no Lighthouse tab, but pagespeed.web.dev shows the same Accessibility category, and the browser's own Accessibility inspector has a Check for issues option.

What the machine cannot see¶

A photo of a dog with alt="A cat" passes every tool. Deque measured its own tools on about 13,000 pages in 2021: automation caught about 57 % of the issues, counted by volume. Lighthouse's own report says that only a subset of accessibility issues can be detected automatically.

From observations to fixes¶

A test gives you a pile of notes. You cannot fix everything, so you need an order. Rate each problem with Jakob Nielsen's severity scale:

Then write your top 3 fixes, each in the same format: screen · heuristic or criterion · severity · what you saw · what you will change. For the volunteer at the start:

2 Note · heuristics 2 and 6 · severity 3 · stopped at Save, could not find how to share · replace Options with a visible Share button

Fix those three, then test again.

Key takeaways¶

• A wireframe sketches one screen, a user flow shows the path of one task, and a prototype links screens so people can click. Start at low fidelity: changes cost minutes, not days.
• A wireframe uses grey boxes and real words. A flow starts from what a person wants, and has an end the user can see.
• A usability test puts a real person in front of a real task. With think-aloud, you hear their reasoning. Your rules: do not help, do not explain, do not defend.
• Record effectiveness, efficiency and satisfaction. About 5 users reveal around 85 % of the problems, so test in small rounds.
• An accessibility audit combines a manual check with tools such as Lighthouse and axe. A score of 100 means no automatic failures, never "accessible".
• Turn your notes into a short list of fixes, ordered by severity.

Quick check¶

That closes Unit 1: you can now design screens that are usable, accessible and built from reusable pieces, and you know how to prove it with real people. In Unit 2 you will turn those designs into code with a visual editor.