The first process I documented at the manufacturing company ran eleven steps and collected four signatures. When I finished writing it down, I had an accurate, well-organized description of something nobody should have been doing. The document was fine. The process was the problem, and no amount of clear writing was going to fix that.
What is process design?
Process design is deciding what a process should be: which steps exist, who owns each one, where the handoffs fall, and what has to be true before work moves forward. Documentation records the process you already have. Design determines the process you want. Most companies call asking for the first, and a good number of them need both.
The distinction sounds academic until it turns up on an invoice. Those four signatures on our purchase requisition existed because of one incident years before I arrived, when somebody ordered thirty thousand dollars of the wrong steel. The company's answer was to add an approval. A different incident added another. Nobody ever went back and asked whether four people skimming the same requisition caught more errors than one person reading it properly. They didn't. What the four approvals reliably caught was three days.
Design is the part where somebody asks that question out loud, in a room with the authority to change the answer.
How is process design different from writing the procedure down?
Documentation is descriptive and design is prescriptive. A writer documenting your process asks what happens. A designer asks what should happen, and whether a given step has earned its place. Both begin with the same interviews and the same maps. They end somewhere different: one produces a faithful record, the other produces a changed operation.
Here's what that looked like on an order entry process I mapped. Customer information arrived by email, got typed into the quoting spreadsheet, got typed again into the order system once the quote was accepted, and got typed a third time onto the shipping paperwork. Three entries, three chances to transpose a digit in a delivery address, and we had the credit memos to prove it happened.
Everyone involved knew about their own piece. Nobody had ever seen the three steps drawn on one page, because each lived in a different department and each department had documented its own part correctly. The documentation wasn't wrong. It was three accurate documents that added up to a problem none of them could show you.
When does documenting a process turn into redesigning it?
It turns the moment an interview produces an answer nobody can defend. When the only reason for a step is that it's always been there, or when two departments each believe they own the same approval, you've stopped documenting and started designing. Writing down a step you can't justify doesn't preserve it. It promotes it.
That promotion is the part I've watched go wrong more than once. A pointless step that lives in habit can be dropped by anyone who notices it's pointless. The same step written into an approved SOP is now in the training material, in the audit trail, and in the answer somebody gives a registrar who asks how the work gets done.
One shipping department I worked with ran a second inspection that a supervisor had added during a bad month in 2019 and never removed. It went into the procedure during a documentation project. It was still being performed, and audited against, two years later. Nobody on the floor had the standing to remove a step from a controlled document, and the person who'd added it had left. Writing it down had made a temporary fix permanent.
What does a process design project actually look like?
Four passes. Map what happens now, with the people who do it. Mark every step nobody can justify. Decide the process you want, with someone who can approve the change. Then write the procedure for the version you decided on. The writing comes last and it's the shortest part of the work.
The map has to come from observation rather than the org chart, and it has to cross departments. A process that lives entirely inside one department is usually already understood by the people in it. The expensive confusion sits at the handoffs, where each side assumes the other is doing something.
The justification pass is one question, asked of every step: what breaks if we remove this? Three answers come back. Something real breaks, and the step stays. Nothing breaks, and the step goes. Nobody knows, which is the interesting answer and the one worth chasing, because it usually means the step was protecting against a risk that no longer exists.
The decision pass is short, and it's where these projects die. A room full of people who can describe the problem and can't authorize a change produces a list of recommendations. Bring someone who can say yes.
Documentation comes after all of that. By then the procedure nearly writes itself, because the arguing is finished and you're recording a decision instead of negotiating one. If you want the mechanics of that stage, I've written about how to document a process and how to build an operations manual people use.
Who needs to be in the room?
The people who do the work, and one person who can approve a change. Without the first group you design something that won't survive contact with the floor. Without the second you produce recommendations that sit in a folder until the next reorganization. Get both, or wait until you can.
Our month-end close ran three days, and it ran three days because our controller knew which report had to be re-run after the inventory posting. I sat her in a room with the inventory clerk, which had somehow never happened in four years. The controller re-ran the report because postings often landed after her deadline. The clerk had been holding postings until the end of the day because a manager, long gone, had told her batching was cleaner for the system.
Two hours in one room, one decision, and the close dropped by a day permanently. Neither of them could have found it alone, because each was doing exactly what they'd been told and neither could see the other half.
Isn't redesigning first just a way to make the project bigger?
It can be, and it's a fair thing to ask before signing anything. Redesign earns its place when the mapping turns up steps nobody can justify. When a process is sound and simply undocumented, the honest answer is to write it down and leave it alone. I've given clients that answer. It makes for a smaller invoice and a better document.
The signs that a process needs design work are consistent. People route around the official steps. There's a workaround everyone knows and nobody wrote down. The same defect keeps arriving from the same handoff. Approvals pile up at one desk. Two people give you different accounts of who owns a decision.
The signs that it's fine are just as plain. People follow it because it works. The output is consistent. Exceptions are rare and get handled the same way each time. That process needs a writer, not a redesign, and telling you otherwise would be selling you something.
What if you already documented a process that should have been fixed?
Don't start over. Pull the procedures where you already know the process is wrong, fix those, and leave the accurate ones alone. A clear document describing a bad process is easier to repair than a vague one, because you can see exactly what needs to change and exactly who's affected when it does.
Rank the repairs by what the flaw costs, not by how uncomfortable the document is to read. A tidy procedure that adds three days to every purchase is worth more of your attention than a messy one covering a task performed twice a year. Fix the expensive ones, retire anything describing work you no longer do, and let the rest wait for their scheduled review.
The one thing worth avoiding is a full rewrite launched out of embarrassment. Those projects run for a year, exhaust everyone, and end with a shelf of documents that describe the same operation you had before.
When I take on technical writing work, the mapping conversation comes first, and sometimes it ends with me recommending less work than the client expected. More on how projects run is on the FAQ, and if you want to talk through a specific process, book a discovery call and bring the one that's costing you the most.
Frequently asked questions
What is the difference between process design and process documentation?
Documentation describes the process you have. Design decides the process you should have. A writer documenting a process asks what happens; a designer asks what should happen and whether each step has earned its place. The same interviews and maps feed both, but one produces a record and the other produces a changed operation.
Do I need process design, or just someone to write the procedures?
If people follow the current process, output is consistent, and exceptions are rare, you need a writer. If people route around the official steps, the same defect keeps arriving from the same handoff, or two people describe different owners for one decision, the process needs design work before anything gets written down.
How long does a process design project take?
For a single cross-department process, mapping and interviews usually take one to two weeks, the decision meeting takes a few hours, and writing the new procedure takes about a week. Larger programs covering many processes run longer, but the individual process is rarely the bottleneck. Getting decision-makers in one room usually is.
What happens if we document a process that should have been redesigned?
The flawed step becomes permanent. Once it is in an approved procedure it appears in training, in the audit trail, and in the answer given to an auditor, and nobody on the floor has standing to remove a step from a controlled document. Fixing it later costs more than questioning it during the mapping stage.
