Make the work clear enough to decide, test, and build.

The method depends on the question. Sometimes the team needs to understand a handoff. Sometimes it needs to resolve a repeated interaction or test a proposed workflow. These examples show how I choose a useful form for the decision in front of us. The work often loops back as new evidence changes the picture.

Five stages, used as the work requires

1. Frame. Establish the decision, the people it affects, and the constraints and evidence around it.
2. Map. Make the roles, workflows, handoffs, information, and rules visible together.
3. Unify. Find the shared structure and identify where different situations need different behavior.
4. Direct. Carry the agreed direction into workflows, patterns, and implementation guidance.
5. Validate. Test critical behavior and decide what to pursue, revise, or leave open.

These stages can repeat, and validation can send the work back to an earlier decision. An engagement uses the stages and outputs it needs.

Map the handoff

At Sedgwick, the service blueprint followed field evidence through photographs, diagrams, estimates, and reports. Separating adjuster, administrative, mobile-app, and background actions helped identify where information had to move and who needed it next.

Use a map when a problem crosses people or systems and the next step depends on understanding those relationships.

Follow the Sedgwick example →

Make a shared decision reusable

At AliveCor, Pride combined shared components with descriptions of their data, states, and behavior. Standard components could refer to MUI documentation; custom behavior needed its own specifications. The common reference carried the decision into design and development work.

Use shared patterns when teams keep resolving the same behavior independently. Document the conditions that matter, including where a product needs something different.

Explore Pride at AliveCor →

Explain the conditions for implementation

At RLI, a guided bond workflow needed more than a sequence of screens. The guidance explained shared controls and the conditions that made later steps available. That detail helped connect the proposed experience to the rules developers had to implement.

Use annotated guidance when the important decisions live in states, dependencies, and exceptions that a static screen cannot explain on its own.

See the RLI case →

A useful artifact answers a real question for the people doing the next piece of work. Its form and level of detail should follow that purpose.