Planning for enterprise adoption

Maximizing and measuring ROI is a popular topic, both on the internet and with our clients, and rightly so. It can be nerve-wracking to consider spending money, time, and resources on a replatforming or implementation of a new system without any real idea of the extent to which it will be worth it. There are many, many considerations that go into evaluating ROI, but I know of one that can immediately tank internal projects, and isn’t talked about nearly as much as it should be: Adoption.

When you’re dealing with external customers, most people understand that you have to make an experience desirable or people won’t seek it out. When considering the ROI of internal projects, like intranets, CMS, ERP, PIM, DAM, or other kinds of enterprise solutions, there’s not a lot of thought given to how you make your employees want to use it. It’s apparently assumed that internal users are a captive audience, and if you build it, they’ll have to come. If we’re going to be realistic, we need to accept three hard truths:

1. Your system needs people to use it. If your system is one of the infrequent ones that has no human contact ever, good for you, you don’t have to think about adoption. Design it however you want to. For everybody else, success depends on people, whether you like it or not.

2. You cannot assume that people will use it. No matter how objectively better you think a solution is, people need a very good reason to change the way they do their work every day, and re-platforming or introducing a new system is inherently disruptive.

3. You cannot force people to use it. Sticks won’t work here, you need carrots. Even if you have the organizational backing to make your solution mandatory, if people do not want to use it, they will work around it. They have Post-Its and Outlook and telephones; they will find alternate routes, and your expensive new solution will be for nothing. In my years of consulting, I have seen some truly ingenious workarounds. People are like water, they will flow around the obstacles.

So, if we need people, they won’t start using it spontaneously, and we can’t force them to use it, how does any solution catch on? What causes adoption or resistance?

The Beaudry and Pinsonneault “Coping Model of User Adaptation” provides an explanation which reflects what I’ve observed on real-life projects. In the model, users come to a coping strategy for major IT change by evaluating the situation to see whether they feel like it is a threat or an opportunity, and then whether they feel like they have control over the situation.

Threat and opportunity

People evaluate an IT situation based on how risky they feel the new system is to them , not to the company as a whole.

Advice on adoption frequently focuses on trying to make sure that users understand how important the change is to the company, or making sure they understand that the new system is an improvement, but it’s important to remember that this is not, at its heart, a logical evaluation. Users are not taking in the totality of a situation, waiting until the end of your roll-out process, and deciding how they feel about it. They are deciding, in the back of their mind, whether this feels scary from the very beginning.

Control over the situation

Similarly, this is an evaluation that users make about their own situation. People run through their options, to figure out whether they are trapped or empowered by the system. The more control they have over the work —the autonomy to modify their tasks in response to a changing environment—, themselves —their personal ability to adapt to change—, and the technology —the degree of mastery they have over the features and functionality of the system—, the better equipped they are to deal with even scary situations.

In a quantitative study on the model in the European Journal of Information Systems, Elie-Dit-Cosaque and Straub express the model as a diagram:

Research model (from Elie-Dit-Cosaque & Straub 2011, adapted from Beaudry & Pinsonneault, 2005).

When users feel like the change presents an opportunity and they have control, they can focus on taking full advantage of the opportunities of the new system and making their own daily lives better. If they feel like it’s an opportunity but they don’t have control, they can use the system without it making their lives worse, but you’re unlikely to get real engagement.

When users feel like the change is a threat, but they have control over it, they see the system as a problem to be solved, and their role is to keep it from negatively affecting their life and work. If it’s a threat and they don’t have control, users tend to see the system as an attack, and try to avoid it, ignore it, and distance themselves from it.

Active adoption and engagement with a system depends on users feeling like it presents an opportunity, rather than a threat, and like they have control over their work, themselves, and the technology from the very beginning. I think it’s important to note that these are both issues of perception rather than objective truth. It’s unlikely that the average employee will have a great deal of control over an enterprise-level system, but giving them well-targeted capabilities can produce the feeling of control, as well as the very real ability to do their job well.

Addressing those feelings

• Use research to socialize the project: In some of the projects I’ve worked on, the first contact a user has with the new system is sitting down with a nice, smiling person, who wants to know all about them and how they do their job. In others, it’s a training PowerPoint where all the decisions have already made. People feel heard and important when they are part of the research process. Even employees who don’t directly participate in research sessions hear about it from their colleagues and know that an effort is being made.

• Identify what control users really need: Using research to really dig into their needs and workflows will also let you identify the control that’s important to your users. The average employee will not have a great deal of control over an enterprise-level system, but by zeroing in on their needs, you can ensure that they have the control they need over their own selves and work.

• Identify other pressures on users: The workplace is a complex system, and early research will help you identify the other pressures your users are under. Competing requirements for their time –or compensation– can create a context in which even a very well-designed system seems threatening and out of their control.

• Identify simple annoyances that you can fix, and tell them so: I’ve done a lot of user interviews, and the best part of my day is getting to say, “Oh, that thing? I can fix that for you. Let me write that down.” The key is, you also have to do it. Find the details that ruin peoples’ days, and make sure you fix them. They’re usually minor, from a technical perspective, especially if you plan for them early, and you avoid your users sitting down to the new system and realizing that you spent hundreds of thousands of dollars and a calendar year on a new solution and didn’t even bother to get rid of that annoying thing.

• Give users input into the final product through research and testing: You cannot rely on UAT or unmoderated usability testing alone for the final product, because they won’t catch the mistaken details that cause you to lose credibility and trust with your users. I’ve had these details be as small as the order in which four taxonomy terms were displayed. They didn’t prevent users from completing the task, but they did prevent them from feeling good about the system. These details need to be caught and fixed through moderated usability testing, with users thinking aloud.

Most internal projects don’t have a full UX work stream attached to them. It’s expensive and often seems superfluous, since these projects often focus on configuration, with minimal customization. I would agree that for many of these projects, prototypes, personas, and many of the other deliverables associated with UX are totally optional for the project’s success. Adoption, however, is not optional.  

For your project to succeed, you need people to use the technology; to get them to use it, you need to understand them. This understanding is what allows you to nudge the evaluations that users make in the right direction, helping them to see a new system as something that will make their everyday life better (not riskier), and will give them more control (not less.) A user-centered design process can easily fold into an implementation project, guiding the configuration decisions, even when a full UX workstream isn’t possible.

Q: Track down this source again.