Decisions

Using situations in decisions

Decisions helps teams identify whether Situations is the right place to be working and, once they are, which part of the block will be most useful given their situation. It is designed to be scanned quickly — find the situation that matches, follow the guidance, and move forward.

When to use Situations

Situations is the right place to be when signals exist but the conditions creating them are not yet clear, when the same friction keeps appearing across different users and sessions without a shared explanation, or when the team is ready to move into Measure but cannot yet name what they would be testing.

If the team is reacting to individual data points rather than seeing recurring conditions, Situations is almost always the right place to begin.

Recognizing Your Situation

1. We have signals but can't see a pattern

The team has collected data from multiple sources — analytics, usability findings, interviews, support tickets — but the signals are not pointing in a consistent direction. Everyone is drawing different conclusions from the same evidence.

What to do: Start with Techniques. Apply at least two lenses to the same set of signals and look for convergence. The four lenses — By Type, By Time, By Stage, By Engagement — each reveal a different layer of context. A pattern that is invisible through one lens often becomes visible when a second lens points to the same condition. Use the signal-to-situation mapping table in References to check what the converging signals typically indicate.

2. We can see the pattern but can't name the situation

Signals are converging. The team can see that something is recurring, but they cannot agree on what the situation actually is or how to describe it in a way that would guide a design response.

What to do: Use the Playbook's Interpret step and the situation types table in References. Check the signal pattern against known situation types — comprehension breakdown, trust gap, effort mismatch, habit formation gap, and others. Then use the four-part structure from the Playbook (trigger, goal, friction, what success means) to draft a situation statement. If it cannot be completed, more observation is needed before naming.

3. We're not sure if what we're seeing is a situation or just noise

A signal is visible and recurring, but the team is not confident it represents a real condition rather than a collection artifact, an outlier audience, or a temporary phase that will resolve on its own.

What to do: Use the situation strength checklist in References. A situation needs to appear in at least two sources, across at least two lenses, and across at least two audience segments before it is ready to name. If it cannot pass the checklist, return to Collecting for additional signals. By Time is particularly useful here — leading and lagging indicators together show whether a condition is structural or temporary.

4. We have a situation statement but aren't sure it's strong enough to move into Measure

The team has named a situation but it feels vague, too broad, or not grounded in enough evidence to anchor a concept test or a Findings output. Moving into Measure with a weak situation statement usually produces weak findings.

What to do: Apply the situation strength checklist from References before proceeding. Check whether all four parts of the situation are named and specific. Check whether at least two lenses converged. Check whether the situation appears across more than one audience segment. If anything is missing, return to the Playbook's Interpret step and gather the missing evidence before moving forward.

5. Multiple situations are emerging at the same time and we don't know where to start

Research has surfaced more than one recurring condition. Each one appears real and supported. The team risks spreading effort across all of them or defaulting to the most visible rather than the most foundational.

What to do: Use the Multiple Situations section in the Playbook and apply the three prioritization questions: which situation is blocking the others, which has the strongest evidence across lenses and sources, and which connects most directly to a measurable business outcome. Use the product context catalog in References to understand how the competing situations typically relate to each other before deciding where to focus first.

6. We need to present the situation to stakeholders who aren't convinced

The team understands the situation but is struggling to communicate it in a way that creates alignment. Stakeholders are jumping to solutions, questioning the evidence, or framing the condition as an edge case.

What to do: Use the Primary Situation Output table from the Playbook to structure the presentation. The table format — situation name, summary, trigger, what users are trying to do, what stands in their way, evidence, audience, why it matters — is designed to ground stakeholder conversations in observable conditions rather than opinion. Include the lenses that converged and the audience segments the situation appeared in. The Example Situation Statement is a shorter format for async reviews or presentations.

7. We know the situation but aren't sure which UX metrics will tell us if it's improving

A situation has been named and the team is ready to move toward Measure, but it is not clear which metrics will actually reflect whether the conditions are changing. Choosing the wrong metrics means the team will not know if the design response is working.

What to do: Go to the situation type in References and check which lenses surfaced it. The lenses point directly to the metric types most relevant to that situation. A trust gap surfaced by By Type and By Engagement connects to attitudinal metrics like Trust and Comprehension and activity metrics like return visits. Use the Techniques section to confirm which specific metrics apply to the lenses that converged, then carry those into Measure as the measurement frame for the concept or finding.

8. We're setting up an AI Skill for this block

The team is building or refining an AI Skill that uses Situations and needs to understand which parts of the block the skill should draw from, what inputs it needs, and what output format it should produce.

What to do: The Playbook is the primary source for the Observe → Interpret → Name cadence, input formats, prompt structure, and expected outputs. References provides the situation type catalog and signal-to-situation mapping the skill uses to classify conditions consistently. Examples provides worked cases and the common traps table the skill uses to calibrate output quality. Use all three together when configuring a skill for this block. Agent Operations in this section covers the routing logic, confidence rules, and escalation handling specific to AI Skills working with situation-level signals.

Quick Reference

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 336px;"><colgroup><col style="min-width: 25px;"><col style="width: 311px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="311"><p><strong>Start Here</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Signals exist but no pattern is visible</p></td><td colspan="1" rowspan="1" colwidth="311"><p>Techniques — apply two lenses, check signal-to-situation mapping in References</p></td></tr><tr><td colspan="1" rowspan="1"><p>Pattern visible but situation not named</p></td><td colspan="1" rowspan="1" colwidth="311"><p>Playbook — Interpret step, situation types table in References</p></td></tr><tr><td colspan="1" rowspan="1"><p>Not sure if it's a situation or noise</p></td><td colspan="1" rowspan="1" colwidth="311"><p>References — situation strength checklist, Techniques — By Time</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situation named but not strong enough for Measure</p></td><td colspan="1" rowspan="1" colwidth="311"><p>References — strength checklist, Playbook — Interpret step</p></td></tr><tr><td colspan="1" rowspan="1"><p>Multiple situations, unclear where to start</p></td><td colspan="1" rowspan="1" colwidth="311"><p>Playbook — Multiple Situations, References — product context catalog</p></td></tr><tr><td colspan="1" rowspan="1"><p>Need to align stakeholders around the situation</p></td><td colspan="1" rowspan="1" colwidth="311"><p>Playbook — Primary Situation Output, Example Situation Statement</p></td></tr></tbody></table>

Related links

Briana Bui

Reflects on a stakeholder meeting where defending design choices was hard, and shares the muscle designers need to build to articulate why a design is right. Useful when a designer is unsure how to defend their work in reviews.

Akorede J. Ayanbisi

Walks through how to back design choices with app analytics and OKRs so stakeholders can buy into the decision. Useful when execs keep pushing back on design recommendations and you want a data narrative they will accept.

Tom Greever

Tom Greever's IDEAL framework (Identify, Describe, Empathize, Lock) for responding to design feedback, paired with four categories: business, design, research, limitations. Useful when a designer wants a script for hard stakeholder questions.

Identify where decision quality breaks down

The Glare Design Assessment helps teams spot weak validation, stakeholder friction, alignment gaps, and assumptions that scale without measurable learning—so you have a clearer starting point for improvement.

About 5 minutes · Team-based · Diagnostic snapshot you can act on

Take the Design Assessment