What Self-Checkout Can Teach Us About Process Design
A familiar grocery-store machine offers a useful standard for judging workplace processes, particularly when the people using them did not help design them.
The first self-checkout machine I remember using was not especially elegant. The scanner hesitated over produce stickers. The bagging area seemed suspicious of every movement. An unexpected item was always appearing somewhere, even when nothing unexpected had happened. Still, after a few visits, the machine became ordinary. I stopped thinking about the sequence of prompts and began thinking only about getting through the store.
I do not know who designed that system. I could not explain how the scanner recognizes a barcode, how the scale distinguishes a bag of apples from a bottle of detergent, or how the software decides when to summon an employee. I have never seen its process map or sat in a meeting where someone debated the wording of the “place item in bagging area” prompt. None of this knowledge is required for me to use the machine.
That is part of what makes the self-checkout useful. The operating knowledge remains mostly inside the system. The customer is asked to understand only the portion necessary to complete the task: scan the item, place it in the bag, pay. Even the small changes that have accumulated over the years have generally arrived without requiring a new course. The interface shifted, the screens improved, payment options changed, and most customers simply continued.
I thought about this recently during a conversation about an AI-enabled process. Someone observed that the process was fast for them because they had built it. The comment was offered as evidence that the process worked. In a narrow sense, it probably did. A person who has spent hours constructing a workflow will usually know where the fields are, which prompts produce useful results, what to ignore, and how to recover when something fails.
The builder’s speed, though, tells us little about the experience of everyone else.
The person who designed a self-checkout machine can presumably move through it quickly. That would be an odd benchmark for the rest of us. We do not judge the machine by asking whether its designers remember which button comes next. We judge it by watching someone with a cart full of groceries, a child asking for gum, and a line forming behind them. The system has to survive distraction, imperfect attention, unfamiliarity, and the ordinary pressure of getting on with the day.
Workplace processes rarely receive the same test. A new tool is often demonstrated by the person who configured it. A learning team builds a workflow, tests it with colleagues who already understand the logic, and then presents a polished version to everyone else. The demonstration proceeds smoothly because the person driving knows what is supposed to happen. When the tool is released, the first users encounter the parts that were invisible during development: the naming conventions, the exceptions, the hidden assumptions, and the steps that seemed obvious only because the project team discussed them for six weeks.
The resulting friction is often treated as a learning problem. A guide is created, followed by a video and a live session explaining the guide and the video. Questions are collected, and a frequently asked questions document appears. Before long, the organization has constructed a small curriculum around a process that was originally introduced to save time.
Some processes genuinely require substantial learning. A new clinical procedure, financial control, or complex piece of equipment cannot always be made intuitive through interface design. Expertise has a shape, and some work asks people to develop it. But many workplace tools are not difficult because the work itself is difficult. They are difficult because the builder’s understanding has leaked into the design.
This happens easily with AI workflows. The person who creates the process has already learned how much context the model needs, which instructions matter, where outputs tend to drift, and what quality looks like. They may have developed a compact personal shorthand over dozens of attempts. By the time the workflow is handed to someone else, its apparent simplicity rests on a large amount of unspoken knowledge.
A prompt may look like a single step while depending on five judgments the user is expected to make. A template may reduce typing while increasing interpretation. An automated sequence may save ten minutes when everything works and consume forty when it does not. The builder knows when to intervene because the builder remembers the system’s history. The user sees only a box, a button, and an output that may or may not be usable.
In Learning & Development, this distinction matters because we are often asked to repair the distance between a process and its users. Sometimes that is appropriate. People need orientation. They need opportunities to practice and enough context to understand why the work is changing. Yet training can also become a way to transfer the burden of poor design onto the people least responsible for it.
I have seen this with learning platforms, performance systems, content templates, intake forms, and approval workflows. A project team spends months becoming fluent in the system. Near launch, someone asks what training will be needed. The answer is shaped by the team’s own fluency: perhaps a quick walkthrough, perhaps a reference sheet, perhaps nothing at all because the process feels straightforward. The first group of users then encounters a system whose logic reflects the meetings that produced it rather than the work they are trying to complete.
The training team is called back. At that point, it is tempting to add more explanation. Explanation is available, and design changes may not be. A job aid can be written this week. A revised workflow might require another round of approvals, technical work, or an uncomfortable conversation with the project sponsor. The practical choice is often to teach people how to navigate the difficulty.
Over time, this can distort the role of L&D. We become translators for systems that have not learned to speak clearly. We turn workarounds into competencies. We document avoidable steps and call the resulting document performance support. When users struggle, we measure completion, offer another session, and wonder why adoption remains uneven.
The self-checkout offers a quieter standard. It does not require the customer to understand the architecture behind the transaction. It reveals what is needed when it is needed. It provides feedback close to the action. Most of the time, it allows a person to recover from a small mistake without studying the system.
It is not a perfect machine. Anyone who has waited for an employee to approve an item knows that. Its failures are instructive because they are visible at the moment of use. The red light begins to flash. The customer stops. A staff member intervenes. The process has made its limits plain.
Workplace AI processes often obscure their limits. The output arrives with the same confidence whether it is useful or not. A user may not know that the result is weak until much later, when someone else reviews it or the work enters a consequential setting. The process can feel efficient while quietly moving effort downstream.
That possibility makes the builder’s experience especially unreliable as evidence. The builder is often the person best equipped to notice a weak result, correct it, and move on. Their fluency absorbs the flaws. What looks like speed may be expertise compensating for the system.
A more revealing test would involve someone who did not attend the design meetings. Give them the actual task, not a simplified demonstration. Watch where they pause. Notice what they have to infer. Count the moments when they leave the process to ask another person what the process means. Pay attention to the quality of the finished work, not only the time it took to produce.
This kind of observation can be uncomfortable because it changes the question. Instead of asking how quickly the process can be taught, we begin asking why so much teaching is necessary. Instead of admiring the elegance of the workflow from inside the project, we see what it asks of a person encountering it for the first time on a busy Tuesday afternoon.
The answer will not always be to redesign everything. Organizations live with inherited systems, contractual limits, technical debt, and deadlines. Sometimes people need to learn a cumbersome process because the process cannot yet be changed. There is honest work in helping them do that.
There is also value in naming the source of the difficulty accurately. A complicated process is not made successful because its creator can use it quickly. A workflow is not intuitive because the project team stopped noticing its assumptions. An AI tool is not saving time if the savings depend on the tacit knowledge of the person who built it.
At the grocery store, I can scan my groceries about as quickly as the person who designed the machine, although I have no idea who that person is. The design does not ask me to share their expertise. It allows me to complete the work without it.
That seems like a reasonable place to begin when we decide whether a new process is ready for everyone else.
