What counts as friction?

In a workflow, friction is effort that makes progress harder. Some of it comes from the work itself: comparing conflicting evidence, finding the right explanation, or deciding between legitimate alternatives. That difficulty may be necessary.

Other friction comes from the machinery around the work:

• Entering the same information into several places.
• Searching for the current draft among nearly identical filenames.
• Rebuilding context after switching tools.
• Repeating a predictable export or formatting sequence.
• Checking whether a save or submission actually succeeded.
• Recovering work that an interface failed to preserve.

These are often good candidates for automation or better interface design. Removing them does not necessarily remove a meaningful decision. It may simply stop the system from asking a person to compensate for its awkwardness.

But friction is contextual. Naming a file may be clerical in one workflow and an important act of classification in another. A reliable filename generator can help with the first. In the second, it may need to suggest a name while leaving the classification open.

The useful question is not “Can this step be automated?” It is “What purpose does this step serve, and can we reduce its burden without losing that purpose?”

What thinking needs to remain?

Thought includes more than making a final choice. It includes noticing that the available choices are wrong, recognizing missing context, reconsidering an assumption, and deciding not to proceed.

A workflow can retain an approval button while quietly removing these opportunities. If a person sees only a polished recommendation, without its evidence or uncertainty, their role may have narrowed from evaluation to acceptance.

For human judgment to remain meaningful, people need enough information and practical freedom to exercise it. Depending on the task, that may mean being able to:

• Inspect the source material rather than only a summary.
• Distinguish a recorded fact from an inference or suggestion.
• Understand what changed since an earlier review.
• Edit, reject, defer, or choose another route.
• Stop an action before it creates an external consequence.
• Recover from a mistake without losing unrelated work.

This is why human-in-the-loop systems need more than human presence. The person needs a useful position in the workflow, with information, time, and authority appropriate to the decision.

Not every routine action requires individual approval. Well-defined, low-risk actions can often run automatically within agreed limits. The important distinction is between deliberately delegating an action and allowing a system to acquire authority merely because it can execute it.

What this looks like in practice

Writing and publishing

A writing tool can preserve drafts, maintain revision history, check for broken links, and prepare clean HTML. It can also help an author explore an outline or reconsider an unclear passage.

None of those capabilities makes a completed draft permission to publish.

A useful workflow keeps preparation and release distinct. The author or editor can inspect the article, check its claims, revise its language, and decide whether it belongs in public at all. A saved revision remains a saved revision until a separate publishing decision occurs.

The mechanical work becomes lighter while editorial review and responsibility remain visible.

Research and retrieval

A retrieval system can gather relevant passages, group duplicates, and help someone find material they would otherwise spend hours locating. An AI-assisted tool can suggest connections or summarize an argument.

The boundary matters when those preparations become a conclusion. A relevant passage may be outdated. Several apparent sources may repeat one original claim. A fluent summary may omit the exception that changes the answer.

Automation supports thought when it preserves a route back to the evidence. It weakens thought when it makes the synthesis easy to accept but difficult to check. Grounding AI-assisted answers requires attention to that connection, not just the appearance of a citation.

Forms and administrative work

A form can remember information already supplied, save progress, and identify a missing attachment. Those features reduce effort without deciding what a person intended to say.

Automatically choosing a consequential response is different. So is submitting a form because all required fields are complete. Completeness establishes that the form meets certain input requirements; it does not establish that the person is ready to send it.

A good interface reduces repetitive entry while preserving review and correction before a consequential submission.

Workflow recovery

Automation can retry a failed read operation, restore a draft, or resume a known-safe processing step. But uncertainty about an outcome needs different treatment.

If a request to create an external record times out, the record may still have been created. Repeating the request without checking can produce a duplicate. Here, useful automation investigates the existing outcome or uses a supported duplicate-prevention mechanism rather than treating uncertainty as failure.

Retry safety is a practical example of the larger principle: removing effort should not remove the distinction between what is known and what is merely assumed.

Preserve useful pauses

Not every pause is a defect. Some pauses give a person the chance to recognize a consequence.

Reviewing the recipient before sending a sensitive document, comparing changes before replacing a published page, or checking the scope of a deletion can all be useful. The goal is not to make every action feel equally effortless.

At the same time, a confirmation dialog is not automatically a safeguard. Repeated, vague prompts can become another mechanical task: click through so the work can continue.

A useful pause makes the decision clearer. It identifies the action, the affected material, the relevant changes, and any limits on recovery. It appears where attention matters rather than interrupting every harmless step.

For example, “Are you sure?” offers little context. “Replace the published article with this revision? Three sections have changed” gives the reviewer a more meaningful starting point—especially if the changes are available to inspect.

A pause earns its place by helping someone understand or control an outcome, not by adding another click.

How to design the boundary

Before automating a step, describe it in ordinary language. Avoid starting with the capabilities of a tool. Start with the burden someone is carrying.

1. Name the burden. Is the person repeating an entry, locating information, remembering state, interpreting evidence, or authorizing an action?
2. Identify the judgment inside it. What, if anything, needs contextual interpretation? Would reasonable people make different choices?
3. Consider the consequences. What happens if the automation is wrong? Does it change private working material, affect another person, or create a public commitment?
4. Set the authority boundary. Can the system prepare, recommend, execute within limits, or act only after approval? These are different permissions.
5. Preserve visibility and recovery. Make relevant inputs, changes, outcomes, and failures understandable. Keep a practical way to correct or stop the work where possible.
6. Test the exception. Try missing information, changed circumstances, interrupted connections, and an explicit decision not to continue.

These questions help establish automation boundaries that match the task rather than the convenience of implementation.

The boundary may also change over time. A step initially requiring review might become safe to delegate after its conditions are well understood. An automated step may need review again when its inputs, consequences, or operating environment change.

That is maintenance, not a failure of automation. Delegation works best when its conditions remain explicit.

Measure what remains possible

Time saved is useful, but it is not the whole result. A workflow can become faster while becoming harder to understand, question, or repair.

After introducing automation, ask what the person can still do:

• Can they explain what happened?
• Can they find the evidence behind a recommendation?
• Can they recognize that something is incomplete or uncertain?
• Can they disagree without rebuilding the workflow from scratch?
• Can they resume after an interruption?
• Can they stop before the next consequence occurs?

These are not arguments for keeping people busy. They are ways to check whether reduced effort has produced greater capacity or merely less involvement.

Sometimes the best improvement is modest: the correct file stays selected, the draft survives a closed tab, a change is shown clearly, or the system reports what actually succeeded. Nothing makes the substantive decision easier than it should be. The machinery simply stops getting in the way.

Automate the copying, carrying, checking, and remembering where doing so is reliable and appropriate. Use tools to support exploration and understanding. Keep consequential authority explicit.

The point is not to preserve every manual step. It is to preserve room for thought.