Mid-level product designers are expected to work in systems, not single screens, and to ship with engineers rather than throw files over a wall. This course covers why design systems exist and how to audit a product for inconsistency; design tokens for colour, type and spacing, written as CSS custom properties; component specs with states and variants; handoff specs and annotations, including accessibility annotations for focus order, labels and headings; reading and adjusting real HTML and CSS; and the product side of the job: choosing metrics with the HEART framework, planning post-launch research, and preparing a mid-level portfolio and design-challenge answer. Lessons combine a short reading, curated videos and hands-on tasks in free Figma, on paper or in small HTML and CSS exercises. It builds on UX Design Process and Accessible & Responsive Interfaces.

Build design tokens and component specs, hand designs to engineers with clear annotations, and measure and iterate after launch.

Design Systems & Developer Handoff

Choose a product and five to eight of its most-used screens. Write them down.

Create one board per category: buttons, text styles, colours, form inputs, error and alert messages, and one more of your choice.

Screenshot every instance of each category across your chosen screens, crop it and place it on its board.

Group identical instances and count the distinct variations in each category.

For each category, note the differences that matter (size, colour, radius, label style, states) and any that look inaccessible, such as low-contrast text.

Fill in a table: category, variations found, notes, and a proposed consolidated set.

Write a three-sentence summary you could send to a product manager explaining why consolidation is worth doing.

## Why it matters

As a product grows, small inconsistencies pile up. One team's button has 4px corners, another's 8px. There are eleven shades of grey, three date pickers and two different error styles. Each one was a reasonable decision on the day, but together they make the product feel unreliable, slow designers down ("which button do I use?") and multiply engineering work, because every variation has to be built, tested and maintained.

A **design system** is how teams stop that drift. Knowing how to use, extend and argue for one is a core mid-level skill: most product design jobs today involve working inside a system rather than designing every screen from scratch.

## The core idea: shared decisions, written down and built once

A design system is a collection of reusable decisions, with the code and documentation that make them easy to follow. It usually has these layers:

| Layer | What it is | Example |
|---|---|---|
| Principles | The values that guide decisions | "Clear over clever" |
| Design tokens | Named values for colour, type, spacing, radius, shadow, motion | `color-primary`, `space-4` |
| Components | Reusable UI parts with states and variants | Button, Input, Modal |
| Patterns | Combinations of components for common jobs | Sign-in form, empty state |
| Documentation | When and how to use each piece | Usage guidelines, do and don't |
| Code library | The components implemented for developers | A React or web component package |
| Governance | How changes are proposed, reviewed and released | Contribution process, versioning |

A **style guide** (colours and fonts) or a **UI kit** (a Figma file of components) is part of a system, not the whole thing. A system only works when design and code match and people know how to contribute.

Well-known public systems are worth studying: Google's Material Design, IBM's Carbon, the UK government's GOV.UK Design System, Shopify's Polaris and Atlassian's design system all publish their tokens, components and guidelines for free.

## What a system buys you

- **Consistency**: users learn a pattern once and recognise it everywhere.
- **Speed**: designers assemble screens from tested parts; developers reuse code.
- **Quality**: accessibility, states and edge cases are solved once in the component.
- **Easier change**: update a token, and every screen that uses it updates.

The cost is real too: someone has to maintain it, and a system that is too rigid or out of date gets ignored. Small teams often start with tokens and a handful of core components, not a full system.

## The interface inventory (UI audit)

The classic way to start, or to justify, a design system is an **interface inventory**: collect every instance of each UI element across the product and put them side by side. Brad Frost popularised this approach. The visual evidence ("we have 14 button styles") persuades teams far better than any argument.

How to run one:

1. **Choose the scope**: a product, or the five to ten most-used screens.
2. **Pick categories**: buttons, form inputs, colours, type styles, icons, spacing, cards, alerts and messages, modals.
3. **Screenshot every instance** and crop it. Paste each category onto its own board (paper, slides or free Figma).
4. **Group duplicates** and count the variations.
5. **Note the differences** that matter: size, colour, corner radius, label style, states.
6. **Recommend a consolidated set**: for example, "3 button variants (primary, secondary, danger) in 2 sizes".

## Worked example: a small audit

An audit of a booking site's top eight screens found:

| Category | Variations found | Notes | Proposed |
|---|---|---|---|
| Primary buttons | 6 | 3 blues, radius 2/4/8px, 36 to 52px tall | 1 style, 2 sizes |
| Greys used for text | 9 | Several fail contrast on white | 3 text greys |
| Error messages | 4 | Red text, red box, toast, alert icon only | 1 inline pattern + 1 page alert |
| Date pickers | 3 | Two custom, one native | 1 accessible picker |
| Font sizes | 13 | 11px to 40px with no scale | 7-step type scale |

This table, plus the boards of screenshots, became the case for building tokens (next lesson) and a small component library.

## Common mistakes

- **Starting with a huge library.** Build what the product actually uses; grow from real needs.
- **Design-only systems.** A Figma kit that does not match the code creates two sources of truth.
- **No owner.** Without governance, the system drifts like the product did.
- **Auditing opinions instead of instances.** Collect what exists before deciding what is "right".
- **Treating the system as a rulebook only.** It should make the right choice the easy choice, with clear docs and a way to propose changes.

## Quick recap

- A design system is shared, reusable decisions: tokens, components, patterns, docs, code and governance.
- It buys consistency, speed, quality and easier change, at the cost of maintenance.
- An interface inventory collects every instance of each UI element to show inconsistency and guide consolidation.

## Try it

On the Do tab you will run an interface inventory on a real product and propose a consolidated set of components.


Explain what a design system contains and why teams build one, then audit a real interface for inconsistency.

Why design systems

