Follow one real piece of work
Choose an ordinary enquiry, order or service request. Trace where it starts, which people handle it and where it finishes. Include the messages and spreadsheets that sit outside the official process.
Ask what each person is trying to decide. A screen inventory tells you what software exists; a decision map tells you why it needs to exist. That distinction helps avoid rebuilding the same friction in a more attractive interface.
Name the records and the transitions
Identify the things that need a stable identity: a customer, request, order or payment. Then describe the events that change their state. A message may add context to a request; approval may create an order; a confirmed payment may unlock a next step.
These relationships do not need a complicated diagram. A short map with clear names is useful if both the business and the builder can explain it back to each other.
- What starts the workflow?
- Which record owns each piece of information?
- Who is allowed to change a state?
- What happens if the expected event never arrives?
Make exceptions part of the design
A workflow that only handles the ideal path is incomplete. Consider duplicate submissions, incomplete requirements, failed notifications and decisions that need human review. Define where those cases become visible.
This does not mean building every possible edge case into the first release. It means distinguishing a deliberate manual fallback from a gap nobody has considered.
Build a slice you can review
Take one path from customer action through to the team's next step. Build enough of it to review real behavior together: the interface, the record, the transition and the failure state.
Once that slice is understandable, extend it. Document the important decisions as you go, and choose measurements that reveal whether the intended change actually happened. A blueprint should guide the build without becoming a rigid prediction of everything the business will ever need.