Showing 16 exercises
| Exercise | Phase | When to use | How to run it | Templates & tools |
|---|---|---|---|---|
| Stakeholder interviews | Discover | Project kick-off, before any user research | 30–60 min semi-structured conversations with business owners, PMs, and commercial leads. Surface assumptions, business constraints, and success metrics. Run before user work so you understand what the business believes vs what users actually need. | Research plan: Figma official |
| User interviews | Discover | Discovery phase; also continuously alongside delivery | 5–8 participants, 45–60 min each. Semi-structured guide around context, behaviours, and pain points; never show the product. Record and transcribe. Look for patterns across sessions, not individual quotes. | User interview questions: Figma official |
| Competitive audit | Discover | Early discovery; before defining scope | Review 4–8 competitors or analogous products. Document onboarding, core flows, UI patterns, and tone. Use a scoring matrix. Identify gaps in the market, not just what others do. | Competitor analysis: Figma official |
| Affinity mapping | Define | Immediately after a round of interviews or testing | Transfer observations to sticky notes (one per note). Working silently, cluster by theme. Name each cluster. Works best with 3–6 people who all attended the sessions. Produces a shared understanding of patterns across a team. | Affinity diagram: Figma official |
| Empathy mapping | Define | After interviews, before persona synthesis | 4-quadrant canvas: Says, Thinks, Does, Feels. Populate from research data as a team. Surfaces contradictions: what users say versus what they actually do. Useful for aligning a cross-functional team on user reality before moving to solutions. | Empathy map: Figma official |
| Persona creation | Define | After synthesis of research, before design sprint | Build 2–4 research-grounded personas (not marketing demographics). Include goals, frustrations, context of use, and key behaviours. Avoid fictional details; anchor every attribute to a data source. Use as a decision-making shorthand throughout delivery. | User persona: Figma official |
| JTBD canvas | Define | After interviews; when defining product scope or positioning | Map the functional, social, and emotional "jobs" users hire the product to do. Use the format: "When I [situation], I want to [motivation], so I can [outcome]." Run as a team workshop; it surfaces competing interpretations of the core problem. | Jobs to be done: Figma official |
| Current-state journey map | Define | After research, before ideation: map the as-is experience | Plot user steps, touchpoints, thoughts, emotions, and pain points across the existing journey (not your product itself, but the task). Use research data to populate. The emotional curve is often more useful than the step list. | Customer journey map: Figma official |
| How Might We (HMW) | Design | Transition from problem to solution space | Reframe pain points as opportunity questions: "How might we make it easier for users to…?" Generate 10–20 HMW statements, then dot-vote to prioritise. Keeps the team in problem mode long enough before jumping to solutions. Works well in a 60–90 min workshop. | Brainstorming templates: Figma official |
| Card sorting | Design | When designing navigation, IA, or category structures | Open sort: participants group items any way they like, then name groups; this reveals mental models. Closed sort: participants place items into predefined categories, testing your proposed IA. Run with 15–30 participants for quantitative signal. Use Maze, Optimal Workshop, or UserZoom for remote. | Card sorting tool: Figma official |
| Future-state journey map | Design | After initial concepts; to align teams on intended experience | Map the ideal experience your product should deliver, using the same structure as the current-state map. Useful for aligning stakeholders on vision before detailed design begins. Flag where the product directly intervenes in the current-state pain points. | Customer journey map: Figma official |
| Moderated usability testing | Validate | At any fidelity, from wireframe through to live product | 5 participants per round (per Nielsen's law). Give realistic task scenarios, never instructions. Observe without intervening. Debrief observers immediately after each session. Use think-aloud protocol. Identify failure points, not just opinions. | FigJam UT template: by Figma's research team |
| Heuristic evaluation | Validate | When user testing isn't possible, or as a pre-test screen | 2–5 evaluators review the design against Nielsen's 10 heuristics (or platform-specific principles). Each works independently, then results are consolidated and severity-rated (0–4). Quick and cheap; it catches 75–80% of usability issues without users. Best combined with real user testing. | Heuristics evaluation board: Nielsen's 10 principles (FigJam) |
| A/B testing | Post-launch | When you have sufficient traffic and a clear hypothesis | Run controlled experiments on a single variable (copy, layout, CTA). Requires significant traffic for statistical significance, typically 1,000+ conversions per variant. Define the primary metric before launching. Avoid running too many concurrent experiments on the same users. | A/B test planner (FigJam) |
| Funnel & behavioural analytics | Post-launch | Continuously, especially after launch and after changes | Track drop-off rates across key flows. Identify where users abandon tasks. Use session recordings (FullStory, Hotjar) to see specific failure moments. Analytics tells you what is happening; pair with qualitative research to find out why. | Tagging map: analytics tracking visualised (FigJam widget) |
| NPS / CSAT survey | Post-launch | Ongoing: track sentiment over time after releases | NPS (0–10 likelihood to recommend) gives a directional benchmark. CSAT (1–5 satisfaction per task) gives feature-level signal. Neither tells you why; always include an open text field and follow up qualitatively with outliers. Run on a fixed cadence to spot trends. | Likert scale: Figma official |