We have spent the past weeks inside a national operations system for the police, the kind of environment where the gap between the process on paper and the process on the ground is the whole project. It has settled something for me about how discovery should start.
I no longer open with "walk me through your process." I open with "show me the last time this happened."
Why the described process is fiction
When you ask a manager to describe how work flows, you get the happy path. It is honest, but it is an average of a hundred cases, and averages do not have exceptions. The exceptions are where the software will break, and where the people doing the work spend most of their day.
A recent real case has none of that smoothing. It has a specific trigger, a specific person, a specific wait, and the moment somebody made a judgment call that no document mentions. That is the material a workflow tool is actually made of.
The six questions
Once someone has a real case in front of them, I ask the same six things every time:
- What triggered this? A call, a form, a message, a missed deadline. The trigger defines the entry point of any tool.
- What did you do next, and why? The "why" reveals the rule they are following, which is usually not the written one.
- What information did you need but not have? This is the list of things the system should put on the screen before anyone asks.
- Where did you wait, or type the same thing twice? Waits and re-entry are the cost centers. They are also the easiest wins.
- What was unusual about this case? Every case has something. That something is the exception path, and it needs a home in the design.
- How did you know it was safely done? The answer is the real definition of complete, and it becomes the acceptance test.
Then I write each answer down with a label: observed, reported, or my interpretation. Three weeks later, when the team disagrees about how something works, that label is what stops the argument.
What it changes in the build
Discovery done this way produces a map that looks like this: trigger, action, artifact, handoff, decision, exception, end state, downstream consumer. It is not beautiful. It should not be beautiful yet. It is true, which matters more.
From that map, the first slice of software almost designs itself. It is the shortest path from the trigger to "safely done" for the most common case, with the most common exception handled and the rest visibly parked. Everything else waits until that slice is in someone's hands.
If you are about to brief a builder
Bring a recent case, not a process document. Bring the person who handled it, not only their manager. Expect the builder to ask what was unusual, and be honest about the part where you improvised. That improvisation is not a flaw in your operation. It is the requirement nobody wrote down.
A note on recording
The point of the labels is not bureaucracy. It is memory. In a police operations project, the person who told you how a dispatch actually works may be on a different shift next week, and the person replacing them may describe it differently. If the first account was recorded as "reported" with a date and a name, the difference becomes a question to resolve, not a contradiction that stalls the build. I keep the notes short, one line per answer, and I keep the labels honest even when the interpretation is mine and probably right.
Ask for the last real case, label what you heard, and design for the exception you were told about.