Process Flow

A process flow maps an operation from trigger to completion: the sequence of steps a piece of work goes through, regardless of who or what performs each step. Where a user flow (User Flow) is person-centered — "what does the user do next?" — a process flow is operation-centered: "what happens to the application / order / claim / ticket next?" The thing moving through the diagram is the work item, not the person. Near-synonyms: business process diagram, process map, flowchart (the generic term).

Why UX designers need them

The interface makes promises the process must keep. A "Submit application" button promises that something reviews it; an order confirmation promises fulfillment; "We'll email you when it's approved" promises a step, a decision, and a notification exist. If you design the screen without mapping the process, you design promises nobody is keeping — the classic symptom is a status page with nothing truthful to display ("Processing…" forever). Process flows also tell you which states the UI must represent: every box and diamond in the process is a status the user may ask about (State Flow).

What it answers

What kicks the process off? What are the steps, in what order? Where does the process branch, wait, or loop back? What are ALL the exit states (approved, rejected, expired, abandoned, escalated)? How long does each step take — and what does the user see during it?

Vocabulary

Standard flowchart symbols are a convention, standardized as ANSI X3.5 (1963) and internationally as ISO 5807:1985; in text form:

• Start/End (drawn as rounded terminals): ((Start)) — every process has one trigger and names ALL its end states.
• Process step (rectangle): a verb phrase — [Review application].
• Decision (diamond): a question with labeled exits — <Approved?> yes/no (depth: Decision Flow).
• Wait/delay: not in the classic minimal set, but mark it anyway — (wait: 3–5 business days) — because waits are where users churn.

BPMN (Business Process Model and Notation, an OMG standard, current version 2.0.2, 2014) is the formal grown-up version: events, tasks, gateways, pools/lanes, message flows. You rarely need to author BPMN as a designer, but enterprises and process teams speak it — being able to read a BPMN diagram is a cheap superpower in enterprise UX. When roles matter, the process flow grows lanes and becomes a swimlane flow (Swimlane Flow) or workflow diagram (Workflow Diagram).

Example — application review

((Application Submitted))
  → [Completeness check]
      ├── incomplete → [Request missing info] → (wait for applicant)
      │       ├── info received → back to Completeness check
      │       └── no response in 14 days → ((Expired)) — notify
      └── complete → [Review]  (SLA: 3 business days — what does
              the applicant SEE during this wait?)
          → <Approved?>
              ├── yes → [Payment] 
              │     ├── payment succeeds → ((Confirmation sent))
              │     └── payment fails → [Retry / other method]
              │            └── still failing → ((On hold)) — notify
              └── no → [Rejection email with reason]
                     → ((Closed — Appeal option, 30 days))

Reading it as a designer: five end states, not one — Confirmation, Expired, On hold, Closed/Appeal, and the implicit "stuck in review past SLA." Each needs a status label, a notification, and a screen that tells the truth. The (wait) steps are the UX battlegrounds: that's where "where's my application?" support tickets come from, and where a progress tracker or expectation-setting copy earns its keep (Feedback, Loading, Errors & Recovery, Notifications & Communication).

How to build one

1. Pick one work item (an application, an order) and follow it from trigger to every possible end. Interview the people who actually run the process — the documented process and the real one differ.
2. Write steps as verb phrases; write decisions as questions.
3. Mark waits with realistic durations, and loops with exit conditions (nothing loops forever — what breaks the loop?).
4. Name every end state, including the sad ones.
5. Then map each step/wait/end to what the user sees: status text, notification, screen. Gaps in that mapping are your design backlog.

Common mistakes

• Only one end state (the happy one). Real processes leak: expired, abandoned, escalated, refunded.
• Waits drawn as instant arrows — the arrow between "Review" and "Approved?" might be five days of user anxiety.
• Loops without exit conditions.
• Confusing the process with the user flow: "Review application" is invisible to the applicant; what THEY experience is silence. Design both views.
• Mapping the official process instead of the real one.
• Drawing steps at wildly mixed altitudes ("Submit form" next to "Underwriting").

Checklist

• One clear trigger; ALL end states named, including failure and abandonment ends.
• Steps are verb phrases; decisions are questions with labeled exits (Decision Flow).
• Waits are marked with realistic durations and SLAs.
• Every loop has an exit condition.
• Every step, wait, and end state maps to something the user can see: status, notification, or screen.
• Verified against the people who actually operate the process.
• If ≥3 roles are involved, upgraded to lanes (Swimlane Flow / Workflow Diagram).

Sources

• ISO 5807:1985 — flowchart documentation symbols and conventions (successor to ANSI X3.5, 1963; ISO adopted the ANSI symbols in 1970).
• Object Management Group — Business Process Model and Notation (BPMN), v2.0.2 (2014), omg.org/spec/BPMN — the formal standard for process notation; maintained by OMG since 2005.
• Goldstine, H. & von Neumann, J. (1947). Planning and Coding of Problems for an Electronic Computing Instrument — origin of the program flowchart.
• Rummler, G. & Brache, A. (1990). Improving Performance: How to Manage the White Space on the Organization Chart — process thinking across departmental boundaries (see Swimlane Flow).