The UCD Challenge
A game of design, delivery & difficult decisions
Game board
Overview
Roles
Mechanics
Debrief
Players & roles
User Researcher
R
R
Content Designer
D
Interaction Designer
D
Service Designer
D
Product Manager
P
Delivery Manager
P
Business Analyst
R
Session timer
60:00
Time's up! Proceed to the Debrief tab. A penalty of −3 DP has been applied for each phase not completed.
Scores — hidden until gate
Scores hidden during play
— —
Tokens
Select a step on the board above to display its card.

Board structure

Discovery
2 scenarios + event + gate
Alpha
2 scenarios + event + gate
Beta
2 scenarios + event + gate
Live
2 scenarios + event + gate
Review
Scores revealed

Game objective

Your team is developing a digital health service during a live outbreak. Players must reach the Review phase having both hit delivery milestones and genuinely served user needs — while navigating the ethical and privacy implications of AI-generated advice drawn from location, contacts, and wearable data.

A high Delivery Progress score with a low Service Quality score is a valid and intentionally uncomfortable outcome. The debrief makes it useful.

There is no win or lose. The scores create the conditions for reflection.

Turn sequence (per scenario)

  1. Reveal the scenario card for the current step on the game board
  2. The facilitator reads it aloud
  3. Each player whose role is triggered states their perspective. If the Product Manager chooses to use their ability, they call a silent vote now — each triggered player sends D (delivery-focused) or Q (quality-focused) privately via back channel, and all votes are read aloud simultaneously. Any other triggered player wishing to use their ability also declares it now. Abilities may only be used once per game.
  4. The team discusses and agrees a response (2 to 3 minutes)
  5. The facilitator reveals the resolution paths. Click the chosen path to apply its scores and log the decision.
  6. Each phase contains 2 scenarios, 1 event, and 1 gate. After the first scenario, click the Event card and resolve it, then complete the second scenario, then click the Phase gate.
  7. If the gate is passed, advance to the next phase on the board

Session timing

The session runs against a 60-minute countdown timer on the game board. The facilitator starts it once the brief has been read and roles assigned. If the team does not reach the Review step within 60 minutes, a penalty of −3 DP per incomplete phase is applied automatically when time expires.

PartExpected timeNotes
Setup & brief5–10 minFacilitator reads brief, assigns roles, sends pressures privately — start the timer once play begins
Scenario cards (×8)5–7 min each
40–56 min total
Read aloud, triggered roles respond, team discusses, path chosen
Event cards & gates (×8)~1 min each
~8 min total
No team discussion required; facilitator resolves and advances
Debrief20–30 minSee Debrief tab for guide and questions — run after gameplay regardless of whether Review was reached
Aim for 5–7 minutes per scenario. The 60-minute session timer creates the pressure — name it if discussions are running long. If the group stalls, remind them that unfinished phases carry a penalty.
If time expires before Review, go straight to the Debrief tab. The penalty is applied automatically. The incomplete run still produces enough scenario decisions for a meaningful debrief.

Phase gates

Discovery to Alpha
Have we found out enough to build something?
Check the current SQ score. If SQ is below 1, the discovery evidence base is too thin: remove 1 Research token and 1 Design token from the Alpha starting allocation. If SQ is 1 or above, advance to Alpha with full token allocation.
Alpha to Beta
Is there enough to build on?
Check whether the team has spent at least 1 Research token during this phase. If fewer than 1 Research token was spent, the evidence base is too thin: remove 1 Research token and 1 Design token from the Beta starting allocation. If the threshold is met, advance to Beta with full token allocation.
Beta to Live
Is the service ready for wider use?
SQ must be at least half of DP (SQ ≥ DP ÷ 2). If the threshold is met, advance to Live with full token allocation. If not, remove 1 Design token and 1 Research token from the Live starting allocation before proceeding.
Live to Review
Is quality high enough to launch?
No gate. The team always enters Review. This is intentional — the question is answered by the scores themselves.

Player roles

Each player holds one role card. The ability is shared knowledge — read it now so everyone understands what each role can contribute. Each role also has a private pressure: a default instinct that is realistic rather than a flaw. Pressures are not listed here; they are given to each player individually before the session begins (facilitators can access these near the bottom of the brief). The tension between ability and pressure is the game.

When abilities can be used: Each player may use their ability once per game, and only during a scenario card on which their role is listed as triggered. The ability must be declared before the team chooses their approach. If your role is not triggered on a card, you contribute to the discussion but your ability is not available. Choose your moment carefully.

