Situations

Find recurring behaviors and friction shaping decisions.

A metric might show high drop-off, rising effort, or weak retention. But a number alone cannot tell you why. It cannot tell you what was happening around the user when the friction appeared, what they were trying to accomplish, what forces were working against them, or why the same breakdown keeps showing up across different sessions, different audiences, and different product areas.

That is what Situations does.

Situations is the fourth block in Define. It sits after User Needs, Audience, and Collecting, where those three converge. User Needs names what people are trying to accomplish. Audience identifies whose signals carry weight. Collecting gathers the evidence. Situations is where recurring conditions become visible across all of it, turning isolated signals into stable context that teams can design against.

What This Block Covers

Situations are organized into seven sections, each with a specific job:

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 384px;"><colgroup><col style="min-width: 25px;"><col style="width: 359px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Section</strong></p></td><td colspan="1" rowspan="1" colwidth="359"><p><strong>What It Does</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Overview</strong></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Explains what Situations is, where it sits in Define, and how it connects to User Needs, Audience, and Collecting.</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.zurb.com/docs/decision-map/define/situations/techniques"><u>Techniques</u></a></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Covers the four lenses for surfacing recurring situations from signals: By Type, By Time, By Stage, and By Engagement.</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.zurb.com/docs/decision-map/define/situations/playbook"><u>Playbook</u></a></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Provides the process for identifying, naming, and validating a situation, with prompts, inputs, and outputs.</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.zurb.com/docs/decision-map/define/situations/references"><u>References</u></a></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Situation types, signal-to-situation mapping, and common situation catalogs by product context.</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.zurb.com/docs/decision-map/define/situations/examples"><u>Examples</u></a></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Realistic situations showing recurring conditions teams commonly misread, including near-miss cases and common traps.</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.zurb.com/docs/decision-map/define/situations/decisions"><u>Decisions</u></a></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Helps teams recognize when they have enough signal to name a situation and move forward into Measure.</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.zurb.com/docs/decision-map/define/situations/agent-operations"><u>Agent Operations</u></a></p></td><td colspan="1" rowspan="1" colwidth="359"><p>Defines how AI Skills identify situation-level signals, evaluate pattern strength, and route to the next step.</p></td></tr></tbody></table>

What Is a Situation?

A situation is a specific set of circumstances that gives behavior its meaning. It captures the conditions surrounding what a user does, not just the action itself.

Behavior does not happen in isolation. Every action a user takes is shaped by what triggered it, what they are trying to accomplish, what stands in their way, what forces are working around them, and what success or failure means in that moment. Strip those conditions away, and a metric tells you what happened. Keep them, and you begin to understand why.

This is the distinction that makes Situations useful. A pattern without context is just a trend. A situation gives that trend meaning, because it explains the conditions that produced it.

The Four Parts of a Situation

Every situation in Glare can be understood through four elements:

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 393px;"><colgroup><col style="min-width: 25px;"><col style="width: 368px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Element</strong></p></td><td colspan="1" rowspan="1" colwidth="368"><p><strong>What It Captures</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>What triggered it</p></td><td colspan="1" rowspan="1" colwidth="368"><p>The condition, pressure, or goal that set the situation in motion.</p></td></tr><tr><td colspan="1" rowspan="1"><p>What they are trying to do</p></td><td colspan="1" rowspan="1" colwidth="368"><p>The progress the user is seeking in this specific context.</p></td></tr><tr><td colspan="1" rowspan="1"><p>What stands in their way</p></td><td colspan="1" rowspan="1" colwidth="368"><p>The friction, uncertainty, or constraint that shapes behavior.</p></td></tr><tr><td colspan="1" rowspan="1"><p>What success means here</p></td><td colspan="1" rowspan="1" colwidth="368"><p>How the user defines resolution, and what failure costs them.</p></td></tr></tbody></table>

When the same four-part pattern shows up repeatedly across different users, sessions, and audiences, a situation has emerged. One data point is an observation. A recurring situation is a design signal.

Situations and User Needs Are Not the Same Thing

User Needs name what people are trying to accomplish at a category level. Basics, Trust, Personal, Impact, Feelings. Those categories are stable and broadly applicable. They set the foundation for what matters.

Situations are one level more concrete. They capture how a need manifests inside a specific context, shaped by the circumstances surrounding it. The same user need can produce entirely different situations depending on who the person is, what they are dealing with, and where they are in the experience.

A physician who needs to learn and a product manager who needs to learn are both expressing the same user need. But the situations they find themselves in are different, shaped by different pressures, workflows, relationships, and stakes. Designing for the need alone misses that. Designing for the situation gets closer to what actually matters.

User Needs defines the category. Situations define the context inside it.

Situations vs Jobs to Be Done

Jobs to Be Done focuses on the need itself. The functional job a person is trying to accomplish, expressed as a statement of motivation and intended outcome. It is a powerful framework for naming what users want, and it maps closely to the User Needs block in Define.

