Every automation project has a hidden stakeholder group: the people who will use it day-to-day. Skipping user research is one of the most common reasons a technically sound system is quietly abandoned or worked around.
Start by mapping your user cross-section. Teams are rarely uniform. Some colleagues are confident with new software and will explore it unprompted; others rely on a handful of memorised steps and feel anxious when a screen changes. Some work from a single device in a quiet office; others are on shared terminals, mobile devices or in noisy, time-pressured environments. Lloyds Banking Group (2024) found that fewer than half of UK workers can complete all of the essential digital skills needed for their job, so assuming baseline confidence is risky. A short survey, a few observed work sessions or informal conversations with a representative sample will quickly surface these differences.
Needs and resistance are connected. Venkatesh et al. (2003) grouped the drivers of adoption into performance expectancy, effort expectancy, social influence, and facilitating conditions: people ask whether a tool helps them, whether it is easy to learn, whether colleagues and managers endorse it, and whether support is available when something goes wrong. Resistance often signals an unmet need in one of these areas rather than simple reluctance to change. The Prosci ADKAR model (Prosci, n.d.) is a useful lens here: people need awareness of why a change is happening, desire to engage with it, knowledge of how to use it, ability to apply that knowledge, and reinforcement once it is live. Skipping any one of these stages leaves adoption incomplete.
Accessibility deserves equal weight alongside general usability. Designing only for the average user routinely excludes people with low vision, hearing loss, limited dexterity, or cognitive and neurodivergent differences, along with anyone working in a second language. Holmes (2018) describes this as a mismatch between the design and the person, and argues that solving for one excluded group, for example, someone using a screen reader, usually improves the experience for everyone else as well. The Web Content Accessibility Guidelines (W3C WAI, 2023) set out practical, testable standards covering how content should be presented, how interfaces should be operated, how information should be understood, and how systems should work reliably with assistive technology such as screen readers and voice control.
When designing or introducing an AI or digital workflow, build accessibility and adoption research in from the start rather than retrofitting it. Involve a genuine cross-section of users in testing, not just the most confident volunteers. Check colour contrast, text alternatives, keyboard navigation and plain language against recognised standards. Offer more than one route to learn the new system, for example written guidance, short demonstrations and one-to-one support, since people build confidence in different ways. Finally, treat launch as the beginning, not the end: reinforcement, feedback channels and visible quick wins are what turn early trial into lasting adoption.
Action Point
Before your next automation or AI rollout, identify a representative cross-section of 5 to 8 users. For each, note their technical confidence and any accessibility needs. Use this to test the workflow before wider release and to plan the support each group will need to adopt it confidently.