User Researcher
Ability: When triggered: insist on an extra research round before the team chooses their approach. This adds +1 SQ but costs -1 DP. Once per game.
Content Designer
Ability: When triggered: reframe the communication or information challenge in the scenario. If used, remove 1 SQ penalty point from any SQ penalty incurred this scenario. Once per game.
Interaction Designer
Ability: When triggered: walk through what the user experience of the current situation looks like step by step. The team must identify one concrete user harm before proceeding. If the team addresses the root cause, the chosen approach gains +1 SQ. If not, they must name the user harm they are accepting and the facilitator records it. Once per game.
Service Designer
Ability: When triggered: identify one handoff point where this scenario's outcome will affect another team, another phase, or another user group, and name the risk to that handoff. If the team addresses the root cause, the chosen approach gains +1 SQ. If not, they must spend a token to document the handoff risk before moving on. Once per game.
Product Manager
Ability: When triggered: call a silent vote before any discussion begins. Ask each triggered player to send their vote privately via back channel — D for delivery-focused, Q for quality-focused. Read all votes aloud simultaneously. The result does not determine the resolution path but makes hidden preferences visible before discussion starts. Once per game.
Delivery Manager
Ability: When triggered: borrow from the next phase's token allocation to push progress. This adds +2 DP but reduces next phase's starting tokens by 2. Cannot be used in the Live phase. Once per game.
Business Analyst
Ability: When triggered: ask one clarifying question about scope, evidence, or impact that must be answered before the team proceeds. If the answer changes anyone's stated preference, the chosen approach gains +1 SQ. Once per game.
The game works best with all seven roles represented. Do not run with fewer than 4 players as the multi-role resolution mechanic breaks below that.

Each player starts each phase with a token allocation. Tokens represent bandwidth and are spent to resolve scenarios or activate abilities. Each ability can only be used once per game, and only during a scenario on which your role is triggered. Abilities must be declared before the team chooses their approach.

Token typeHeld bySpend effect
Research (R)User Researcher (2), Business Analyst (1)Required for any resolution that involves user evidence. Spent once per card.
Design (D)Content Designer (1), Interaction Designer (1), Service Designer (1)Required for usability, content, or design quality resolutions.
Progress (P)Product Manager (1), Delivery Manager (1), Business Analyst (1)Required for unblocking decisions, accelerating progress, or overriding gates.
Tokens reset at the start of each phase. Unused tokens do not carry over. The Delivery Manager's borrowing ability pulls from next phase's allocation — track this explicitly, and note it cannot be used in the Live phase.

Each scenario card has two or three resolution paths. Before the team chooses a path, triggered players state their perspective and may declare their ability. The Product Manager may call a silent vote at this point. Once all abilities have been used or waived, the team agrees a path and the facilitator reveals the resolution panel. Click the chosen path on the game board to apply its scores and log the decision.

PathTypical tendencyScore effectWhen to use
Path AHigher token costTypically +SQ, sometimes −DPTeam takes time to address the root cause
Path BModerate token costTypically balanced or +DPTeam finds a workable middle ground
Path CLower or no token costTypically +DP, risk of −SQTeam deprioritises quality to hit the milestone
Exact token costs vary by card and are shown on each resolution path. Path A is not always the "right" answer — it depends on the scenario and the team's situation.

Scoring

Two separate running totals. Both visible throughout the game on the session tracker. Scores can go negative.

Final scores (Review phase)Outcome labelDebrief tone
Both high (within 4 points)Sustainable deliveryWhat made this possible? What nearly derailed it?
DP high, SQ low (gap over 6)Delivered, but at a costWho got hurt? What did we skip and why?
SQ high, DP lowHigh quality, real costThe service quality is strong. The delivery pace reflects the choices you made. Which of those choices do you stand behind, and which would you revisit?
Both lowProgramme in troubleWhere did we lose control? What would we do again?

Session summary

No resolution paths have been chosen yet. Play some scenarios, then return here.

Debrief guide

Allow 20 to 30 minutes. The facilitator does not summarise or interpret. Ask the questions and let the team lead.

Opening question

What moment in the game felt most like something that has actually happened to you?

On role pressure

This is the moment pressures become visible to the group for the first time. Each player: describe the instinct your role gave you. When did it work against the team? When did it help? Was it a fair representation of how that role behaves in practice?

On other roles

What did you learn today about what another role is actually dealing with? What would you do differently to support them on a real project?

On the Business Analyst

When did the Business Analyst's instinct to define before deciding help the team? When did it slow you down?

On the scores

Look at where Delivery Progress and Service Quality diverged. What decision caused the gap? Was it the right call at the time?

Closing question

Name one concrete thing you will do differently on your next project.

Facilitator notes

  • Do not allow a single player to dominate scenario resolution. Name the rule: two or three roles must contribute.
  • The delivery manager and product manager will often favour Path B or Path C. Let them, then debrief it.
  • The Business Analyst will often want more time to clarify requirements. Watch for whether the team uses this productively or as avoidance.
  • Keep the resolution paths hidden until the team has agreed their approach. Use the toggle on the game board.
  • Some scenario cards include a "Note for facilitator" that references a decision made in an earlier card. Because scenarios are randomly selected, the referenced card may not have appeared this session — use your judgement about whether the note is relevant, and skip it if not.
  • Aim for 5–7 minutes per scenario. The 60-minute session timer creates collective pressure — name it if discussions are running long. Remind players that incomplete phases carry a −3 DP penalty.
  • Do not intervene in decisions, even clearly bad ones. The discomfort is the learning.
  • After a full run, ask players which scenario they want to replay differently.
  • The session summary above records which resolution path was chosen for each scenario — use it as your debrief data.