What is a design whiteboard challenge?
The whiteboard challenge (also called the app design challenge, design exercise or product design interview) is a live round in many UX and product designer interview loops. You get a deliberately open prompt like “Redesign a smart lock” or “Design an alarm clock for blind people”, then work through it out loud while an interviewer watches, answers your questions and pushes back.
It runs 30 to 60 minutes, in person on a whiteboard or remotely on a shared canvas. The drawing matters less than people expect. The round exists to show how you think when nobody has handed you a brief: whether you ask before you assume, commit to one user and one problem, weigh options, and end with something you could test.
Looking for prompts to practice with? We keep a list of whiteboard challenge examples reported at Meta, Apple, Google, Amazon and other companies.
What interviewers score
Companies don't publish their rubrics, but interview guides and candidate reports describe the same themes. ZeroBoard's review turns them into 6 weighted areas. Each is rated on four levels (Missing, Surface, Solid, Hire-level) and combined into a score out of 100.
| Area | Weight | What hire-level looks like | Scored in |
|---|---|---|---|
| Framing | 20% | Reframes the prompt and cuts scope using what they learned | Full loop and warm-up |
| User & problem | 20% | Justifies the user choice and says who is excluded | Full loop and warm-up |
| Ideas & trade-offs | 15% | Picks using the user and metrics, and names what's lost | Full loop only |
| Flow & detail | 20% | Covers errors, offline, accessibility and repeat use | Full loop only |
| Success & impact | 10% | Adds a guardrail and a plan to test | Full loop and warm-up |
| Communication & time | 15% | Explains decisions throughout and finishes on time | Full loop and warm-up |
Score bands: 85+ hire signal, 65+ interview-ready, 40+ getting there, under 40 not yet.
A minute-by-minute plan for 45 minutes
The most common failure is time: strong designers spend 30 minutes on screens and never define success, or frame beautifully and never draw. A fixed budget per stage prevents both. Roughly a third of the time goes to framing, before you draw anything.
| Stage | The question it answers | Time |
|---|---|---|
| 01 · Frame | What exactly am I being asked to design? | 2 min |
| 02 · Context | What's true about the situation? | 4 min |
| 03 · User | Who exactly am I designing for? | 3 min |
| 04 · Problem | What is my user's problem? | 3 min |
| 05 · Constraints | What limits am I working within? | 2 min |
| 06 · Success | How will I know it worked? | 2 min |
| 07 · Journey | What does my user go through, start to finish? | 5 min |
| 08 · Ideas | What could I build, and which one do I pick? | 5 min |
| 09 · Flow | What does my pick look like, screen by screen? | 13 min |
| 10 · Wrap | What did I decide, and what comes next? | 6 min |
| Total | Framing 16 min · Solving 29 min | 45 min |
Short on time? The first 6 stages make a 15-minute warm-up with no drawing. It trains the part most candidates rush.
The 10 stages, one by one
Each stage answers one question, so you never do the same work twice. The worked example uses a prompt that isn't in our practice library: “Design an app for visiting a museum.”
Framing: stages 1 to 6
Stage 1 · Framing · 2 min
Frame the prompt
“What exactly am I being asked to design?”
Say the prompt back in your own words, then list the words that could mean more than one thing.
Watch out: Don't choose a user or a metric yet. You'll do that in User and Success, once you've asked questions.
Ask yourself
- Which words could mean several things?
- Is this a redesign or something new?
- Is it a whole product, or one part of one?
Worked example · “Design an app for visiting a museum.”
- Your restatement
- Help people get more out of a museum visit with their phone. Unclear: 'visiting' (before, during or after?), 'app' (does it have to be one?), and which museum.
Stage 2 · Framing · 4 min
Clarify the context
“What's true about the situation?”
Ask the interviewer about the company, the people who use it, and what exists today. Write down what they tell you.
Watch out: Only facts go here. Your own guesses go in Constraints, and the group you choose to design for goes in User.
Ask yourself
- Who is the company, and what is the business?
- Who uses this, and how often?
- Why does this matter now?
- What device or setting is it used in?
- What exists today?
Worked example · “Design an app for visiting a museum.”
- What you learned
- A large city art museum. Most visitors are first-time tourists, and most leave within an hour. Today there is a paper map and an audio guide to rent. Phone signal inside the galleries is weak.
Stage 3 · Framing · 3 min
Pick one user
“Who exactly am I designing for?”
List everyone involved, choose one group to design for, and say who you are leaving out.
Watch out: If the prompt already names a group, narrow it: which of them, and in what situation? 'Nurses' becomes 'night-shift nurses on a busy ward'.
Ask yourself
- Who is affected?
- Which group has the sharpest pain?
- If the prompt names a group, which of them exactly?
- Who is out of scope for now, and why?
Worked example · “Design an app for visiting a museum.”
- People affected
- First-time tourists, members, families, school groups, gallery staff
- Primary user
- First-time tourists with about two hours
- Why this user
- They are most of the visitors, and the ones who leave early
- Out of scope for now
- School groups, who come on guided tours, and tools for staff
Stage 4 · Framing · 3 min
Name the problem
“What is my user's problem?”
Describe what your user is trying to get done and what gets in the way, then write one problem statement.
Watch out: Describe the problem, not a fix. Solutions come later, in Ideas.
Ask yourself
- What is the user trying to get done?
- What goes wrong today?
- Can you phrase it as "How might we…"?
Worked example · “Design an app for visiting a museum.”
- What gets in the way today
- They want to see the famous works in the time they have, but they get lost, can't tell what's worth seeing, and queue for the audio guide.
- Problem statement
- How might we help first-time visitors find what's worth seeing in two hours without getting lost?
Stage 5 · Framing · 2 min
Set constraints
“What limits am I working within?”
Write down the limits your design has to respect, and any assumptions you're making where the interviewer left it to you.
Watch out: Every assumption belongs here, so the interviewer can see and challenge it.
Ask yourself
- What did the interviewer leave up to you?
- Technical limits?
- Accessibility needs?
- Privacy, safety or legal rules?
- Time or cost limits?
Worked example · “Design an app for visiting a museum.”
- Constraints and assumptions
- Weak signal in the galleries · Must work for visitors with low vision or hearing loss · No new hardware in the building · Assumption: tourists won't install an app for one visit
Stage 6 · Framing · 2 min
Define success
“How will I know it worked?”
Pick one user outcome, one business metric, and one guardrail: something that must not get worse.
Watch out: Choose things you could actually measure after launch.
Ask yourself
- How is the user's life better?
- Which number would the business watch?
- What must not get worse?
Worked example · “Design an app for visiting a museum.”
- User outcome
- Visitors see the works they came for
- Business metric
- Share of visitors who come back within a year
- Guardrail
- Crowding at the most famous works doesn't get worse
Solving: stages 7 to 10
Stage 7 · Solving · 5 min
Map the journey
“What does my user go through, start to finish?”
List the steps of the experience, then mark the one or two moments worth designing.
Watch out: Steps, not screens. You draw screens in Flow.
Ask yourself
- What happens before, during and after?
- Where is the pain sharpest?
- Which moment would you design first?
Worked example · “Design an app for visiting a museum.”
- Steps of the experience
- Arrive · Get oriented (focus) · Walk the galleries · Find a highlight (focus) · Take a break · Leave
Stage 8 · Solving · 5 min
Explore ideas
“What could I build, and which one do I pick?”
Rough out two or three genuinely different directions, compare them against your user and metrics, and pick one.
Watch out: Keep each idea to a sentence. The detail goes in Flow.
Ask yourself
- What are very different ways to solve this?
- How does each do against your metrics?
- What do you give up with your pick?
Worked example · “Design an app for visiting a museum.”
- A · Personal route
- Pick your interests and get a walking route
- B · Scan a label
- Scan any artwork's label to open a web page about it, no install
- C · Highlight tours
- Short tours led by staff every half hour
- Why this one
- B: no install and works on weak signal, which fits first-time tourists. We give up a personal route.
Stage 9 · Solving · 13 min
Draw the flow
“What does my pick look like, screen by screen?”
Draw the chosen idea end to end on the board, including the states where things go wrong.
Ask yourself
- What does the user see first?
- What happens when something fails?
- Does it work offline and with assistive tech?
Worked example · “Design an app for visiting a museum.”
- On the board
- Scan the code at the entrance → choose 'I have 2 hours' → map of 8 highlights → artwork page with audio
- Flow notes
- Offline: pages saved at the entrance. Lost: show the nearest room number. Low vision: large text and audio.
Stage 10 · Solving · 6 min
Wrap up
“What did I decide, and what comes next?”
Recap the problem, your decision and its trade-offs. Then say how you'd test it and what comes next.
Ask yourself
- Can you say it in 30 seconds?
- What would you test first?
- What would version 2 add?
Worked example · “Design an app for visiting a museum.”
- Recap
- For first-time tourists short on time, I designed a no-install guide you open by scanning a label. It trades a personal route for zero setup.
- How you'd test it first
- Watch 10 visitors use a paper version at the entrance
- What version 2 adds
- Save favorites and get a return-visit offer
Seven mistakes that sink strong designers
- Drawing screens in the first five minutes. Framing you never said out loud can't be scored. Restate the prompt and ask questions first.
- Designing for everyone. “Users” is not a user. Pick one group in one situation, and say who you're leaving out and why.
- Treating the interviewer as an audience. They're your source. Most prompts hide context (who, when, what's broken) that you only get by asking.
- No way to measure success. Name one user outcome, one business metric and one guardrail, something that must not get worse.
- Only the happy path. Show what happens on errors, empty states, a weak connection and with assistive tech.
- Falling in love with the first idea. Sketch two or three different directions in a sentence each, then pick one and say what you gave up.
- Running out the clock. Save the last five minutes to recap the decision, the trade-offs and how you'd test it.
Edge cases to cover in your flow
Interviewers notice when the flow only works on a sunny day. Before you wrap up, check your flow against each of these:
- Errors and failures
- Empty and first-time states
- Offline or slow connection
- Accessibility
- New vs. returning users
- Privacy, safety and permissions
How to practice
Reading about the whiteboard round helps less than doing it. Practice with prompts you haven't seen, on a timer, out loud, and have someone (or something) hold facts back until you ask.
Practice the round free on ZeroBoard
A 45-minute full loop with a drawing canvas, or a 15-minute warm-up that works on your phone. The AI interviewer answers only what you ask. The review scores your notes, questions and board across 6 areas and lists the facts you missed. Stuck on a real prompt? Paste it into Breakdown for a full worked answer.
Frequently asked questions
How long is a design whiteboard challenge?
Usually 30 to 60 minutes, and 45 is common. A workable split for 45 minutes: about 16 minutes framing the problem, 23 minutes on the journey, ideas and flow, and 6 minutes to wrap up.
What do interviewers look for in a whiteboard challenge?
How you think, more than what you draw. They watch whether you clarify the prompt, pick a specific user, name a real problem, compare options, handle failure states, define success and explain your decisions as you go.
Do I need to be good at drawing?
No. Boxes, arrows and short labels are enough. Nobody scores fidelity. What counts is whether someone else could follow the flow, including what happens when something goes wrong.
How does a remote whiteboard challenge work?
The same way, on a shared canvas such as FigJam, Miro or Excalidraw. Get comfortable with the tool before the interview so you are not fighting it on the clock, and keep talking while you draw because the interviewer cannot see your face as easily.
What if I don't know the product or industry in the prompt?
That's normal, and often deliberate. Ask the interviewer: who uses it, what exists today, what's broken. Interviewers usually hold back context on purpose to see whether you ask for it.
How is a whiteboard challenge different from a take-home design exercise?
A take-home gives you days and judges the finished output. The whiteboard challenge gives you under an hour and judges your reasoning in real time: the questions you ask, the trade-offs you make and how clearly you explain them.
How can I practice the whiteboard challenge on my own?
Run full rounds on the clock with a prompt you haven't seen, out loud. ZeroBoard does this for free: a timed 45-minute round with an AI interviewer who only answers what you ask, then a scored review across 6 areas.