Research real users, define the problem, design and prototype a solution, test it and write it up as a portfolio case study.

UX Design Process

Pick the three screens from your flow that matter most for the task and write the goal of each in one sentence.

For the most important screen, fold a sheet into eight panels and do Crazy 8s: eight different sketches in eight minutes.

Circle the best ideas from your eight sketches and combine them into one layout.

Wireframe all three screens at phone size with real headings, labels and example data (no lorem ipsum).

Check hierarchy: on each screen, make sure exactly one element is clearly primary.

Add at least one state that your flow needs, such as an error, empty or loading state.

Annotate any behaviour you cannot draw in the margin.

Show the three screens to someone for 10 seconds each and ask what they think each screen is for. Note any mismatch with your goal sentences.

## Why it matters

A **wireframe** is a simple drawing of a screen that shows what goes where: content, controls and their priority, without colour, images or polish. Wireframes let you test structure and content cheaply. When something looks rough, people comment on whether it works ("I can't find the total") instead of how it looks ("I don't like that blue"). That is exactly the feedback you need at this stage.

## The core idea: fidelity matches the question

**Fidelity** is how close a design is to the final product.

| Fidelity | Looks like | Good for |
|---|---|---|
| Low | Pen sketches or grey boxes, real-ish words | Layout, content, priority, flow; many options fast |
| Mid | Clean grey-scale screens in a tool | Spacing, components, realistic content |
| High | Final colour, type and imagery | Visual polish, brand, final sign-off |

Start low. You should be able to throw a low-fidelity wireframe away without regret. Move up only when the questions you are asking need it.

## What goes into a wireframe

- **Real content**, or close to it. Write the actual heading, button label and an example amount. "Lorem ipsum" hides problems, such as labels that are too long or a missing total.
- **Priority**. Make the most important element obvious (larger, higher or bolder), as you learned in Visual Design Fundamentals.
- **Standard placeholders**. A box with a cross for an image, horizontal lines for body text, rounded rectangles for buttons.
- **States** that matter: an empty list, an error message, a loading state, where the flow needs them.
- **Annotations**: short notes in the margin for behaviour you cannot draw, such as "pre-filled with equal split" or "only shows if a housemate owes money".

## Worked example: three screens for the bill flow

From the user flow in the last lesson, the three key screens are Bill detail, Split and Confirmation.

**Bill detail**
```text
+--------------------------------+
| <  Internet - October          |
|                                |
|   $60.00                       |  <- largest element
|   Due 28 Oct  ·  Paid by Sam   |
|                                |
|  [ Split this bill ]           |  <- primary button
|                                |
|  View PDF                      |  <- secondary link
+--------------------------------+
```

**Split**
```text
+--------------------------------+
| <  Split $60.00                |
|  Split equally  (o) yes ( ) no |
|  Sam (you)        $15.00       |
|  Priya            $15.00       |
|  Leo              $15.00       |
|  Jordan           $15.00       |
|  Total            $60.00  ok   |  <- turns red if totals differ
|  [ Send requests ]             |
+--------------------------------+
Note: housemates who left before the bill date are not listed.
```

**Confirmation**
```text
+--------------------------------+
|        (tick)                  |
|   Requests sent to 3 people    |
|   We'll remind them in 3 days. |
|   [ Back to the house ]        |
+--------------------------------+
```

Notice the decisions made on paper: the amount is the hero on Bill detail; the total check is visible on Split so the error from the flow has a home; the confirmation reassures Sam that the app, not Sam, will do the chasing, which addresses the "nagging" pain point.

## Crazy 8s for options

Before settling on one layout, sketch options fast. In **Crazy 8s** you fold a sheet into eight panels and sketch eight versions of one screen in eight minutes. Most will be bad. One or two will contain an idea you would never have reached by polishing your first attempt.

## Paper or Figma?

Both work. Paper is fastest for exploring. Figma's free plan is good once you want to rearrange, duplicate and later link screens into a prototype (next lesson). In Figma, use a phone-sized frame, grey rectangles and plain text; avoid colour for now. Free wireframe kits are available in the Figma Community.

## Common mistakes

- **Starting in high fidelity.** You will defend pixels instead of testing ideas.
- **Placeholder text everywhere.** Real words reveal real problems.
- **No hierarchy.** Every element the same size and weight; nothing reads first.
- **Designing one perfect option.** Sketch several before choosing.
- **Forgetting states.** The empty, error and loading versions are part of the design.
- **Decoration.** Shadows, gradients and icons distract from structure at this stage.

## Quick recap

- Wireframes show layout, content and priority without visual polish.
- Match fidelity to the question; start low.
- Use real content, clear priority, standard placeholders and short annotations.
- Explore several options (for example with Crazy 8s) before refining one.

## Try it

On the Do tab you will sketch options and then wireframe the three key screens of your flow.


