How can a traditional business reduce employee resistance to a new system?
No supplier can guarantee that every employee will welcome a new system. Involve frontline staff in research and trials, measure real task completion, time, and rework, and revise or pause rollout if the pilot does not beat the old process. Low adoption should not automatically be blamed on employees.
Age is rarely a sufficient explanation. The system may add duplicate entry, management may introduce monitoring without explaining its purpose, staff may fear punishment for mistakes, devices or connectivity may not fit the workplace, or training may teach menus instead of the job. Older users can have different visual, motor, or memory needs, but research should establish them; a “large text mode” is not a substitute for understanding work.
When turning a business goal into an executable scope, also compare Will you tell us which features to cut or postpone to save budget? and Why launch the core product first and iterate from real feedback?; the linked guidance adds context that should be considered in the same decision.
| Observed behaviour | Possible cause | How to test | Useful response |
|---|---|---|---|
| Paper first, system later | More steps or unsuitable device | Shadow work; count duplicate fields | Scan, defaults, offline draft, remove duplication |
| Reluctance to submit | Unclear accountability; no undo | Observe and ask about failure concerns | Preview, withdrawal, clear recovery messages |
| Training succeeds, work fails | Menus taught instead of tasks | Complete a real job without prompts | Role-based critical-task practice and floor support |
| A few proxy users enter everything | Access, devices, or responsibility never reached staff | Review use by person and shift | Clarify ownership, add devices, simplify entry |
| Many logins, work remains offline | Login is a target, not process completion | Reconcile records with actual work | Measure completed tasks and data quality |
Designers must visit or realistically observe where the work happens. Check text resizing, contrast, touch-target size, focus, labels, time limits, error correction, and alternatives to colour-only meaning. W3C's guidance on older users and web accessibility explains that WCAG addresses many age-related visual, motor, hearing, and cognitive needs. Dedicated industrial terminals may require additional environmental and device standards.
Pilot one team and one complete workflow. Establish the old process's completion time, errors and rework, waiting, requests for help, and time until data becomes usable. Compare the new process using completion rate, median and P90 time, manual fields per item, recovery rate, assistance, offline re-entry, and differences among user groups. If management reporting becomes faster while frontline workload rises materially, report both effects.
Management practice matters too. Explain why the process is changing, how collected data will be used, and how mistakes can be corrected. Do not use pilot learning errors for punishment. Retire the offline report that the system genuinely replaces; requiring both makes continued use of the old process rational rather than resistant.
Wavesteam can provide field research, prototypes, usability testing, and launch support, but cannot promise adoption from project count. We should deliver before/after evidence, issue and repair logs, and a recommendation to continue, revise, or pause. The client supplies real users and explains management policy. If access to users is unavailable, that adoption risk and the conclusions we could not verify must remain explicit assumptions.