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

Design Systems & 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.