Welcome to design systems - Lesson 1 : Introduction to design systems

What is a Design System? 6 Different Types of Design Systems

## Why it matters

Design tokens are the smallest, most reused decisions in a product: the exact blue of the primary button, the body text size, the gap between a label and its input. When those decisions live as hard-coded values scattered across hundreds of files and Figma layers, changing one (a rebrand, a dark mode, an accessibility fix) means hunting down every copy. **Design tokens** give each decision a name and a single source, so designers and developers use the same value and change it in one place.

## The core idea: name the decision, not the value

A token is a name-value pair: `color-primary = #2563eb`. The name is what people use. The value can change without anyone editing the places that use it.

Most systems use two (sometimes three) tiers:

| Tier | Purpose | Examples |
|---|---|---|
| Primitive (core, global) | The palette and raw scales, named by what they are | `blue-600: #2563eb`, `space-3: 16px` |
| Semantic (alias) | What a value is *for*, pointing at a primitive | `color-primary: blue-600`, `color-text: gray-900` |
| Component (optional) | One component's specific use | `button-padding-x: space-4` |

Designers and developers should mostly use **semantic** tokens. A button uses `color-primary`, not `blue-600`. Then a dark theme or a rebrand only changes which primitive each semantic token points at.

## Tokens in Figma and in code

In **Figma** (free plan included), **variables** store tokens: colour, number and string variables, organised into collections, with **modes** for themes such as light and dark. **Styles** (colour, text, effect) are an older, still common way to share values. Figma's free plan has some limits on modes, so check the current plan details if you need many themes.

In **code**, the simplest form of tokens is **CSS custom properties** (CSS variables):

```css
:root {
  --blue-600: #2563eb;          /* primitive */
  --color-primary: var(--blue-600);  /* semantic points at primitive */
  --space-3: 16px;
}

.button {
  background: var(--color-primary);
  padding: var(--space-2) var(--space-4);
}
```

A custom property is declared with two dashes, usually on `:root` (the `html` element) so it is available everywhere, and read with `var()`. Custom properties cascade and can be overridden, which is how themes work:

```css
:root[data-theme="dark"] {
  --color-text: #f9fafb;
  --color-surface: #111827;
}
```

Many teams keep tokens in a JSON file and use a build tool (Style Dictionary is a popular free one) to generate CSS, iOS and Android formats from the same source. The W3C Design Tokens Community Group is working on a standard JSON format so tools can share tokens.

## Worked example: a small token set

```text
Colour primitives   blue-600 #2563eb   blue-700 #1d4ed8   gray-900 #111827   gray-100 #f3f4f6   white #ffffff
Colour semantic     color-primary -> blue-600        color-primary-hover -> blue-700
                    color-on-primary -> white        color-text -> gray-900
                    color-surface -> white           color-background -> gray-100
Type                font-size-body 16px   font-size-heading 28px
Spacing (4/8 base)  space-1 4px   space-2 8px   space-3 16px   space-4 24px
Radius              radius-md 12px
```

Note the spacing tokens are named by step, not by pixel value (`space-3`, not `space-16`), so the scale can be tuned later without names becoming lies. Check that each semantic colour pairing meets contrast requirements: white on `#2563eb` passes WCAG AA for normal text (about 5.2:1).

## Naming tips

- Use a consistent pattern: `category-role-variant-state`, such as `color-primary-hover`.
- Name by purpose for semantic tokens (`color-danger`), never by appearance (`color-red`), so a theme can change the appearance.
- Keep the set small. Every token is a decision someone must understand.
- Document which pairs are safe together (text on surface, on-primary on primary).

## Common mistakes

- **Using primitives directly in components.** Themes then need every component changed.
- **Appearance names for semantic tokens.** `color-blue-button` breaks the moment the button turns green.
- **Tokens only in Figma** or only in code. They must match; one source should generate the other, or be checked regularly.
- **Hundreds of one-off tokens.** If a value is used once, it probably does not need a token.
- **Ignoring contrast** when defining colour pairs.

## Quick recap

- Tokens name design decisions so they are used and changed from one source.
- Primitive tokens hold raw values; semantic tokens say what a value is for and point at primitives.
- In Figma, use variables (with modes for themes); in code, CSS custom properties on `:root`, read with `var()`.
- Name by purpose, keep the set small, and keep design and code in sync.

## Try it

On the Do tab you will replace hard-coded values in a small page with colour, type and spacing tokens written as CSS custom properties.


Define primitive and semantic tokens for colour, type and spacing, and apply them with CSS custom properties.

Design tokens

Tokens, variables, and styles - Update: Introduction to design systems

CSS Variables - An introduction to CSS custom properties

Choose the component and list its anatomy: every named part.

List its variants (for example type and size) and write when each should be used.

List every state it needs: at least default, hover, focus, pressed or filled, disabled, and one of loading or error.

Build or sketch a grid with variants as rows and states as columns, so every combination is visible.

For each cell, note which tokens it uses (colour, spacing, type, radius). Mark any value that is not a token.

Check every focus state is clearly visible against its background, and every text colour has enough contrast.

Write the behaviour rules: keyboard interaction, long content, minimum target size and accessible name.