Sketch low-fidelity wireframes for the three key screens of your flow, focusing on layout, content and priority.

Wireframes

Prototypes vs Wireframes in UX Projects

How To Create Your First Wireframe (A UX Tutorial)

Write the one question your prototype must answer, for example "Can people split a bill unequally without help?".

List the screens and states needed to answer it, including any extra frames that fake logic (such as an error state).

Put each screen in its own phone-sized frame (or on its own sheet of paper) and name it.

In Figma's Prototype tab, connect every button on the tested path to its destination and set the first frame as the flow's starting point.

Add back navigation from every screen so a wrong tap is recoverable.

Give every other visible button a response, even if it only shows a "not part of this test" frame.

Present the prototype and click through every path yourself.

Pilot it with one person: give them the task, say nothing, and note every place they hesitate or tap something that does not respond.

## Why it matters

A wireframe shows a screen. A **prototype** lets someone use it. When people tap through a prototype, they reveal problems no static picture can: buttons they do not notice, steps they did not expect, and moments where they do not know what to do next. A prototype is also the clearest way to explain a flow to stakeholders and developers. Clicking through takes a minute; reading a spec takes much longer.

## The core idea: just enough to answer a question

A prototype is a question in disguise. Before you build one, write what you want to learn: "Can people split a bill unequally without help?" Then build only what is needed for that question. A prototype does not need every screen, real data or working logic. It needs the path being tested, plus enough surrounding screens that people do not hit a wall immediately.

Prototypes come in fidelities too:

- **Paper prototype**: hand-drawn screens; a person plays "the computer" and swaps paper when the participant taps. Very fast and surprisingly effective.
- **Clickable wireframes**: grey-scale screens linked with hotspots.
- **High-fidelity prototype**: close to the real look, with transitions and realistic content.

## Prototyping in Figma (free plan)

Figma's free Starter plan includes prototyping. The basic steps:

1. **Frames are screens.** Put each wireframe in its own phone-sized frame (Frame tool, then choose a phone preset).
2. **Switch to Prototype mode.** In the right-hand panel, open the Prototype tab.
3. **Add connections.** Select a button or hotspot; drag the small circle that appears onto the destination frame. Each connection is an **interaction**: a trigger (On click/tap), an action (Navigate to) and an optional animation (Instant, Dissolve, Smart animate).
4. **Set a starting point.** The first frame of the flow becomes the flow's starting point. You can have several flows in one file.
5. **Add back navigation.** Connect back arrows using the "Back" action so people can recover.
6. **Present.** Press the play button to preview, or share the prototype link with test participants.

Keep transitions simple ("Instant" or "Dissolve"); fancy animations take time and rarely answer your question.

## Worked example: the bill-split prototype

Question: *Can people split a bill unequally and send requests without help?*

Screens needed: Bill detail, Split (equal), Split (edit amounts), Split (totals do not match error), Review, Confirmation, plus a simple Home so participants have a realistic start.

Connections:

| From | Hotspot | To |
|---|---|---|
| Home | Notification card "Internet bill added" | Bill detail |
| Bill detail | "Split this bill" | Split (equal) |
| Split (equal) | "No" radio | Split (edit amounts) |
| Split (edit amounts) | "Send requests" | Split (error) |
| Split (error) | "Fix amounts" | Review |
| Review | "Send requests" | Confirmation |

Notice the trick in row 4: the prototype cannot calculate, so the first press of Send always shows the error state. In a test, you set up a scenario ("Leo owes 20, the others share the rest") that leads people to that state naturally. Prototypes often fake logic with extra frames like this.

## Making prototypes testable

- Use realistic content that matches your test scenario (names, amounts, dates).
- Make sure every visible button on the tested path does something, even if it only shows a "Not part of this test" message. Dead buttons confuse participants and spoil data.
- Put a frame number or name on each screen in the file so you can follow along during a test.
- Click through the whole prototype yourself, then ask one person to try it before a real session.

## Common mistakes

- **Prototyping everything.** Weeks spent wiring an entire app. Build what answers the question.
- **Polishing before testing.** High fidelity too early makes it painful to change.
- **Hotspots that are too small or missing.** Participants tap a label instead of the button; nothing happens; the test stalls.
- **No way back.** Without back links, one wrong tap ends the session.
- **Testing the prototype tool instead of the design.** If people are confused by the prototype's limits, say so up front and design the scenario around them.

## Quick recap

- A prototype lets people use a design so you can watch what happens.
- Start from a question and build only the screens and links needed to answer it.
- In Figma: frames as screens, Prototype tab, drag connections, set a starting point, present.
- Fake logic with extra frames, make every visible control respond, and pilot before testing.

## Try it

On the Do tab you will turn your wireframes into a clickable prototype and pilot it with one person.


Link your screens into a clickable prototype in free Figma so people can try the flow before anything is built.

Interactive prototypes

Figma For Beginners: Build prototypes (3/4)

