# Situation Mining — the "When" Is the Whole Method

Job stories live or die on the situation clause. "When I want to check analytics" is a feature restated; "When a customer emails asking why their invoice doubled and I have 10 minutes before my next call" is a design brief. This reference is how to mine real situations.

## What a load-bearing situation contains

At least two of: **trigger** (what just happened) · **time pressure** (how long they have) · **emotional state** (worried/rushed/defensive) · **social context** (who's watching/waiting) · **environment** (phone in a hallway vs desktop with two monitors).

Test: could a designer make a layout decision from the situation alone? "When I'm curious about metrics" decides nothing; "when my CEO forwards a board question and CCs me" decides almost everything (speed over depth, quotable numbers, exportable).

## Where situations hide in your data

- **Support tickets** — the first sentence before the question ("we're closing our quarter and…")
- **Session timing** — 2am usage, Monday 8:55am spikes, usage bursts after billing emails: each is a situation wearing analytics
- **Interview stories** — the sentence *before* the pain in any narrated incident
- **Workarounds** — every workaround encodes a situation the product doesn't serve ("I screenshot dashboards into slides" = "when I must present numbers to people without accounts")

## Forces: the part everyone skips

Each job story carries its forces — what pushes toward change and what holds them back:
- **Push:** the situation's pressure ("I look slow when I can't answer")
- **Pull:** the outcome's promise ("answer in the meeting, not after")
- **Anxiety:** what the new way risks ("what if the number's wrong and I quoted it?")
- **Habit:** what the old way costs to abandon ("my spreadsheet already works")

A feature that answers the pull but ignores the anxiety loses to the spreadsheet every time. Write forces per story; design against anxiety and habit, not just toward pull.

## Granularity check

Too broad → multiple different situations share the story (split it). Too narrow → the situation names one specific user's Tuesday (generalise the *pressure*, keep the texture).
