Map the workflow before drawing screens

Show actions, decisions, waiting and handovers so the proposed software supports the complete business process.

A hand maps a process using wooden blocks and yellow thread before screen design.

Screens are easier to discuss when the team agrees what work must happen between them. A workflow map makes that sequence visible without requiring technical notation. For a small business, it can be a simple diagram showing who acts, what information they use and what event allows the next step to begin.

Follow one real piece of work

A hypothetical Shepparton metal workshop could trace an accepted fabrication request from the office to production and dispatch. Start with a representative recent job and mark every meaningful action. Include work outside software, such as checking a measurement or phoning a customer. A map that includes only clicks misses the surrounding process the application must support. Note where the job waits and what causes it to move again, because those points often explain delays better than the action list.

Show decisions separately from tasks

Preparing a job summary is a task; deciding whether the information is sufficient is a judgement. Mark the condition behind each branch and identify who can make the decision. If staff cannot agree on the rule, label it as unresolved. The map should expose uncertainty instead of concealing it under a neat arrow. Include the route for incomplete information, since a process that only shows successful completion often leaves the most frequent coordination work unexplained.

Distinguish current and proposed work

First make the existing process understandable, then create a separate proposed version. Otherwise, participants may assume an improvement already happens or mistake an old workaround for a requirement. The tradeoff is that drawing both versions takes effort, but it lets the team explain exactly what changes. Remove steps only when their purpose is understood. An apparently redundant review may provide information that another team relies on, even if nobody has documented that dependency.

Use the map to define scope

Mark which steps the new software will support and which remain manual or belong to another tool. Check every crossing between those boundaries for an owner and information handover. Your next scoping step is a one-page map for one complete job, reviewed by the people on both sides of each handover. Ask a staff member unfamiliar with the drawing to explain the process back to you. Confusing sections identify where more investigation is needed before detailed screen design.

Planning checklist

  • Include waiting and work outside software.
  • Name the conditions behind decisions.
  • Show owners at every scope boundary.

Discuss your software project with 110s

Related Insight