Pencils vs. Pixels for UI Protyping and Sketching

## Why it matters

You will not always have time or budget to test every screen with users. **Heuristic evaluation** is a fast way to find many usability problems by inspecting a design against a set of well-known principles. **UI patterns** are proven solutions to common problems, such as tabs, steppers and inline validation, that people already know how to use. Together they let you catch obvious problems before you spend participants' time on them.

## The core idea: Nielsen's ten heuristics

Jakob Nielsen published ten "usability heuristics" in the 1990s. They are rules of thumb, not strict rules, and they are still the most widely used checklist in UX.

1. **Visibility of system status.** Keep people informed about what is happening, with timely feedback. Example: a progress indicator while a payment sends.
2. **Match between the system and the real world.** Use the user's words and familiar concepts. Example: "Who owes what" instead of "Outstanding receivables".
3. **User control and freedom.** Provide clear exits: undo, cancel, back. Example: "Undo" after deleting a bill.
4. **Consistency and standards.** Follow platform conventions and be consistent within your product. Example: the primary button always looks and sits the same way.
5. **Error prevention.** Prevent problems before they happen. Example: disable "Send" until shares add up to the total, or pre-fill an equal split.
6. **Recognition rather than recall.** Show options instead of making people remember them. Example: show housemates' names to choose from instead of asking for their email addresses.
7. **Flexibility and efficiency of use.** Offer shortcuts for frequent users without confusing new ones. Example: "Split like last month".
8. **Aesthetic and minimalist design.** Remove information that competes with what matters. Example: hide the bill's PDF metadata behind "Details".
9. **Help users recognise, diagnose and recover from errors.** Error messages in plain language that say what went wrong and how to fix it. Example: "Shares add up to $55. The bill is $60." rather than "Error 422".
10. **Help and documentation.** Ideally not needed, but if it is, make it short, searchable and in context. Example: a one-line tip beside "Split unequally".

## How to run a heuristic evaluation

1. Choose the flow or screens to review and the user's goal.
2. Walk through the flow at least twice: once to get a feel for it, once to inspect each element.
3. For each problem, write: where it is, what the problem is, which heuristic it breaks, and a **severity** rating (for example 0 = not a problem, 1 = cosmetic, 2 = minor, 3 = major, 4 = catastrophic: blocks the task).
4. Have three to five evaluators work independently, then merge their lists. One person typically finds only around a third of the problems.
5. Prioritise by severity and fix the biggest first.

Heuristic evaluation finds many problems, but not all, and it can flag things real users do not mind. It complements usability testing; it does not replace it.

## Worked example: an evaluation table

| Location | Problem | Heuristic | Severity |
|---|---|---|---|
| Split screen | Totals can differ from the bill with no warning until Send | 5 Error prevention | 3 |
| Error after Send | Message says "Validation failed" | 9 Error recovery | 3 |
| Confirmation | No sign of when reminders will go out | 1 System status | 2 |
| Bill detail | Delete has no undo | 3 Control and freedom | 3 |
| Menu | "Ledger" label | 2 Real-world match | 2 |

## Common UI patterns

Patterns save you from reinventing solutions. A few you will use constantly:

- **Inline validation**: check a field when the user leaves it, with the message next to the field.
- **Stepper (wizard)**: break a long task into numbered steps with progress shown.
- **Empty state**: explain what goes here and offer the first action ("No bills yet. Add your first bill").
- **Undo toast**: a short message after a destructive action with an Undo button.
- **Tabs and segmented controls**: switch between views of the same content.
- **Progressive disclosure**: show the essentials, hide advanced options behind "More options".

Use the standard pattern unless you have strong evidence that something else works better. Familiarity is itself a usability feature (heuristic 4).

## Common mistakes

- **Using heuristics as an opinion shield.** "This breaks heuristic 8" must point to a real problem for the user, not your taste.
- **No severity.** A long unranked list does not help a team decide.
- **One evaluator.** You will miss most issues.
- **Skipping user testing.** Heuristics find likely problems; users show actual ones.
- **Custom controls for standard jobs.** A home-made date picker usually performs worse than the platform's.

## Quick recap

- Nielsen's ten heuristics are a checklist for spotting usability problems quickly.
- Record location, problem, heuristic and severity; merge several evaluators' findings.
- Standard UI patterns are familiar and usually the best starting point.
- Heuristic evaluation complements, and never replaces, testing with users.

## Try it

The Do tab has a quiz that asks you to match real problems to heuristics. Afterwards, review your own prototype against the ten heuristics before you test it in the next module.


Review an interface against Nielsen's ten usability heuristics and use familiar UI patterns to fix what you find.

UI patterns and heuristics

Heuristic Evaluation of User Interfaces

Usability Heuristic 1: Visibility of System Status

Sketch wireframes, link them into a clickable prototype and review it against Nielsen's usability heuristics.