In 1996, I was a database developer at AT&T Solutions (now defunct). AT&T Solutions had two separate payroll systems, one for AT&T Solutions and one for AT&T corporate. Both were excruciatingly slow. My colleagues used to joke that we needed a separate accounting code for the time it took to enter our hours into both systems.
Being young and cocky, I decided I would ignore the corporate payroll system. This went on for about two months until my boss finally noticed a discrepancy between the two systems. (How vital was this system if nobody noticed that I wasn’t using it for two months?) My act of defiance earned me the chewing-out of my life and cost me both a raise and a promotion, and from then on I used both systems.
That experience taught me two valuable lessons about user adoption:
- User adoption is not a binary concept; there are many levels between wholehearted adoption and outright user rejection. Merely using a system is not the same as adopting a system.
- User adoption makes or breaks every IT project, whether it’s a CMS, portal, intranet, or other web application. You can build the most elegant system imaginable, but if the users don’t adopt your solution wholeheartedly, it’s unlikely you’ll realize any return on your investment.
Wholehearted user adoption means that users embrace your solution as part of their daily work routine. They rely on the system. In fact, they cling to it. The thought of accomplishing a task in any other way is unthinkable to them.
On the other hand, outright user rejection is fairly easy to spot. When traffic logs are flat, nobody logs in, nobody comments on your articles, nobody buys your products, and timesheets don’t get updated, you start thinking about sending your application to the island of misfit toys.
But what’s often just as damaging as outright user rejection (and much harder to recognize) is halfhearted user adoption. In this case, users interact with your system grudgingly and sporadically. Users do the bare minimum required to use the system, often to comply with organizational rules. But they do this unwillingly and without recognizing any personal benefit.
Symptoms of Halfhearted User Adoption
As I mentioned, halfhearted user adoption can be hard to spot, especially when site metrics are telling you that the system is being used. To help you figure out whether or not you have a halfhearted user adoption problem, here are three questions you can ask yourself:
Do you have to give incentives for using the application?
The need to bribe employees with bonuses or favorable performance reviews for using a system may indicate halfhearted adoption. If a system is truly vital to your employees, if it addresses their needs, and if it delivers value to them, then using the system will be its own reward.
Do you penalize non-use?
If you actually have to threaten people with disciplinary action, loss of pay, or loss of promotions to enforce adoption, you should take a step back and ask yourself what, if any, benefit the system provides to end users. If the answer is none, then we shouldn’t be surprised to find halfhearted adoption.
Do you invent reasons for using the system?
You’ve seen this before: a well-meaning web manager holds an online scavenger hunt to promote the launch of a new intranet or portal. The idea is that users will come for the Easter-egg hunt and stay for a message from the CEO. If a scavenger hunt is the only thing drawing users to your system, you may need to ask whether or not the system has a raison d’être in the first place.
Causes of Halfhearted User Adoption
It’s easy to blame the user for not embracing a system. And when I refused to use my company’s duplicate payroll system, it was certainly my fault. But most of the time, user adoption falls flat because of shortcomings in the system itself.
There are at least four causes of halfhearted user adoption:
The system isn’t designed for how users actually work
In 2007, I was assigned to determine why scientists at a biomedical firm were hesitant to share their research via a new knowledge management portal. My research found that one of the most significant barriers to adoption was that vital laboratory equipment was often located in other buildings, far away from the researchers’ desktop computers.
When researchers couldn’t access the portal where they actually did their work, they were much less likely to share the results of their experiments online. Instead, they recorded their findings in their lab notebooks. I’m not talking about notebook computers; I mean paper notebooks.
Sometimes the more diligent employees uploaded their findings to the portal, but never in large enough quantities to generate a meaningful ROI for the firm.
No benefits to end users
I’ve already told the story about my former employer’s two payroll systems. It’s possible that the management at AT&T Solutions believed they had compelling a reason for two payroll systems, but it certainly didn’t make me a more effective or efficient employee.
Poor system performance
In 2005, I was tasked with evaluating the content management system (CMS) of a highly visible federal website. Content contributors were dragged down by slow system response times from the CMS. Merely adding a link to a page took 15 minutes. Creating a new page could easily take an entire day. Still, the web managers dutifully used the system every day, unless they were in a time crunch.
When Hurricane Katrina hit the Gulf Coast, web managers updated the homepage every hour with new information about the government’s response to the disaster. They did this using Dreamweaver and a simple FTP client. When it really mattered, users abandoned the CMS altogether and reverted to 1995 technology. That’s halfhearted user adoption.
Lack of a Business Case
This is the classic barrier to adoption. Launching a web app without a clearly defined business case is like building your house on sand. If you haven’t defined a compelling business case for building your solution, why expect users to embrace it? Lack of a business case is often the single biggest reason for halfhearted adoption or outright rejection.
Achieving Wholehearted User Adoption
So now that we’ve discussed the causes and symptoms of halfhearted user adoption, we need to ask, how do we create wholehearted user adoption?
Think back to the symptoms of halfhearted user adoption and consider these three questions:
- Did anybody ever bribe you to use Facebook?
- Have you ever been penalized for not using email?
- Were you ever invited to play a scavenger hunt to get you to use Google?
The answer is probably “no” to all three questions. Why? Because Facebook, email, and Google are killer apps. Simply put, the apps themselves have driven wholehearted user adoption.
There are five key factors that promote wholehearted user adoption:
Usability
The system must exemplify the five pillars of usability: it must be learnable, memorable, effective, efficient, and error-tolerant. Above all else, it should provide an enjoyable user experience.
Commitment to user-centered design principles
Usable systems don’t happen by accident. Project sponsors need to commit to user-centered design—an approach to the software development life cycle (SDLC) that places user satisfaction (rather than executive opinion or developer prejudices) at the core of all design activities. This also means that project sponsors must invest in user research. Understanding the needs, limitations, and pain points of end users is the one of the most cost-effective investments you can make in your IT project.
Integration into the normal workflow
The system must be available in the proper medium, whether that’s a laptop computer, tablet, smartphone, or kiosk. And it has to be accessible in the proper context, when and where the user needs it. (Remember the lab scientists who had to go to another building to record their research findings?) Most importantly, the system must complement and facilitate the way the user would naturally complete tasks.
Delivers value for end users while achieving business goals
The system must deliver tangible benefits to all users, such as improving customer service, streamlining operations, increasing profits, reducing costs, or creating a competitive advantage. These benefits must be felt in some way by those in the trenches as well as by the brass.
Transformative effect
As bold as it sounds, your application must have a transformative effect. You want your users to ask, “How did we ever get by without this?” Think back to the last time you sent interoffice mail in a manila envelope. You probably stopped doing that around the same time you discovered email. Who would ever consider going back to those ratty old envelopes with all the scratched-out names? You want your project to have a similar effect.
Finally, consider enlisting the support of a UX consultancy to guide you through the design phase of your project. UX consultants can bring unbiased expertise to your team, advocate for the needs of end users, and clear away the barriers to wholehearted user adoption.
