Realistic cases showing how situations emerge from signals, how teams recognize them, and where the interpretation goes wrong.
Each example follows the same format: the signals the team saw, the lenses they applied, where they converged, and the named situation that resulted. Near-miss cases show what teams initially concluded and why the situational framing changed the decision.
Example 1: The Onboarding Completion Trap
CONTEXT: SaaS product, onboarding flow, new paying users
A product team was preparing to launch a redesigned onboarding flow. Prototype testing had gone well. Completion rates in beta were above 80 percent. Stakeholders were satisfied. The team was ready to ship.
A researcher asked one question before launch: what do users do in the first 48 hours after finishing onboarding?
Signals
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 515px;"><colgroup><col style="min-width: 25px;"><col style="width: 490px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Completion rate</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>82% of users finished all onboarding steps in beta testing (By Stage — proxy)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Trust scores</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Post-onboarding trust rated 5.8 out of 10 across beta participants (By Type — attitudinal)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Return visits</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Only 31% of users who completed onboarding returned within 48 hours (By Engagement — activity layer)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Support tickets</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Most common question in week one: "What does my score mean and what should I do first?" (Collecting — support)</p></td></tr></tbody></table>
Lens Application
By Type showed an immediate mismatch: completion was strong but trust was weak. Users were finishing the flow without feeling confident about what they had completed.
By Engagement showed the activity layer collapsing after the first session. Users were not returning, despite having finished setup.
The two lenses converged on the same condition: users were completing onboarding mechanically without building enough understanding to act on what the product was telling them.
Named Situation
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 516px;"><colgroup><col style="min-width: 25px;"><col style="width: 491px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Onboarding confidence breakdown</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Trigger</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>The first product recommendation appears before users understand the scoring system behind it</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What users are trying to do</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Complete setup and feel confident enough to act on what the product is telling them</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What stands in their way</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Recommendations appear before users have the context to evaluate them</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What success means</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Finishing setup with enough understanding to take a first meaningful action, not just finishing the steps</p></td></tr></tbody></table>
Near-Miss
Initial conclusion: The completion rate is strong. Ship the flow and monitor week-one engagement.
What changed: By Type and By Engagement converging on the same confidence gap shifted the decision. The team added a context layer before the first recommendation. Return visits in week one rose from 31% to 58% after launch.
Example 2: The Satisfied Non-Returner
CONTEXT: Consumer product, retention, habitual and dormant users
A consumer app had consistently high satisfaction scores. NPS was strong. Users rated the experience positively after every session. But retention was quietly declining. Month-three retention had dropped from 61% to 44% over two quarters, and the team could not explain why.
The standard read was that a competitor had entered the market. The team was preparing a feature response.
Signals
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 515px;"><colgroup><col style="min-width: 25px;"><col style="width: 490px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Satisfaction scores</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Post-session satisfaction averaged 8.2 out of 10 across active users (By Type — attitudinal)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Return visits</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Month-three retention declining steadily with no corresponding drop in satisfaction (By Time — lagging vs. attitudinal)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Session behavior</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Users who returned were completing their primary task in under three minutes and leaving (By Type — behavioral)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Interview signals</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Users described the product as "useful when I think of it" but not something they opened habitually (Collecting — interviews)</p></td></tr></tbody></table>
Lens Application
By Type showed satisfaction and behavior diverging. Users rated the experience highly but were completing a narrow task and leaving. The product was not creating the conditions for a longer, more integrated session.
By Time showed the retention decline was not new. It had been building steadily for two quarters while satisfaction remained flat. The condition was structural, not a response to a competitor.
By Engagement showed the activity layer failing. Users were expressing positive needs-based signals but not building return behavior. The product was relevant in the moment but not habitual.
Named Situation
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 516px;"><colgroup><col style="min-width: 25px;"><col style="width: 491px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Satisfied but non-returning</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Trigger</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Users complete their primary task and find no natural prompt or reason to return before the next time a need arises</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What users are trying to do</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Accomplish a specific task when it comes to mind</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What stands in their way</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Nothing — the product works. But it does not connect to a recurring need in their daily workflow</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What success means</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Finding the product useful enough to open without a specific trigger, not just completing a task when they remember it</p></td></tr></tbody></table>
Near-Miss
Initial conclusion: A competitor is drawing users away. Build features to match or exceed their offering.
What changed: By Time confirmed the decline predated the competitor's launch. By Engagement showed the product had never established a habit loop. The team shifted from feature development to habit-forming touchpoints tied to recurring workflow moments. Month-three retention recovered to 54% within two quarters.
Example 3: The Testing Environment Gap
CONTEXT: B2B product, adoption, trial users converting to paid
A B2B team had strong concept testing results for a new workflow feature. Usability scores were high. Task completion in controlled testing reached 91%. Stakeholders approved the build. The feature launched.
Six weeks after launch, feature adoption was at 12%. The team had no explanation.
Signals
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 515px;"><colgroup><col style="min-width: 25px;"><col style="width: 490px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Proxy completion</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>91% task completion in controlled usability testing (By Stage — proxy)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Production analytics</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>12% feature adoption six weeks post-launch, concentrated in power users (By Stage — analytics)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Time on task</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>Users who attempted the feature took 4x longer than testing suggested (By Type — performance)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Drop-off point</strong></p></td><td colspan="1" rowspan="1" colwidth="490"><p>67% of users who started the feature abandoned it at the same configuration step (By Stage — analytics)</p></td></tr></tbody></table>
Lens Application
By Stage showed an immediate gap between proxy and analytics. The 91% completion in testing had not translated to real-world adoption. The controlled environment had removed the conditions that made the feature difficult.
By Type showed the performance signal in production was far worse than testing had revealed. Users who attempted the feature were spending significantly more time and abandoning at a specific configuration step that had not appeared as a problem in testing.
The two lenses converged on a testing environment gap: the usability test had used pre-configured accounts with familiar data. Real users were encountering the feature with unfamiliar data structures and no configuration guidance.
Named Situation
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 516px;"><colgroup><col style="min-width: 25px;"><col style="width: 491px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Testing environment gap at configuration</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Trigger</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Users encounter the feature with their own data and existing account structures, which the testing environment did not replicate</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What users are trying to do</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Set up the feature and integrate it into an existing workflow</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What stands in their way</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Configuration requires decisions about data structures that users cannot make without guidance they were not given</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What success means</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Completing configuration without needing to leave the product to find answers or make guesses about their own data</p></td></tr></tbody></table>
Near-Miss
Initial conclusion: Adoption is a communication problem. Users do not know the feature exists.
What changed: The drop-off data from By Stage showed users were finding the feature but abandoning at a specific point. By Type confirmed the performance problem was real. The fix was contextual guidance at the configuration step, not marketing. Adoption reached 47% within six weeks of the update.
Example 4: The Stakeholder Override Loop
CONTEXT: Enterprise product, decision and evaluation, cross-functional team
A cross-functional team had been running the same research cycle for three quarters. Usability findings were consistent. The same friction point appeared in every study. Design proposed a solution twice. Both times, stakeholders redirected the team toward higher-visibility features before the solution was built.
The team recognized the pattern but had no language to name it as a situation rather than a process problem.
Signals
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 514px;"><colgroup><col style="min-width: 25px;"><col style="width: 489px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Usability findings</strong></p></td><td colspan="1" rowspan="1" colwidth="489"><p>The same friction point appeared in four consecutive studies across different user segments (By Stage — proxy, repeated)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Analytics</strong></p></td><td colspan="1" rowspan="1" colwidth="489"><p>Drop-off at the corresponding workflow step had increased 18% over three quarters (By Time — lagging)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Stakeholder decisions</strong></p></td><td colspan="1" rowspan="1" colwidth="489"><p>Two design proposals addressing the friction were redirected to lower-priority status at review (Collecting — workflow observations)</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Contradictory framing</strong></p></td><td colspan="1" rowspan="1" colwidth="489"><p>Stakeholders consistently framed the friction point as "edge case behavior" despite signals showing it across segments (By Type — contradictory)</p></td></tr></tbody></table>
Lens Application
By Time showed the analytics signal had been worsening steadily while the team cycled through the same research and proposal loop. The situation was structural and deepening.
By Type showed contradictory signals: research consistently pointed to a real friction condition while stakeholder framing dismissed it as marginal. The team was measuring one thing and the organization was deciding based on another.
The two lenses converged on an organizational blind spot: the decision loop itself was the situation. The friction point was real, supported, and documented, but the organizational conditions around the review process were preventing it from being acted on.
Named Situation
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 516px;"><colgroup><col style="min-width: 25px;"><col style="width: 491px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Organizational blind spot — stakeholder override loop</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Trigger</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>A documented friction condition reaches stakeholder review without the organizational framing needed to compete with higher-visibility priorities</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What the team is trying to do</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>Move a well-evidenced design decision from proposal to implementation</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What stands in their way</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>The review process weights visibility and stakeholder intuition over documented user signal</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>What success means</strong></p></td><td colspan="1" rowspan="1" colwidth="491"><p>A friction condition supported by four studies and worsening analytics reaching implementation within one review cycle</p></td></tr></tbody></table>
Near-Miss
Initial conclusion: This is a prioritization problem. The team needs to advocate more effectively for the fix.
What changed: Naming it as a situation shifted the frame from "we need to convince stakeholders" to "the conditions around our review process are creating a recurring organizational blind spot." The team brought the situation statement and the By Time data to the next review. The proposal was approved and built within the quarter.
Common Traps
These are the most frequent ways teams misread signals and arrive at an observation instead of a situation.
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 483px;"><colgroup><col style="min-width: 25px;"><col style="width: 229px;"><col style="width: 229px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p>Trap</p></td><td colspan="1" rowspan="1" colwidth="229"><p>What It Looks Like</p></td><td colspan="1" rowspan="1" colwidth="229"><p>What to Do Instead</p></td></tr><tr><td colspan="1" rowspan="1"><p>Naming the symptom</p></td><td colspan="1" rowspan="1" colwidth="229"><p>"Users are dropping off at step three" is an observation. The situation is the condition creating the drop-off.</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Apply By Type and By Stage. Look for the conditions surrounding the drop-off point, not just the drop-off itself.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Trusting a single lens</p></td><td colspan="1" rowspan="1" colwidth="229"><p>One lens showing a pattern feels convincing, especially when the data is clean. But a single lens is an observation, not a situation.</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Always apply at least two lenses. Look for convergence before naming.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Confusing testing with production</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Strong proxy results are treated as proof. The gap between controlled testing and real-world conditions goes unexamined.</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Apply By Stage explicitly. Ask whether the conditions in testing match the conditions users actually face.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Treating satisfaction as retention</p></td><td colspan="1" rowspan="1" colwidth="229"><p>High satisfaction scores are used as evidence that the experience is working. Retention signals are not checked.</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Apply By Engagement. Check whether satisfaction is connecting to return behavior or whether users are satisfied but not habitual.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Racing to solutions</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Signals are visible and the team jumps to design responses before the situation is named. The solution addresses a symptom instead of a condition.</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Use the situation strength checklist from References before moving to Measure. A situation that cannot answer all five questions is not ready.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Single-audience framing</p></td><td colspan="1" rowspan="1" colwidth="229"><p>A situation is named based on signals from one audience segment and assumed to apply broadly.</p></td><td colspan="1" rowspan="1" colwidth="229"><p>Check whether the situation appears across at least two audience segments before naming it. Audience source shapes what a signal means.</p></td></tr></tbody></table>