Write two usage rules (do and don't) that would stop someone misusing the component.

## Why it matters

A component that only exists as one pretty picture will be built differently by every developer who touches it. What happens on hover? What does it look like disabled, loading or with a very long label? Does it work with a keyboard? A **component spec** answers those questions once, so the component is built correctly, documented, and reused everywhere. Writing clear specs is one of the clearest signs of a mid-level designer.

## The core idea: anatomy, variants, states, behaviour

A complete spec covers four things.

**1. Anatomy.** The named parts of the component. For a button: container, label, optional leading icon, optional trailing icon. Name parts the way developers will (match the code where possible).

**2. Variants.** Deliberate, *designed* differences that a designer chooses when placing the component:

- **Type or emphasis**: primary, secondary, tertiary (text-only), danger.
- **Size**: small, medium, large.
- **Content options**: with icon, icon-only.

**3. States.** Differences caused by *interaction or system status*, which every variant must handle:

| State | Trigger | Typical visual change |
|---|---|---|
| Default (rest) | Nothing happening | Base style |
| Hover | Pointer over it | Slightly darker background |
| Focus | Keyboard focus | Visible focus ring (at least 3:1 against the background) |
| Active (pressed) | Being pressed | Darker still, or slight inset |
| Disabled | Not available | Reduced emphasis; not focusable or explained |
| Loading | Action in progress | Spinner, label kept or changed to "Saving...", repeat clicks blocked |

Form inputs add more: filled, error, read-only, and help-text states. Remember that a state like focus must be visible on every variant, not just the primary one.

**4. Behaviour and content rules.** What happens and what is allowed: keyboard support (Enter and Space activate a button), long labels (wrap or truncate?), minimum target size (for example at least 24 by 24 CSS pixels under WCAG 2.2, and many teams use 44 or 48), icon-only buttons need an accessible name, and when to use each variant ("one primary button per view").

## Variants in Figma

In Figma, a **component set** groups variants and uses **properties** to switch between them. A button might have:

- `Type` = Primary, Secondary, Danger (variant property)
- `Size` = Small, Medium (variant property)
- `State` = Default, Hover, Focus, Pressed, Disabled, Loading (variant property)
- `Label` (text property) and `Show icon` (boolean property)

Three types x two sizes x six states = 36 variants. That sounds like a lot, but building them all is how you find gaps, such as a danger button whose focus ring is invisible against red. Build each variant with auto layout and tokens (variables), so changes flow through.

## Worked example: a button spec

```text
Component: Button
Anatomy: container | leading icon (optional) | label | trailing icon (optional)
Variants:
  Type: primary (filled, color-primary), secondary (outline, color-primary border),
        danger (filled, color-danger)
  Size: medium (height 44, padding-x space-4, font-size-body)
        small  (height 32, padding-x space-3, font-size-small)
States (every type and size):
  hover    background -> *-hover token
  focus    2px focus ring color-focus, 2px offset, visible on all types
  pressed  background -> *-active token
  disabled 40% opacity is NOT used (fails contrast); use color-disabled-bg and
           color-disabled-text, and prefer explaining why the action is unavailable
  loading  spinner replaces leading icon, label "Saving...", aria-busy, ignore repeat clicks
Behaviour:
  Enter and Space activate. Label wraps to max 2 lines; never truncate.
  Icon-only buttons require an accessible label (e.g. "Close").
Usage:
  One primary button per view. Danger only for destructive, irreversible actions.
```

Notice the spec ties every visual decision to a **token** (previous lesson), covers every state for every variant, and states rules that a developer or a future designer can follow without asking you.

## Where specs live

Specs live in the design file (a documentation page next to the component) and in the system's docs site. Many teams also document components in code with a tool such as Storybook, which shows each state live. Whatever the tool, design and code docs should say the same thing.

## Common mistakes

- **Only designing the default state.** Developers then invent hover, focus and error.
- **Confusing variants and states.** A danger button is a variant; hovered is a state. Mixing them creates a tangled component set.
- **Invisible focus** on some variants.
- **Disabled = low opacity** text that nobody can read, with no explanation.
- **Hard-coded values** instead of tokens.
- **No usage rules.** Without "when to use", people use the danger style because they like red.

## Quick recap

- A component spec covers anatomy, variants, states and behaviour, plus usage rules.
- Variants are designed choices (type, size); states come from interaction (hover, focus, pressed, disabled, loading).
- In Figma, build a component set with variant, text and boolean properties, using auto layout and variables.
- Every state must exist and be accessible on every variant.

## Try it

On the Do tab you will write a full spec for a component, with every state for every variant.


Specify a component's anatomy, variants, states and behaviour so it can be built once and used everywhere.

Component specs

Figma Tutorial: Variants

Figma components and variants for beginners

Audit a product for inconsistency, define colour, type and spacing tokens, and spec components with states and variants.

Design Systems

Create a cover note with the screen name, status (ready for dev), owner, and a link or reference to the user flow.

Place the screen with its states next to it: default, loading, empty or zero, error, and a version with very long content.

Add numbered markers beside each interactive element and a matching note in the margin describing its behaviour.

For every input, write the validation rule and the exact error message text.

Write the responsive rules: what stretches, wraps or stacks at a narrow width, and any maximum width.

List which system components and tokens the screen uses, and mark anything that is new or custom.

Ask someone (ideally a developer or a developer friend) to read only your annotations and list every question they still have. Answer each one in the file.

## Why it matters

"Handoff" sounds like a single moment when you throw a file over a wall. In good teams it is a conversation that starts early and continues through build. Still, at some point engineers need a design they can build from without guessing. Missing details turn into questions, delays and inconsistent results. Clear **specs and annotations** are how you answer the questions before they are asked.

## The core idea: answer what the picture cannot

Modern tools give developers measurements, colours and fonts automatically. In Figma, **Dev Mode** shows spacing, sizes, variables (tokens) and generated CSS for any layer. (Dev Mode is part of Figma's paid plans; on the free plan developers can still inspect layers with view access, and you can write the same information as annotations.) What tools cannot show is **intent**: behaviour, rules, edge cases and anything that changes over time.

So annotations should focus on:

- **Behaviour**: what happens on tap, hover, scroll, submit, success, failure.
- **States and edge cases**: empty, loading, error, long text, zero, one and many items, offline.
- **Responsive rules**: what stretches, what wraps, what stacks at small widths, breakpoints.
- **Content rules**: maximum lengths, truncation, formatting of dates and numbers.
- **Data and logic**: where values come from, sorting, validation rules.
- **Components and tokens used**: so developers reuse the system instead of rebuilding.
- **Accessibility**: covered in depth in lesson 3 of this module.

## A handoff-ready file

Organise the file so it is easy to navigate:

1. **A cover or index page** with the project name, status, owner, links to the ticket and research, and a changelog.
2. **Ready-for-dev sections.** Mark which frames are final. Figma lets you mark sections "Ready for dev"; otherwise a clear label works.
3. **The flow** at the top: the screens in order, with arrows, so the developer sees the journey.
4. **Each screen** with its states next to it: default, loading, empty, error, long content.
5. **Numbered annotations** beside the design, with matching notes in a margin. Avoid notes scattered over the artwork.
6. **Responsive versions** at the key breakpoints, or written rules.

## Worked example: annotating a sign-up form

```text
Screen: Create account (mobile, 360 wide; desktop 1280, form max-width 400, centred)

1  Email field (Input/Default from the system)
   Validate on blur: must contain @ and a domain. Error text: "Enter an email address
   like name@example.com". Do not clear the field on error.
2  Password field (Input/Password)
   Min 8 characters, show/hide toggle (accessible label "Show password").
   Strength hint updates as the user types; it never blocks submit on its own.
3  "Create account" (Button/Primary/Medium)
   Enabled at all times. On submit with errors: focus moves to the first invalid field,
   and a summary appears above the form.
   Loading: label "Creating account...", repeat clicks ignored.
4  Server error (Alert/Error, above form)
   "We couldn't create your account. Try again in a minute." Keep entered data.
5  Success -> navigate to "Check your email" screen (frame 2.3).
Long content: error text wraps; never truncate.
Tokens: spacing between fields space-4; label to input space-1.
```

Each note says what the design cannot. Measurements and colours come from the file or Dev Mode; there is no need to repeat them, except where a rule matters (max-width 400).

## Working with engineers

- **Involve them early.** Review rough flows with an engineer before polishing. They will spot technical constraints and cheaper alternatives.
- **Walk through the design** in a short meeting at handoff rather than only sending a link.
- **Agree on naming**: component names and token names in Figma should match the code.
- **Keep one source of truth.** If a decision changes in chat, update the file and the changelog.
- **Review the build.** Check the implemented version against the spec (often called design QA) and file small, specific issues with screenshots.

## Common mistakes

- **Only the happy path.** Error, empty and loading states are part of the design.
- **Redlining every pixel** when the tool already provides it, while forgetting behaviour.
- **Unclear status.** Developers build an exploration that was never final.
- **Detached components** in final frames, so developers cannot tell which system component to use.
- **Silent changes** after handoff with no changelog.
- **Annotations on top of the artwork** that hide the design.

## Quick recap

- Handoff is a continuing conversation; specs answer questions before they are asked.
- Tools show measurements; annotations show intent: behaviour, states, edge cases, responsive and content rules.
- Organise the file with an index, ready-for-dev sections, the flow, states and numbered notes.
- Involve engineers early, match naming, keep one source of truth and review the build.

## Try it

On the Do tab you will annotate one screen from your own project for engineering.


Prepare a design for engineering with clear annotations, measurements, states and edge cases, using Figma Dev Mode or written notes.

Specs and annotations

Figma tutorial: Collaboration and handoff in Dev Mode

Design to Development Handoff

## Why it matters

You do not need to be a developer to design for the web, but being able to read HTML and CSS changes how you work. You can inspect a live page to see why it does not match the design, suggest a precise fix ("padding is 10px, the spec says 24px"), understand what is cheap or expensive to build, and make small fixes yourself in a pull request if your team allows it. Many product designer job listings ask for "a working knowledge of HTML and CSS" for exactly these reasons.

## The core idea: structure, then style

**HTML** describes structure and meaning: this is a heading, this is a button, this is a list. **CSS** describes presentation: colour, size, spacing, layout.

```html
<div class="plan-card">
  <h2 class="plan-card__title">Team plan</h2>
  <button class="btn btn--primary" type="button">Choose plan</button>
</div>
```

- Elements (`div`, `h2`, `button`) are the building blocks. The element choice matters for accessibility: a real `<button>` is focusable and works with the keyboard; a `<div>` styled like a button is not.
- `class` attributes are labels CSS uses to find elements. Names like `plan-card__title` follow a common convention (BEM: block, element, modifier), which often mirrors design-system component names.

A CSS **rule** is a selector plus declarations:

```css
.plan-card {            /* selector: elements with class plan-card */
  padding: 24px;        /* property: value; */
  border-radius: 12px;
}
```

## Properties designers adjust most

| Design idea | CSS property | Example |
|---|---|---|
| Inner spacing | `padding` | `padding: 8px 16px;` (top/bottom 8, left/right 16) |
| Outer spacing | `margin` | `margin: 0 0 16px;` |
| Corner radius | `border-radius` | `border-radius: 12px;` |
| Text size and weight | `font-size`, `font-weight`, `line-height` | `font-weight: 600;` |
| Colour | `color` (text), `background` | `color: #374151;` |
| Minimum size | `min-height`, `min-width` | `min-height: 44px;` |
| Side-by-side layout | `display: flex` and `gap` | `display: flex; gap: 8px;` |

Two concepts explain most surprises:

- **The box model.** Every element is a box: content, then padding, then border, then margin. Padding is inside the border (it gets the background colour); margin is outside.
- **The cascade.** When several rules target the same element, the more specific selector wins, and among equals the later rule wins. If your change "does nothing", another rule is probably overriding it.

## Inspecting a live page

Every desktop browser has free developer tools. In Chrome, Edge or Firefox, right-click an element and choose **Inspect**.

1. The **Elements** (or Inspector) panel shows the HTML; hover to highlight boxes on the page.
2. The **Styles** panel shows the CSS rules that apply, with overridden values crossed out.
3. The **Computed** panel shows final values and a box-model diagram with padding and margin.
4. You can edit values live to try a fix. Nothing is saved; reloading resets it.

That is how you turn "the card looks cramped" into "the card's padding is 10px; the spec is 24px (`space-4`)".

## Worked example: matching a spec

A plan card was built from a spec but looks wrong. Inspecting it shows:

```css
.plan-card { padding: 10px; border-radius: 3px; }      /* spec: 24px, 12px */
.plan-card__title { font-weight: 400; }                 /* spec: 600 */
.plan-card__badge { color: #a3a3a3; background: #fff; } /* about 2.5:1, fails 4.5:1 */
.btn { padding: 4px 12px; }                             /* about 27px tall; spec 44px */
.plan-card__actions { }                                 /* buttons should sit in a row, 8px gap */
```

Fixes:

```css
.plan-card { padding: 24px; border-radius: 12px; }
.plan-card__title { font-weight: 600; }
.plan-card__badge { color: #374151; }                   /* about 10:1 on white */
.btn { min-height: 44px; padding: 8px 16px; }
.plan-card__actions { display: flex; gap: 8px; }
```

In a real codebase these values would be tokens (`var(--space-4)`), as in the tokens lesson.

## Common mistakes

- **Fixing with a `<div>`.** If something acts like a button, it should be a `<button>`; a link that goes somewhere should be an `<a href>`.
- **Using margin for inner spacing** (or the reverse). Inside the border is padding.
- **Fixed heights on text containers.** Text grows when users zoom or translate; prefer `min-height` and padding.
- **Pixel-pushing in DevTools and forgetting to write it down.** Changes vanish on reload; record the fix in the ticket.
- **Changing shared CSS** that other components use without checking with the team.

## Quick recap

- HTML gives structure and meaning; CSS gives presentation.
- A CSS rule is a selector plus property-value declarations; the cascade decides which rule wins.
- Know the box model: content, padding, border, margin.
- Use browser DevTools (Inspect) to find the real values and propose precise fixes.

## Try it

On the Do tab you will adjust a plan card's CSS so it matches its spec: padding, radius, weight, contrast, button height and layout.


Read the HTML structure and CSS rules behind a component and adjust spacing, type, contrast and layout to match a spec.

Reading HTML/CSS as a designer

HTML & CSS 101 for designers

Mark the landmarks: banner, navigation, main, complementary (if any) and footer.

Mark every heading with its level (H1, H2, H3) based on structure, not visual size. Check there is one H1 and no skipped levels.

Number every interactive element in the order the Tab key should reach it. Include a skip link if the page has repeated navigation.

Write the accessible name for every control, especially icon-only buttons, and rewrite any vague link text such as "Click here".

Mark each image as meaningful (write its alt text) or decorative.

Write the state and announcement rules for anything that changes without a page load, and the focus behaviour for any modal, menu or error.

If you annotated a live page, test it: press Tab through it and compare the real focus order with your numbers. Note every difference.

## Why it matters

Many accessibility problems are decided before a single line of code: a reading order that jumps around, an icon-only button with no name, a modal with no defined focus behaviour, an error shown only in red. If the design does not specify these things, developers have to guess, and guesses are often wrong. **Accessibility annotations** make the invisible parts of a design explicit, so assistive technology users get the experience you intended. You covered the principles in Accessible & Responsive Interfaces; this lesson is about writing them down for handoff.

## The core idea: annotate what sighted mouse users never see

Screen reader and keyboard users experience a page as a structure and a sequence, not a picture. Annotations describe that structure and sequence. The most common categories are:

**1. Headings.** Mark each heading's level (H1, H2, H3) based on structure, not visual size. One H1 per page; do not skip levels.

**2. Landmarks.** Mark regions: header (banner), navigation, main, complementary (aside), footer (contentinfo), and search or form regions where helpful. Screen reader users jump between landmarks.

**3. Focus order.** Number every interactive element in the order the Tab key should reach it. Normally this follows visual reading order (left to right, top to bottom in English). Note anything unusual, such as a skip link first.

**4. Accessible names.** Every control needs a name a screen reader can announce. Visible labels are best. For icon-only buttons, write the name ("Close dialog", "Search"). For links, make sure the text makes sense out of context ("View invoice 1042", not "Click here").

**5. Images.** Mark each image as meaningful (write the alt text) or decorative (empty alt, ignored).

**6. States and announcements.** Specify expanded/collapsed, selected, checked, current page and error states, and what is announced when something changes without a page load ("3 results found", "Saved").

**7. Focus management.** Where focus goes when a modal opens (into the dialog, usually its heading or first control), where it returns when it closes (the button that opened it), and where it moves after an error on submit (the first invalid field or an error summary).

**8. Interaction and other details.** Keyboard behaviour for custom widgets (arrow keys in tabs), touch target sizes, reduced-motion alternatives, and text that must not be in images.

## How to annotate

Use a consistent visual language: coloured markers off to the side of the design with a numbered legend. Free annotation kits are available in the Figma Community; some, such as kits published by large companies' accessibility teams, include ready-made stamps for headings, focus order and names. Paper works too: print the screen and mark it up.

## Worked example: a search results page

```text
Landmarks:  banner (logo + nav) | search (form) | main (results) | contentinfo (footer)
Headings:   H1 "Search results for 'desk'"   H2 per result title   H2 "Filters" (visually small)
Focus order:
  1 Skip to results (visible on focus)
  2 Logo link "Home"
  3-5 Nav links
  6 Search field (label "Search products")
  7 Search button (icon-only; name "Search")
  8 Filters toggle (button; aria-expanded true/false)
  9+ Result title links, in visual order; then Pagination
Names:      Heart icon on each result: "Save Oak desk to favourites" (includes product name)
Images:     Product photos: alt = product name; decorative divider: empty alt
Announce:   After filters change: "24 results" in a polite live region
Errors:     Empty search -> message under field, linked to it; focus stays in field
```

Two details are worth noticing. The heading "Filters" is visually small, but structurally it is an H2, so it is marked H2. And the heart icon's name includes the product name; ten identical "Save" buttons would be useless to a screen reader user listing all buttons.

## Working with developers

- Hand off annotations with the visual design, not after it.
- Agree on terms: use HTML and ARIA words developers know (button, link, `aria-expanded`), but prefer native HTML over ARIA when it does the job.
- Test the build with a keyboard (Tab, Shift+Tab, Enter, Space, Esc) and a free screen reader (NVDA on Windows, VoiceOver on Mac and iOS, TalkBack on Android) and compare with your annotations.

## Common mistakes

- **Heading levels by visual size.** Structure, not style, decides the level.
- **Focus order that ignores layout changes** at mobile widths, where columns stack.
- **"Button" as a name.** Every icon-only control needs a specific name.
- **Colour-only errors.** Add text and an icon, and link the message to its field.
- **No focus plan for modals and menus.** Focus gets lost behind the overlay.
- **Annotating after build.** By then, fixing structure is expensive.

## Quick recap

- Accessibility annotations describe structure and sequence: headings, landmarks, focus order, names, images, states and focus management.
- Mark heading levels by structure, give every control a specific accessible name, and plan focus for modals and errors.
- Use a consistent legend, hand off with the design, and verify with a keyboard and a screen reader.

## Try it

On the Do tab you will annotate a screen for focus order, headings, landmarks and accessible names.


Annotate headings, landmarks, focus order, accessible names and states so accessibility is designed, not left to chance.

Accessibility specs

Essential Accessibility Annotations for a Smoother Design to Development Handoff - axe-con 2023

WCAG 2.4.3 Focus Order

Annotate screens for engineering, read and adjust real HTML and CSS, and write accessibility specs for focus order and labels.

Developer Handoff

## Why it matters

At junior level, designers are judged on the quality of their screens. At mid-level, they are increasingly judged on **outcomes**: did the redesign help people, and did it help the business? Product managers, engineers and leadership talk in metrics. A designer who can say "this change should reduce failed sign-ups, and here is how we will know" earns a seat in decisions about what gets built.

## The core idea: outputs vs outcomes

An **output** is what the team ships: a new onboarding flow. An **outcome** is the change it causes: more new users complete set-up and come back next week. Designs are bets on outcomes, and metrics tell you whether the bet paid off.

Product metrics come mostly from **analytics** (what large numbers of people do in the live product), complementing the usability metrics from small tests (task success, SUS) you met in UX Design Process. Analytics show *what* and *how many*; research shows *why*.

## The HEART framework

Google researchers Kerry Rodden, Hilary Hutchinson and Xin Fu published HEART in 2010 as a way to choose user-centred metrics. It has five categories:

| Category | Question | Example metrics |
|---|---|---|
| **Happiness** | How do people feel about it? | Satisfaction rating, SUS, Net Promoter Score |
| **Engagement** | How much do people use it? | Sessions per user per week, actions per visit |
| **Adoption** | Do new people start using it? | % of new users who try a feature in week one |
| **Retention** | Do people keep coming back? | % of users active again after 30 days |
| **Task success** | Can people do what they came for? | Completion rate, time to complete, error rate |

You do not need all five for every project. Pick the one or two that match the goal of your change.

## Goals, signals, metrics

HEART comes with a simple method to get from a vague aim to a number:

1. **Goal**: what you want to achieve for users, in words. "New users can set up a shared house quickly and without help."
2. **Signal**: what behaviour or attitude would show you are succeeding (or failing). "They finish set-up in one session; few contact support about invites."
3. **Metric**: how you will measure the signal, precisely. "% of new houses that invite at least one housemate within 24 hours; set-up support tickets per 1,000 new houses."

Write a **baseline** (today's value) and a **target** before launch, and note any **guardrail** metrics that must not get worse, such as overall retention or page speed.

## Worked example: a redesigned bill-split flow

Design change: replace the "Split equally: Yes/No" radio buttons with a "Change amounts" button and auto-reminders (from usability findings).

| HEART | Goal | Signal | Metric | Baseline | Target |
|---|---|---|---|---|---|
| Task success | People can split a bill unequally without errors | Fewer abandoned splits | % of started splits that are sent | 71% | 85% |
| Happiness | Requesting money feels less awkward | Fewer complaints, better ratings | In-app rating after first split (1 to 5) | 3.6 | 4.0 |
| Retention (guardrail) | The change does not drive people away | Users keep splitting bills | % of houses with a split in the next 30 days | 58% | not lower |

Now the design has a measurable promise. If splits sent rise but ratings fall, the team learns something too. To be confident the change caused the difference, teams often run an **A/B test**: some users see the old version, some the new, and you compare their metrics over the same period.

## Common pitfalls with metrics

- **Vanity metrics**: page views or downloads that go up without anyone being helped.
- **Gaming a metric**: optimising "time in app" by making tasks slower.
- **Too many metrics**: nobody can tell whether the change worked. Choose one primary metric.
- **No baseline**: without "before", "after" means nothing.
- **Ignoring the why**: a drop in a metric needs research to explain it.
- **Privacy**: collect only what you need, follow your organisation's data rules and never track people in ways they would not expect.

## Quick recap

- Outputs are what you ship; outcomes are the changes they cause. Metrics measure outcomes.
- HEART: Happiness, Engagement, Adoption, Retention, Task success. Pick the categories that fit the goal.
- Goals, signals, metrics turn an aim into a measurable number; add a baseline, target and guardrails.
- Pair analytics with research: numbers show what, research shows why.

## Try it

The Do tab has a quiz on choosing metrics. Afterwards, write a goals-signals-metrics table for one design change in your own project.


Connect a design change to product metrics using the HEART framework and the goals, signals and metrics method.

Product metrics for designers

The HEART Framework | Key Business Metrics | Product Design | Udacity

Goals, Signals and Metrics | Key Business Metrics | Product Design | Udacity

Write the feature name, what changed and an imagined launch date.

List two or three research questions, starting from the riskiest assumptions in your design.

Choose one primary metric and up to two guardrail metrics, each with a baseline (estimated if needed) and a target.

Plan methods week by week for four weeks, combining analytics, feedback and at least one usability or interview round.

Describe who you would recruit for research and how, and how you would get consent.

Write a decision rule for each research question: what result would make you change, roll back or keep the design.

Add a privacy note: what data you will and will not collect, and how long you would keep recordings.

Describe how you will share findings with the team and how fixes will be prioritised.

## Why it matters

Launch is not the end of design. It is the first time you see your design used by real people, at real scale, with real data and real distractions. Some of your assumptions will be wrong. Teams that keep learning after launch improve the product steadily; teams that move straight to the next project leave known problems in place for years. Planning post-launch research is a normal part of a mid-level designer's job.

## The core idea: build, measure, learn, repeat

Iterative design is a loop: ship a version, measure what happens, learn why, and improve. After launch, you have three kinds of evidence:

| Source | Tells you | Examples |
|---|---|---|
| **Analytics** | What is happening and how often | Funnel drop-off, feature adoption, errors logged |
| **Feedback** | What people say | Support tickets, app store reviews, in-app surveys |
| **Research** | Why it happens | Usability tests on the live product, interviews, session observation |

None is enough on its own. A funnel shows that 40% of people drop off at step 3; it does not say why. A usability session shows why, but not how common the problem is. Combine them: use analytics to find *where* to look, research to understand *why*, and analytics again to check whether the fix worked.

## Planning a post-launch study

Write a short plan before launch (or as soon as possible after):

1. **Questions.** What do you need to learn? Start from the risks and assumptions you made during design. "Do people find 'Change amounts' without help?" "Are reminders seen as helpful or annoying?"
2. **Metrics to watch**, with the baseline and target you set (previous lesson), plus guardrails.
3. **Methods and timing.** For example:
   - Week 1: watch analytics daily for errors and big drop-offs; read every support ticket mentioning the feature.
   - Week 2: a short in-app survey after the first use (one or two questions).
   - Weeks 2 to 3: five moderated usability sessions with real users on the live product, focused on the riskiest task.
   - Week 4: review all evidence and decide on changes.
4. **Participants.** Who you will recruit and how (for example, an opt-in link in the app for people who used the feature).
5. **Decision rules.** What would make you change, roll back or keep the design. "If sent splits stay below 80% after four weeks, revisit the edit-amount step."
6. **Sharing.** How findings reach the team: a short readout, a prioritised list in the backlog.

## Worked example: a post-launch plan

```text
Feature: Bill split v2 ("Change amounts" + auto reminders). Launch: 3 March.
Questions:
  Q1 Do people find "Change amounts" without help?
  Q2 Do reminders reduce chasing, or annoy housemates?
Metrics: splits sent / started (baseline 71%, target 85%);
         reminder opt-outs per 100 houses (guardrail: below 10);
         30-day house retention (guardrail: not lower than 58%).
Methods:
  Wk 1   Daily funnel check; tag support tickets "split" and "reminder".
  Wk 2   One-question survey after first split: "How easy was it to split this bill?" (1-7)
  Wk 2-3 5 moderated sessions on the live app with opted-in users who split a bill
         in the last week; tasks: unequal split, turn off reminders.
  Wk 4   Synthesis workshop; decide changes.
Decision rules: below 80% sent at week 4 -> redesign edit step;
                opt-outs above 10 per 100 -> make reminders gentler or less frequent.
Privacy: only aggregated analytics; session participants give consent; no recordings
         kept beyond 90 days.
```

## Prioritising what you learn

After a study you will have more problems than time. A simple way to prioritise is to rate each issue by **impact** (how many people, how badly) and **effort** (how hard to fix), then do high-impact, low-effort fixes first. Keep a visible list so issues are not forgotten, and repeat the loop.

## Common mistakes

- **No plan until something breaks.** Decide what you will measure before launch.
- **Only looking at numbers.** You will see problems you cannot explain.
- **Only reading reviews.** People who write reviews are a loud, unrepresentative minority.
- **Changing several things at once.** You cannot tell which change helped.
- **No decision rules.** Without them, every result is "interesting" and nothing changes.
- **Collecting more data than needed.** Respect privacy and your organisation's data policies.

## Quick recap

- Launch is the start of learning; iterate with a build, measure, learn loop.
- Combine analytics (what), feedback (what people say) and research (why).
- A post-launch plan lists questions, metrics, methods and timing, participants, decision rules and how findings are shared.
- Prioritise fixes by impact and effort, and keep the loop going.

## Try it

On the Do tab you will write a post-launch study plan for a feature from your own project.


Plan a post-launch study that combines analytics, feedback and usability research to decide what to improve next.

Iterating after launch

Usability Testing w. 5 Users: Design Process (video 1 of 3)

UX Benchmarking vs. UX Success Metrics

Set a 45-minute timer and start a recording on your phone (audio is enough) so you can review yourself.

Spend the first 5 to 10 minutes writing clarifying questions. If you have a partner, ask them; if not, write your assumptions down and say them aloud.

Choose a primary user and write a one-sentence problem statement. Say how you would validate it with research in real life.

Sketch at least three different approaches and say one trade-off for each.

Choose one approach and sketch its key flow plus two or three screens, including one error or empty state and one accessibility consideration.

State a primary success metric and one guardrail metric.

Wrap up in two minutes: problem, solution, risks and what you would test first.

Listen back to the recording and note where you went silent, skipped clarifying, or jumped to screens.

Write one paragraph for each of your two strongest case studies that states your role, one key decision and its outcome, ready to use in an interview.

## Why it matters

Moving from junior to mid-level product designer is less about prettier screens and more about showing judgement: framing problems, working with constraints, collaborating with engineers and product managers, and connecting design to outcomes. Interviews test exactly these things, usually through a **portfolio presentation** and a **design challenge** (a whiteboard exercise or a take-home task). Preparing for both is a skill you can practise.

## What a mid-level portfolio shows

A junior portfolio proves you know the process. A mid-level portfolio proves you can use it in messy, real situations. Aim for two or three strong case studies rather than eight thin ones, and make sure they show:

- **Problem framing**: how you understood and sometimes challenged the brief.
- **Trade-offs**: what you chose not to do, and why (time, technical limits, business needs).
- **Collaboration**: how you worked with engineers, PMs, researchers and stakeholders.
- **Systems thinking**: how your work used or improved a design system (tokens, components, specs).
- **Craft and accessibility**: polished, accessible detail where it matters.
- **Outcomes**: metrics or research results, with honest sample sizes (the HEART and post-launch lessons give you the language).
- **Your role**: what *you* did, clearly separated from the team's work.

## The portfolio presentation

Many interview loops include a 30 to 45 minute presentation of one or two projects. A reliable structure for each project:

1. **Context** (1 to 2 minutes): product, users, your role, team, timeline.
2. **Problem** (2 minutes): what was wrong and how you knew.
3. **Process and key decisions** (8 to 12 minutes): two or three decisions, each with evidence, options considered, trade-offs and the result.
4. **Outcome** (2 minutes): what changed, with numbers if you have them.
5. **Reflection** (1 to 2 minutes): what you would do differently.

Rehearse out loud and time it. Leave time for questions; interviewers learn most from your answers to "why?" and "what would you do if...?".

## The design challenge

In a live challenge you get a short prompt, such as "Design a way for library members to avoid late fees", and 45 to 60 minutes. Interviewers are watching how you think, not whether you produce a perfect design. A dependable structure:

1. **Clarify (5 to 10 min).** Ask questions before drawing. Who are the users? What is the business goal? What platform? Any constraints? What does success look like? If the interviewer says "you decide", state your assumptions out loud.
2. **Users and problem (5 to 10 min).** Pick a primary user and their key need. Write a problem statement. Mention how you would validate it with research in real life.
3. **Explore (10 min).** Sketch several approaches quickly and talk through the trade-offs.
4. **Choose and detail (15 min).** Pick one, sketch the key flow and two or three important screens, including at least one edge case (an error or empty state) and an accessibility consideration.
5. **Measure (5 min).** Say how you would know it worked: a primary metric and a guardrail.
6. **Wrap up (5 min).** Summarise the problem, the solution, risks and what you would test first.

Talk the whole time. Silence makes it impossible for interviewers to see your reasoning.

## Worked example: the first five minutes

Prompt: "Design a feature to help housemates share chores."

Good clarifying questions: "Is this a new app or a feature in an existing house-sharing app? Mobile? Are we optimising for fairness, fewer arguments, or less effort to organise? Are there constraints, like no notifications? How would the business measure success?"

Stated assumptions: "I'll assume an existing mobile app, the primary user is the person who currently organises chores, and success means fewer chores missed. In real life I'd check this with five interviews before designing."

Then the problem statement: "House organisers need a fair rota that runs itself, because chasing people causes friction." The rest of the session builds on that.

## Take-home challenges

Some companies set a take-home task instead. Ask how long it should take and stick to it. Present your process and reasoning, not just final screens. Be cautious about very large unpaid tasks; it is reasonable to ask how the work will be used.

## Common mistakes

- **Jumping straight to screens** without clarifying the problem.
- **Designing for everyone.** Pick a primary user.
- **One idea only.** Show you explored alternatives.
- **Ignoring edge cases and accessibility.**
- **No success measure.**
- **Saying "we" throughout** so your own contribution is invisible.
- **Overrunning** the presentation time.

## Quick recap

- A mid-level portfolio shows framing, trade-offs, collaboration, systems thinking, craft and outcomes, with your role clear.
- Present each project as context, problem, key decisions, outcome and reflection, and rehearse with a timer.
- In design challenges: clarify, define user and problem, explore, detail, measure and wrap up, thinking aloud throughout.

## Try it

On the Do tab you will practise a timed design challenge and refine your answer.


Present a mid-level portfolio and answer a design challenge with a clear, structured approach.

Mid-level portfolio and interviews

Presenting Your UX Case Study in an Interview

Whiteboard challenge live demo (UX or product design)

Tie designs to product metrics, plan research after launch, and prepare a mid-level portfolio and design challenge.

Design Systems & Developer Handoff

About this course

Course content

Design Systems

Developer Handoff

Product Design Practice

Where this course leads

Careers that use it