Designing Work Before Automating It: A Human Factors Take on AI in Your Organization

AI can make work faster. But speed is only useful when we’re moving in the right direction.

When we add automation to a process that is unclear, repetitive for the wrong reasons, or full of hidden workarounds, we don’t fix the underlying design. We make its consequences arrive sooner. Before we automate, we need to understand the work: what people are trying to accomplish, where judgment matters, what creates friction, and what the situation requires.

That’s a human factors question as much as a technology question. Our perspective at LEMKTG draws on Lillian’s background in Human Factors Psychology and technology, including a master’s degree and ergonomics certifications. It also connects directly to our belief that systems should fit how people actually behave, not how a process diagram assumes they behave.

Start with the work people really do

A formal workflow rarely tells the whole story. People interpret ambiguous instructions, check details in another system, ask a colleague for context, and make decisions that may not appear anywhere in the process documentation.

Those actions aren’t automatically evidence of a problem. But they are worth understanding before we redesign or automate anything. A workaround may be compensating for missing information, a poor handoff, an exception the process doesn’t handle, or a task that takes more effort than anyone expected.

If we automate before finding out why the workaround exists, we risk making it harder for people to do what the work actually requires.

So we begin with questions, not tools:

• What outcome is the person responsible for?
• What information do they need to reach it?
• Where do they have to pause, repeat work, or seek help?
• Which decisions depend on context, experience, or relationships?
• What happens when an input is missing or something unexpected occurs?

This is the difference between automating a task as described and designing around the work as it happens. In organizational development consulting, that distinction matters: processes live inside teams, roles, systems, and the conditions people face every day.

Design for how people think and respond

Human factors looks at how people, tools, tasks, and environments shape performance. It gives us useful ways to assess an AI-supported workflow before deciding where automation belongs.

Cognitive load is the mental effort required to take in information, remember details, and make decisions. Automation can reduce repetitive effort. It can also add new demands: monitoring a system, interpreting its recommendation, noticing when it is wrong, and deciding whether to intervene. If a person must watch an automated process closely but has little to do until something goes wrong, we shouldn’t assume they will stay ready to catch every failure.

Situation awareness means understanding what is happening, what it means, and what may happen next. When a tool makes decisions without showing its state or basis, people may lose sight of how the work is progressing. A system that produces an answer but hides what information it used, what it missed, or where it is uncertain can make effective oversight difficult.

Error types matter too. Someone may miss a problem because they assumed the system had checked it, or they may follow an incorrect recommendation. Human factors research describes these as omission and commission errors. We can’t address them by simply telling people to “double-check.” The workflow needs usable ways to inspect outputs, surface uncertainty, correct mistakes, and recover safely.

That means designing the interface and process together. People need to know what the system is doing, where its limits are, and how to pause or override it. This is one reason NIST’s guidance on human-AI interaction emphasizes context, human roles, and the conditions around use, not just model capability.

Calibrate trust; don’t demand it

A useful AI system doesn’t need people to trust it unconditionally. It needs to make it possible for them to judge when its output is useful and when it needs review.

Trust calibration depends on the task and the context. If the input is incomplete, the situation is unusual, or the quality of an output is hard to verify, the interface should help people recognize that. Confidence without meaningful context can encourage over-reliance. Vague warnings can become background noise.

We can design for better judgment by making the system’s role clear. Is it suggesting an option, drafting something for review, or taking an action on someone’s behalf? What information did it use? What can a person change? What happens when the system is uncertain or unavailable?

These aren’t details to leave until after launch. They shape how the work is done and who remains accountable for it. NASA’s guidance on automated and robotic systems similarly highlights the importance of keeping people informed about system state and enabling effective intervention.

Automate the repeatable; protect the meaningful

Some tasks are good candidates for automation. Their inputs are clear. The steps are stable. Quality can be checked. They happen often enough that reducing the repeated effort can make a real difference.

Other tasks depend on context that is hard to capture, relationships that need care, or judgment about what matters in a particular moment. Automating those tasks may not remove the responsibility. It may only make the human role less visible and harder to perform well.

That doesn’t mean we should draw a rigid line between “human work” and “AI work.” The right division can vary by organization, team, and use case. We can design a system to prepare an option while a person decides, for example, or handle a routine step while keeping the person informed and able to intervene.

The goal is to give people time back for judgment, relationships, and meaning. We think of this as the gift of time, not an argument for replacing people, but a reason to reduce avoidable effort. If automation takes away a task but leaves people with less understanding, more monitoring, and unclear responsibility, we haven’t given them much.

For the same reason, digital experience design is not just a question of how an interface looks. It’s about whether people can understand what’s happening, make the decisions they need to make, and move through the work with confidence. Our Vibe Coding approach starts with that fit between the system and the people using it.

A practical checklist before you automate

Before we add AI to a workflow, we can use a few simple questions to test whether the work is ready:

• Are the inputs clear? If people regularly have to interpret incomplete or inconsistent information, fix that first.
• Is ambiguity low enough? If the right action changes with context, decide how that context will be handled.
• Can we measure quality? We need a way to tell whether the automation is producing useful results, not just producing them quickly.
• Is the task frequent and low in meaning? Repeated, low-value effort may be a strong candidate. A task involving trust, care, or consequential judgment may need a different design.
• Will automation preserve people’s understanding of the work? People should be able to see the system’s state, check its output, and understand when to step in.
• Can the team recover from a mistake? Define how to pause, correct, undo, or return to a safe manual process before the tool goes live.

These questions won’t produce one universal answer. They help us make a decision that fits the actual work, the people doing it, and the risks involved.

That’s also the approach we bring to our work as a marketing consultancy and organizational development partner: understand the context before choosing the intervention. Technology can create useful capacity, but it cannot tell us on its own what deserves to be made faster.

When we design the work first, we give automation a better chance of helping, and give people more room to do the parts of work that need them.