When a new system does not catch on in production, people usually look for technical causes: interfaces, performance, data model. That is rarely it. The cause is more often banal, and therefore harder to see: the system does not fit the hands that are supposed to use it.
The workstation is not an office
An operator at a reactor, an isolator or a filling line wears protective gloves, works under time pressure and keeps their eyes on the process, not the screen. They need to acknowledge an alarm, confirm a batch, record a fault. These are actions that often happen a hundred times per shift.
Software that demands nested menus, multiple confirmations and a fresh login for this was built for an office desk. For this workstation it is the wrong tool, even if it runs flawlessly from a technical point of view.
What happens next
The team solves the problem itself. It reaches for a clipboard, keeps tally sheets or builds its own spreadsheet where everything goes faster. That is not ill will. It is an attempt to keep production running.
For management, this is dangerous without being noticed. The official system shows clean data, while the actual work sits on paper and in files nobody has validated. The traceability the system was bought for has a gap exactly where it matters.
The rule
I work with a simple rule of thumb: every standard action at the workstation has to be done in about three seconds, with gloves, without detours and without an additional login. The number is not a standard or a measured value from a study. It is a limit against which designs can be tested before they are built.
Three consequences follow:
- Standard actions first. Which five hand movements does the team make most often? The system is designed for exactly those, not for the rare special case.
- Security fitted to the work situation. Login procedures and permissions have to suit the task. On the line, a badge or an identifier without a keyboard can offer the same protection as a long password, without interrupting the work. A rule that only works at a desk will be bypassed at the plant.
- Ergonomics before paragraphs. A requirement that fails in practice protects nobody. It creates workarounds, and they are harder to control than a pragmatic solution that is properly documented.
What this means for validated systems
In regulated production, the rule can be anchored in a place that is required anyway: the requirements specification. Anyone who describes not only functions there but the users’ hand movements can test them later. A test that measures whether an operator wearing gloves can complete the standard action in a reasonable time is just as legitimate an acceptance test as checking a calculation.
That saves money in the right place. Usability flaws are cheap before roll-out and expensive afterwards: then every change costs a change process, in a validated environment often a revalidation.
The spreadsheet is a requirement
Anyone who finds a spreadsheet in a plant that is maintained alongside the official system should not treat it as a violation but read it as a requirement. It shows exactly what the system does not deliver: which information is missing, which step is too long, which view is needed.
What follows
- Walk with the team, do not talk about it. Half a shift at the workstation shows more than a workshop.
- Record the most frequent hand movements and phrase them as requirements with a time limit.
- Evaluate existing workarounds. They are the most honest list of open requirements.
- Test at the workstation before roll-out, with the real protective equipment.
Acceptance does not come from training alone. It comes when the system visibly makes daily work easier.