What is a workflow, and how do you design a good one?

What a workflow actually is

A workflow is the sequence of tasks that moves a piece of work from start to finish, with each step depending on the one before it. The term gets used loosely across industries, which is why it feels vague. In healthcare it might describe patient admissions: registration, then history documentation, then assessment, then a treatment plan. In a design studio it describes a project moving from client brief to concept to draft to review to final file. Different worlds, same underlying shape - a series of steps that hand work along until it is done.

What trips people up is the difference between a workflow and a process. A process is the broad answer to "what do we do here" - we handle support requests, we publish articles. A workflow is the granular answer to "in what order, and who does each part." Process is the strategy; workflow is the choreography. You can have a process in your head and still have no workflow, which is exactly where work falls through the cracks: everyone knows roughly what should happen, but nobody agrees on the steps, so the same task gets done three different ways and stalls at the handoff between two people.

The reason to care is not tidiness for its own sake. A written workflow makes the work repeatable, so quality does not depend on who picks up the task, and it makes the work visible, so when something gets stuck you can see exactly which step it is stuck on. An unwritten workflow gives you neither.

What every workflow is made of

Strip any workflow down and you find the same few parts. Get these right and the rest is detail.

There are stages - the named columns the work passes through, like "to do," "in progress," "in review," and "done." There are tasks that sit in those stages and move from left to right. Each task has an owner, one named person responsible for moving it forward, because a task that belongs to "the team" belongs to nobody. There are handoffs, the moments work passes from one person or stage to the next, which is where most delays live. And there are rules for when something is allowed to move on - the review that has to happen, the approval that has to be granted first.

Most workflows also have a rough lifecycle behind them: you initiate the work, plan it, execute it, review it, and close it out. You do not need to label those phases on your board, but they are a useful checklist when mapping a new workflow, because they catch the steps people forget - especially the review and the formal close, where lessons get recorded for next time. The point of naming all this is not bureaucracy. Once the stages, owners, and handoffs are explicit, you can put the whole thing on a board and let people self-serve the answer to "where is this" instead of asking in chat.

What workflows look like by team

The clearest way to understand workflows is to see a few. The stages differ by team, but the shape is always the same: an ordered path with an owner at each step. Here are four common ones, simplified.

None of these are exotic. They are the work a team already does; the only difference between a team that "has a workflow" and one that does not is whether those stages are written down and shared. Notice too that each one stalls at a handoff or a review, not the production work. That is the recurring lesson: the bottleneck is rarely the typing, it is the waiting in between, and a visible workflow is what lets you spot it.

How to design a workflow from scratch

Designing a workflow is mostly an exercise in honesty: you map what actually happens, not what you wish happened. Skip that and you will design a workflow nobody follows.

Start by picking one type of work and writing down every step it really takes today, from the moment a request arrives to the moment it is finished. Talk to the people who do it, because the real steps almost always include a few that are in nobody's official description. Then group those steps into a handful of named stages - four to six is usually right, because more gets noisy and fewer hides too much. For each stage, answer two questions: who owns the work while it sits here, and what has to be true before it moves on? That second question is what stops things from advancing half-finished.

Now make it visible. The simplest way is a board with one column per stage and one card per task, which is exactly what project boards are built for. In Breeze, that looks like a project for the work, a column for each stage, and a card per item carrying its owner and due date, so anyone can glance at the board and see what is where. If the work is a one-off project rather than a repeating cycle, pair the board with a simple project plan so the dates and dependencies sit alongside the stages. Keep the first version deliberately plain. A workflow that is too elaborate on day one is one people quietly abandon by week two.

How to improve a workflow you already have

Improving a workflow is not about adding steps, it is almost always about removing friction from the slowest one. The instinct when something feels chaotic is to add more structure - another approval, another checklist. Usually the opposite is needed, so start by finding the bottleneck.

The bottleneck is the stage where work sits longest. On a visible board it is easy to spot: the column that is always full while the others are nearly empty. Watch the board for a week or two and the pile-up will tell you where to look. Then ask why work waits there. Often it is a single overloaded owner, an approval that one busy person has to give, or a handoff where the next stage does not know the work is ready. Each has a cheap fix: spread the ownership, require approvals within a day, or make the handoff explicit so nothing waits in limbo.

The second lever is automation. A lot of what clogs a workflow is repetitive busywork - assigning the same person to every incoming ticket, sending the same notification, moving a card when a field changes. Handing those off so they happen automatically frees people for the parts that need judgment and removes a common source of human error. This is also where AI in project management is starting to earn its keep, by drafting routine updates and flagging tasks about to slip. Whatever you change, change one thing at a time and watch the board. Improve five things at once and you will never know which one helped.

Common questions

Is a workflow the same as a process?

No. A process is the high-level description of what your team does. A workflow is the step-by-step path a specific piece of work takes through that process, including who owns each step and in what order. You can think of the process as the recipe and the workflow as the actual cooking, in sequence.

How many stages should a workflow have?

For most teams, four to six. Too few and the board hides where work really is; too many and people stop updating it because moving cards becomes a chore. Start lean and add a stage only when there is a clear handoff the current columns are not capturing.

Do small teams really need a written workflow?

If more than one person touches the work, yes. Even a two-person team benefits from agreeing on the stages and who owns what, because that is what prevents the "I thought you had it" handoff failures. The workflow does not need ceremony, just a shared board everyone can see.

The short version

A workflow is just the repeatable, ordered path your work takes from request to done, made visible so the whole team can see where things stand and where they get stuck. It matters not as process for its own sake, but because an explicit workflow catches the dropped handoffs and quiet bottlenecks that an unwritten one lets slide. A good next step is to pick the kind of work that frustrates your team most, map its real steps onto a board, and find the single stage where everything piles up. Fix that one bottleneck before you add anything else, and you will have done most of the work of "having a workflow" already.