The user didn't ask for your system. They were told to use it. They have a spreadsheet that works perfectly well, thank you. They've been doing their job for twelve years and the old way was fine. Now someone in IT has decided they need a "platform" and their first question is: why?
The Users Nobody Designs For
Most design processes assume willing users. People who chose your product, downloaded it, and want it to work. Consumer design is built on this assumption. Enterprise design can't be.
In enterprise, the person using the software often had no say in purchasing it. They didn't evaluate it. They didn't request it. It arrived in their inbox with a training video and a go-live date. Their existing workflow, the one they've refined over years, is being replaced by something a committee chose.
This is the reluctant user. And they're the majority of your user base in most enterprise deployments.
60-70%
of enterprise software features are rarely or never used after initial deployment
Source: Standish Group, 2022
Why Reluctance Is Rational
The reluctant user isn't being difficult. Their reluctance is usually rational.
They've seen this before. This isn't the first new system. The last one was supposed to transform their workflow too. It was fine for six months, then priorities shifted, funding dried up, and they went back to spreadsheets. Why would this time be different?
Their workaround works. The spreadsheet, the sticky notes, the personal filing system - these evolved over years to fit how they actually work. Your system was designed to fit how someone thinks they work. Those aren't the same thing.
Change has a cost. Learning a new system takes time. During that learning curve, they're slower and less confident than they were with the old tools. That's not just an inconvenience. For people whose professional identity is tied to competence, being a beginner again is genuinely uncomfortable.
The reluctant user isn't your enemy. If they can't see the value, the design hasn't communicated it.
Rainui Teihotua
Chief Creative Officer
Design Principles for Reluctance
Start With Their Current Workflow
Before designing anything, understand how they work today. Not the official process. The actual process. The shortcuts, the workarounds, the informal systems.
On a recent project, we shadowed claims processors for two days. The official workflow had twelve steps. The actual workflow had seven, because they'd figured out which five steps could be skipped without consequences. They were right. Those five steps existed in the process document but not in reality.
If we'd designed to the official twelve-step process, the system would have been slower than their workaround. Instead, we designed for the seven steps they actually used, validated with their managers that the five omitted steps were genuinely unnecessary, and built a system that was faster than the spreadsheet.
Make the First Day Easy
The first experience with a new system determines everything. If the first day is frustrating, you've lost them. They'll find ways to avoid using the system and they'll tell their colleagues to do the same.
The first day should accomplish one thing: let the user do something they already needed to do, faster or easier than their current method. Not everything. One thing. One visible win that proves the system isn't just bureaucratic overhead.
Respect Their Expertise
Enterprise users are domain experts. They know their job deeply. When a system makes them feel stupid - unclear labels, confusing navigation, error messages that assume technical knowledge - it's not just a usability problem. It's a respect problem.
Use their language, not your technical language. If they call it a "case," don't call it a "ticket." If they call it "lodging a complaint," don't call it "creating an incident." The system should speak their language, not ask them to learn yours.
Make the Transition Gradual
Don't remove the old system on day one. If possible, run both in parallel. Let users migrate at their own pace, one task at a time. The ones who see value will move quickly. The reluctant ones will move slowly but they'll move, because they can see their colleagues finding it useful.
Forced cutover creates resistance. Gradual migration creates advocates.
The Adoption Curve
In enterprise deployments, adoption follows a predictable pattern:
Week 1-2: Compliance. People use the system because they've been told to. Engagement is superficial. They do the minimum required.
Week 3-6: Comparison. They start comparing the new system to their old workflow. This is the critical period. If the new system is measurably better at anything, adoption grows. If it's worse at everything, they start building workarounds around the new system.
Month 2-3: Habituation or Rejection. By this point, users have either integrated the system into their workflow or found ways to minimise their interaction with it. The window for design improvements is still open, but it's closing.
Month 6+: The system is either part of the workflow or it's shelfware. By six months, usage patterns are set. If adoption is low at six months, it's very difficult to recover.
Measuring Adoption, Not Usage
Usage metrics lie. A system that's mandatory will have high login rates regardless of whether it's useful. Measure adoption instead:
- Are users doing more than the minimum required?
- Are they using features they weren't trained on (discovery)?
- Has the time to complete core tasks decreased over time?
- Have support requests decreased after the initial period?
- Are users providing improvement suggestions (engagement) or complaints (frustration)?
The difference between a system that's used and a system that's adopted is the difference between compliance and value. You want value.
The Conversation We Should Have Earlier
The best time to design for reluctant users is before you've chosen the technology. Spend time with the actual users. Understand their workflows. Understand their reluctance. Then design something that respects their expertise and makes their day measurably better.
The worst time to think about adoption is after launch, when usage is low and leadership is asking why the expensive new platform isn't being used. By then, you're retrofitting solutions to problems that shouldn't have existed.