Workflow design
Workflow design is the process of designing how work moves through a product: between roles, under rules and through handoffs. It also covers what happens when the normal path fails. It matters wherever software carries real consequences, such as approvals and handoffs.
- Roles
- Rules
- States
- Hand-offs
Workflow design examples from staffing and real-estate software
The rules come first. The screens follow.
Workflow design covers the working rules as well as the interface. In Dealpath, a user searches for an existing deal before creating one, with a deliberate fallback when no record exists. That choice depends on how a deal is identified, who has permission and how exceptions are handled, as much as on the order of screens.
Information architecture defines the objects and relationships underneath that work. A flowchart can still miss who has authority, where work waits, and what happens on failure and recovery.
Explore Information Architecture and Workflow Design or B2B SaaS and Workflow Software.
Workflow design starts with the work a product must carry across people, records, decisions and exceptions. In Scissors, Tcules modelled clients, candidates and jobs so staffing work could be designed around the relationships among them. In Dealpath, a search-before-create decision changed one branch of an established real-estate workflow.
The Information Architecture and Workflow Design service makes those product rules explicit before interface detail hides them.
Common workflow design patterns
A handful of patterns recur in most business software. Each one answers a specific moment where work could go wrong.
| Pattern | What it handles | Where it appears in Tcules work |
|---|---|---|
Search before create | Checks whether a record already exists before a new one is made | Dealpath's add-to-pipeline flow |
Deliberate fallback | Gives the work a clear route when the expected record or step is missing | Creating a new deal in Dealpath when no match exists |
Enter once, reuse later | Keeps details entered at the start in use across later steps | Scissors, where organisation details shape every later job and candidate message |
Handoff between roles | Passes work to someone with different knowledge, and shows who holds it now | The Auxentios quotation, shared across six specialist roles |
Override with a reason | Lets a person overrule a result and keeps the reason on the record | BuildTwin's review of automated drawing checks |
Workflow design vs process design and journey mapping
Process design works at the level of the organisation. Workflow design brings that work into the product, and journey mapping looks at one person's experience around it.
| Process design | Workflow design | User journey mapping |
|---|---|---|
Defines how an organisation's work runs across teams and systems, often before any software is chosen | Defines roles, records, decisions, states, handoffs and exceptions | Follows a person's goal, actions and experience across touchpoints |
Helps the business agree who does what, in what order and under which policies | Helps the product team decide what the software must represent | Helps the team see where the product fits into a broader experience |
Produces process maps, policies and responsibilities | Produces product rules and paths the build can follow | Produces a view of one person's experience, built from what was observed |
Workflow design questions
Why does workflow design matter in software?
Software that carries real work, such as approvals, quotes or orders, tends to break at the handoffs and exceptions more than on the main screen. Workflow design makes those moments explicit, so the product knows who acts next and what happens when something fails. Otherwise people fill the gaps with email and spreadsheets.
Where does workflow design start?
It starts with the work, before the screens: who takes part, which records they touch, which rules apply and where things go wrong today. Interviews and observation supply that picture. A map of roles and states then turns it into something the team can design against.
Who does workflow design in a product team?
Product designers usually lead it, with product managers bringing the business rules and engineers checking what the system can represent. The people who do the work every day are the most important source. In larger products, workflow design and information architecture are worked out together.
Make the rules explicit before the screens
Roles, rules and handoffs have to work together as one product, whatever the screens look like. Workflows are also gaining a new kind of participant. An AI agent that drafts, routes or approves part of the work needs the same explicit rules and handoffs as any role, plus a clear point where a person can step in. User journey mapping looks wider, across stages and channels, and human in the loop covers the review steps where software proposes and a person decides.
Explore workflow design
Explore Information Architecture and Workflow Design, B2B SaaS and Workflow Software, or the Dealpath workflow decision.