UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 697 July 12, 2011

Overcoming Halfhearted User Adoption

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:

  1. 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.
  2. 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.

ABOUT THE AUTHOR(S)

User Profile

Don Bruns directs the Application Design practice at NavigationArts, a Washington, DC based digital consultancy. You can find him at donbruns.net.

Add new comment

Comments

13
19

I'm not sure I'd agree with the assertion that Facebook is either learnable or usable - and some of us actively avoid it despite the bribery of being in touch with people we can't get easy access to any other way.

But that's more about usability being a sliding scale and use/experience dependent. :)

14
15

Mark, that's an excellent point.  The situation you describe seems to map (at least partly) to the idea of designing the system to reflect the way users actually work.

So knowing that the corporate culture does not encourage collaboration, how do we design a system that both:

  1. provides some collaborative benefit that is relevant and appropriate to the corporate culture, and 
  2. encourages users to become more collaborative going forward

The alternative is that we're trying to shoe-horn the users into a solution that doesn't reflect how they truly operate, and that's one of the key ingredients of half-hearted adoption.

It's a tough challenge, and there's no easy solution. But I guess that's why we've got job security. =)

16
14

Nice article, thanks!

An additional reason for half-hearted adoption may be corporate culture. In the case of collaboration tools, for example, there could be practical use cases and quality implementation but if there is not already a corporate culture of collaboration, adoption might be tepid.

13
14

Thanks for the feedback, Juan and Luke.

Luke, that's a very interesting question. I don't think Captcha is the problem. I'm not sure there's even a *problem* per se.

When an article sums up everything, often there's no need for comments. But when an article poses a difficult question or makes a potentially controversial statement, then you'll likely find tons of comments.

I may not get many very comments to this article because I believe most UX practitioners will agree with what I'm saying. But if I said something like, "The way most of us do user research is ineffective, and here's why..." you can bet that readers would comment.

Just my theory anyway.

20
16

Surprising there is no comments on many of the uxmag's articles or there is at most half-hearted input. What would the author suggest to improve the comments ux - make it transformative? Get rid of the captcha?