Workflow automation versus design: which should I choose?

I choose a better interface when people struggle to understand, enter or correct information, and automation when the task is clear, repetitive and governed by stable rules. When both problems exist, I fix the design first, then automate the remaining routine work.

How to tell a workflow problem from a design problem

I start with one completed task, not a diagram of the whole organisation. For a client workflow review, I'd ask someone to show me their last expense claim, purchase approval or support handover. I want the actual records, including corrections. A process description usually tells me what should happen. The records reveal where someone had to interpret, chase or repair it.

I separate the effort into three categories: deciding what something means, entering or finding information, and moving information between places. Confusion over which budget code to select points towards design. Copying an agreed code into three systems points towards automation. Waiting for a manager who has no clear approval deadline may be a policy problem. Neither a new screen nor a bot fixes missing authority.

The useful question is where judgement belongs. If experienced staff disagree about the correct outcome, I wouldn't encode the disagreement as a rule. I'd first clarify ownership, terminology and acceptable exceptions. Workflow automation versus design is rarely a contest between tools. It's a decision about which part of the work is understood well enough to change.

What to measure before automating a workflow

I record active working time separately from elapsed time. A request might take two days to finish but require only six minutes of attention. Removing four minutes of copying won't solve a two-day approval queue. For an initial check, I'd inspect 20 recent cases, including failed and unusual ones. That's a diagnostic sample, not proof of the long-term error rate.

For each case, I note the number of handovers, repeated fields, clarification messages and corrections. I also record how often the task occurs and who absorbs the exceptions. A workflow completed 15 times a month has a different cost ceiling from one completed 1,500 times. Average completion time alone can conceal the difficult cases that consume most of the team's attention.

Suppose 300 monthly requests each need four minutes of copying. The maximum removable effort is 20 hours a month. If the proposed automation still requires one minute of review per request, that falls to 15 hours before maintenance and exception handling. Those are illustrative figures, but the calculation matters: I compare recoverable staff time with setup cost, subscription charges and ongoing care, not with an optimistic promise of zero work.

When a better interface should come first

I favour an interface fix when the same misunderstandings appear repeatedly: people choose the wrong category, miss a required attachment or cannot tell whether a request has been submitted. Useful changes are often small. Rename an ambiguous field. Show an example beside it. Carry forward information already supplied. Make the current status visible without requiring an email to the person handling it.

Consider an illustrative purchase request with 18 fields. If eight are only relevant to overseas suppliers, showing all 18 makes every requester inspect details most won't need. Conditional fields could reduce that effort without adding an automated decision. But hiding information has a cost too. I'd check that requesters can still understand what will be required before they start gathering documents.

I test the revised path with representative tasks and watch for successful completion, corrections and requests for help. Faster clicking isn't enough if the submission is less accurate. I also check keyboard access, clear error messages and recovery after a failed submission. I'd skip visual polishing that doesn't affect comprehension or completion. A calmer-looking form can still contain the same confusing rules.

When workflow automation is the better choice

Zapier explains its automation model through triggers and subsequent actions. I use that structure as a test: can I name the event, the required inputs and the permitted result without vague language? 'When an approved request receives a purchase number, copy that number to the finance record' is bounded. 'When a request looks sensible, sort out purchasing' leaves the important decisions unspecified.

Good candidates have predictable inputs, repeatable outcomes and exceptions that someone can recognise. I would automate copying a confirmed identifier before automating approval of an unfamiliar supplier. I also ask what happens when the trigger fires twice, a destination is unavailable or a record changes halfway through. The workflow needs a way to avoid duplicate actions, retry safely and expose failures to its owner.

Artificial intelligence changes the kinds of inputs a system can handle, not the need for control. Extracting a suggested category from a free-text request may be useful. Letting that suggestion authorise a payment is a different risk. I'd begin with reviewable suggestions, limited data access and a correction route. If a fixed rule does the job reliably, I wouldn't add a model.

How to scope an interface fix and an automation pilot

Basecamp's Shape Up separates the appetite for a piece of work from an estimate of how long a proposed solution might take. I find that distinction useful here. Instead of asking how long a complete process replacement will take, I decide what the problem is worth spending now. That budget forces a smaller, clearer intervention rather than a growing collection of connected tools.

For the hypothetical purchase workflow, I might allow three days to simplify the request form and five days for a narrowly scoped transfer between systems. Those are planning choices, not universal benchmarks. I'd define the boundary explicitly: one request type, one approval route and no historical migration. Supplier onboarding and policy changes would stay outside the pilot unless they prevent it from working.

Before building, I write down the questions that could invalidate the approach. Can the destination accept updates? Is there a stable identifier? Who receives failed requests? Does transferring the data require additional permission? I'd test those uncertainties before refining screens or constructing a long chain of actions. I'd also name one person who owns the workflow after launch, including changes to fields, permissions and business rules.

How to compare results and decide what to keep

I compare the pilot with the baseline using the same task definitions. If the original measure included corrections, the new measure must include them too. I'd track active time, elapsed time, completion without rework and time spent resolving automation failures. I also keep the case mix visible. A pilot handling only straightforward requests cannot demonstrate that the entire workflow has improved.

Where practical, I test the interface change before adding automation. That makes it easier to see which intervention helped. For a higher-risk automated step, I'd first generate proposed outputs without letting them change live records, then compare those outputs with reviewed decisions. Agreement alone isn't sufficient: I inspect the disagreements and their consequences. One incorrect payment matters more than several harmless formatting differences.

I set stopping conditions before rollout. Duplicate records, untraceable changes or failures without an assigned owner would pause expansion. If the pilot saves eight hours a month but needs six hours of maintenance, I'd question whether the remaining saving justifies the dependency. The next investment might be a clearer status view rather than another automated step. I keep the smaller solution when it produces the better operational result.

Questions people ask

Should I improve a process before automating it?

I first remove unnecessary steps and clarify decisions. I don't need a perfect process, but I do need defined inputs, outcomes and exception handling before automating a step.

Can a better interface replace workflow automation?

Sometimes. If most effort comes from confusing fields, missing information or unclear status, I would test an interface fix before connecting systems. Repetitive transfers may still justify automation afterwards.

When should I use artificial intelligence instead of rules?

I consider it when inputs require interpretation, such as classifying free-text requests. For predictable conditions and exact outcomes, I prefer rules because their behaviour is easier to inspect and test.

How do I calculate workflow automation savings?

I multiply task volume by the active time removed, then subtract review, maintenance and exception-handling time. I assess setup and subscription costs separately, and don't count shorter waiting time as recovered labour.

Where I checked my thinking

• Zapier: How it works
• Basecamp Shape Up: Set Boundaries