But JTBD treats the situation as background. The circumstance that sets the job in motion, noted and then set aside. The need is the unit of analysis. Everything else is context.

Situations inverts that priority. The argument is that a need is always a product of the circumstances surrounding it. You cannot fully understand what someone needs without understanding the forces shaping that need in this specific context, at this specific time and place. Those forces include environment, relationships, culture, constraints, habits, and pressure. Strip those away and you have a job statement that is true in the abstract but often too thin to design against.

In practical terms, JTBD helps you write the User Needs block. It gives you the categories and statements that name what people are trying to accomplish. Situations is what comes after you collect evidence and start seeing which conditions keep producing the same behaviors across different users and different moments. A situation is a job statement made visible through repeated, real signal.

How Patterns Become Situations

A situation becomes recognizable when a pattern repeats. One user hesitating during onboarding is an observation. Ten users hesitating in the same moment, across different sessions and different audience segments, is a situation. The repetition is what gives it design credibility.

This is why Situations sits after Collecting. You cannot name a situation from instinct alone. You need signals, gathered from the right people using the right methods. When those signals converge, recurring conditions become visible. The same friction. The same hesitation point. The same workflow breakdown. The same place where confidence drops.

Patterns are the evidence. Situations are the interpretation. Together, they create the shared context that makes everything downstream more useful.

Why Context Shapes What Signals Mean

The same behavior can mean completely different things depending on the situation surrounding it.

Long session duration might signal engagement, or confusion, or comparison behavior, or cognitive overload. A drop in task completion from trial users points toward onboarding clarity. The same drop from habitual users points toward a workflow regression. Rising effort scores after a redesign might indicate that users are learning something new, or that the team introduced friction they did not intend.

Without situational context, teams optimize for the wrong thing. They celebrate completion rates while confidence quietly drops. They reduce time on task without realizing the task itself was the wrong one. They fix the symptom and leave the condition intact.

Situations prevent that drift. They keep teams anchored to what is actually happening around the behavior, not just the behavior itself.

Proof in Practice

A pharmaceutical company had been running the same market research on physicians for seven years. Engagement looked reasonable. The metrics were stable. But nothing was moving.

A team took the existing data and stopped looking for the narrative. Instead, they mapped forces of influence: what conditions shaped how physicians showed up in different moments. What emerged were three distinct situations, each with different motivations, different friction points, and different signals about what the physician valued.

One of those situations consumed a third of the commercial budget. Physicians in that situation had no interest in engaging. The company had no access. Once the situation became visible, the investment decision changed completely.

The data was always there. What was missing was the situational frame that gave it meaning.

Business Impact

• Shared situation definitions align teams around what is actually happening, reducing debate and speeding decisions.

• Situational context makes metrics meaningful, connecting what was measured to why it matters.

• Recurring situations surface earlier, before they scale into product or operational problems.

• Design credibility increases when teams can explain not just what users did, but the conditions that produced that behavior.

Situations is where Define closes. It is the block that turns the signals gathered in User Needs, Audience, and Collecting into stable, shared context. That context is what Measure uses to test ideas worth testing, and what Focus uses to choose the work worth doing.

Moving Through the Situations Sections

Each section of Situations is designed for a different kind of work.

Techniques covers the four lenses for surfacing recurring situations from collected signals: By Type, By Time, By Stage, and By Engagement. Each lens asks a different question and reveals a different layer of context.

Playbook provides the operational workflow for identifying, naming, and validating a situation, including the prompts, inputs, and outputs that connect Situations to Measure.

References contains situation type catalogs, signal-to-situation mapping guides, and common situation patterns organized by product context.

Examples shows realistic cases where situational framing changed what a signal meant and what decision it supported, including situations teams commonly misread.

Decisions helps teams recognize when situational evidence is strong enough to move forward and what to do when it is not.

Agent Operations defines how AI Skills identify situation-level signals, evaluate pattern strength across sources, and route to the appropriate next step.

Where Situations Sits in Define

Situations is the fourth and final block in the Define area, sitting after Collecting. The four blocks build on each other in a specific sequence.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 397px;"><colgroup><col style="min-width: 25px;"><col style="width: 372px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Block</strong></p></td><td colspan="1" rowspan="1" colwidth="372"><p><strong>What It Focuses On</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>User Needs</p></td><td colspan="1" rowspan="1" colwidth="372"><p>The motivations, goals, and expectations that drive behavior.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience</p></td><td colspan="1" rowspan="1" colwidth="372"><p>The people and contexts you learn from, and how much to trust each source.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Collecting</p></td><td colspan="1" rowspan="1" colwidth="372"><p>Capturing behavior, perception, and reaction through the right methods.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situations</p></td><td colspan="1" rowspan="1" colwidth="372"><p>Synthesizing signals into recurring conditions that give behavior its meaning.</p></td></tr></tbody></table>

The first three blocks produce signals. Situations interprets them. Without the context that Situations creates, those signals remain isolated data points. With it, teams begin recognizing the conditions that keep producing the same friction, hesitation, and breakdown across different users and different moments.