Increasing the Adoption of UX and the Products You Design (Part 1)

Applying Diffusion of Innovations Theory

Just because it is great, doesn’t mean it will be adopted, used or even mildly successful.

~Anonymous

A few years ago, I was working for an organization attempting to determine how they could increase user adoption of their products. They essentially wanted to gain greater market share. I had a similar goal — a supporting goal. I wanted to increase the use of the software I designed for. I also wanted to increase the adoption of UX within the organization and build out a larger team.

Being in UX and having routine access to the users through research, some of the executives eventually began asking me about their goal of increasing market share. Seeing as how we were trying to solve similar problems, only with different objectives in mind, I began to work with the organization. The first step was to determine where the gap in adoption was. That is, we needed to find out why more users were not using our product. I had worked on projects like this before and taught a class in organizational behavior. So, I had a good foundation.

Whether you are attempting to advocate for UX and increase the adoption of your team services throughout your organization or are trying to increase the adoption of a product you design for, the end goal is the same. You are attempting to increase the adoption of an idea, concept or innovation. In so doing, there are certain aspects of adoption you must understand. You could have a well-designed product or a team of superstar designers and still fail to see any uptake from users. Why is this? Why do we see products like the Apple Newton fail and the iPad take hold just a little more than a decade later? Why do we see an organization fail to adopt UX one year and build a huge team with the appropriate support only a few years later?

To understand this, you must understand adoption and how innovations are disseminated. These innovations can be a new way of developing a product or the implementation of a new technology or idea — or the implementation of a new team like UX. Let’s take a look back in history to understand the true gravity of this phenomenon of human and organizational behavior.

In 1601, Captain James Lancaster of the British Navy conducted a study to cure scurvy. This was a deadly disease for sailors at the time and could easily wipe out half a crew or more on a ship. On a voyage from England to India, Lancaster administered 3 teaspoons of lemon juice per day to each sailor on one of his three ships. At the halfway point of the trip, 40% of the crew from the other ships had died of scurvy while none had died on the ship administering lemon juice to its crew. Despite this, the British Navy did not immediately adopt the practice of administering citrus to their sailors. Lancaster’s study was not actually repeated until 146 years later.

This is not an isolated incident. Ignatz Semmelweis was a physician in Vienna who discovered “germ theory” in 1847. Troubled at the high number of deaths in one maternity ward of the two he managed, Semmelweis began methodically excluding variables and proposing hand hygiene and better hygienic practices as the culprit in the higher childbirth death rate of one clinic over the other. Semmelweis was essentially laughed out of the institution he worked for proposing better hand hygiene. (Ironically, we still have trouble with hand hygiene in medicine today. I know because I researched this and worked on one of these studies more than a decade ago.)

How do we spread the adoption of a new technology or a new idea? How do we change human behavior to speed adoption? These are a questions Everett Rogers spent nearly his entire life pursuing. Rogers was a sociologist and communication theorist who developed the Diffusions of Innovations theory. His theory is complex. But for the purposes of this article, we are concerned with two primary aspects of his theory — how decision making occurs and the factors of an innovation that influence adoption.

Let me, first, be clear on what an innovation encompasses within the scope of this article. It could be a new technology — like a tablet or smartphone. It could also be a new concept — like hand hygiene in a hospital setting or providing citrus to sailors to avoid scurvy. Finally, it could also be the implementation of a new team within your organization — like UX.

Decision-making and how we really make decisions.

Humans make decisions to adopt an innovation in a staged process. We can be impulsive, most definitely. But when a decision requires considerable effort to adopt a new behavior or practice, we generally go through a series of stages in the decision-making process. Rogers outlines those steps. The five stages of the decision-making process are knowledge, persuasion, decision, implementation, and confirmation.

• Knowledge means you simply become aware that some new idea or concept exists. You know about it. You might not believe it will help you or even believe the claims behind it. But, you know it exists.
• Persuasion is when you know it exists and then begin to believe it might or might not be something that could be beneficial to you. The persuasion process is where you begin to actively seek information related to the innovation.
• The decision phase is when you analyze the innovation and look at the benefits versus the detriments. You then make a decision one way or another regarding the proposed innovation.
• Implementation is when you essentially try out the innovation or change to determine if it is useful or if it works for you.
• Confirmation is when you carefully analyze all of the data from your own experience and then confirm whether to continue or discontinue use of the innovation.

I had a doctor once explain this whole process to me. We were discussing physician education for a new treatment, medicine or medical procedure. He told me a single exposure or class or CME (continuing medical education — a class doctors must have a certain number of credits for each year to keep up to date) will do little to change physician behavior. He believed that was only the first step in the process — the knowledge or awareness stage. Consider a new medicine, for example. A physician might learn of it from a class on the subject or an advertisement. But, they won’t immediately adopt it and begin prescribing it. They may be exposed to it a number of times and still not prescribe it. But, then they might hear a colleague discussing it at a dinner and begin to think it might be of use — the persuasion stage. They’ll then look into the medicine further, look up some studies, ask another colleague or find evidence for or against prescribing — the decision phase. Based on what they learn there, they may begin selectively prescribing it to their patients and following up with them — the implementation stage. Depending on the feedback they receive, they will either continue use or discontinue use — the confirmation stage.

We don’t normally make important decisions impulsively (though we do in some instances). Adopting an innovation or changing our behavior is usually a staged process. And, if you are trying to influence your users to adopt a new technology, you have to keep human cognition in mind as it relates to decision-making. Understanding how we make decisions will accurately set your own expectations when you understand it is not necessarily a quick process.

Factors of an innovation that influence adoption

Once you understand how humans make decisions to adopt a given innovation or change their behavior, you then must understand the factors of an innovation that influence adoption. Rogers outlined five of these factors — relative advantage, compatibility, complexity, trialability, and observability.

• Relative advantage is the ability of a person to see how a particular adoption is advantageous to them. If humans decide to adopt a behavior, make a change or use a new product, they must first perceive there is some benefit to doing so.
• Compatibility is layered and refers to how well a particular concept, idea or innovation fits in with a person’s existing system. That system could be technology they currently use (i.e. software compatibility) or a belief system (i.e. cultural compatibility).
• Complexity is just what it sounds like. How hard will this new idea be to learn and adopt? How much time will I have to invest versus the relative advantage I perceive I will derive from adoption?
• Trialability refers to how easy it is to try a new innovation. The classic example would be receiving a trial period with a software platform or a new product. This is why 14 or 30 days free is so popular with software and platforms (think Netflix or paid subscription business models where they give you a trial period).
• Observability is the ability to see results — the ability to observe the results of adoption and weigh the benefits of an innovation, idea or concept.

The factors of an innovation are baked into the decision-making process described above. That is, these two activities take place in parallel. Let’s take a look at two very different examples — the adoption of UX within an organization and the adoption of a new product your team designs and creates.

When we are attempting to increase the adoption of UX within an organization, we have to see UX as an innovation in and of itself. It’s something new to the organization. Most of the time, we spend all our energy talking about how advantageous and important our work in UX is. And then, we never really go further than that. So, we are pretty good about outlining the ROI and relative advantage of UX and then not so good at addressing the other four factors of UX as an innovation. Here is what we need to address beyond the relative advantage:

Compatibility — UX is difficult in this respect. If you work in any sort of agile environment, you have to figure out where the design process fits into the sprint cycle. This is where UX is not compatible with many existing organizational processes for product development and it is arguably where we need to work the hardest in convincing product managers and scrum teams to use our services. Agile development does not routinely consider design as a part of the overall process. Design takes time and thinking and this is hard to fit into a rigid model with a tightly scheduled sprint cycle. If we can’t be compatible with the existing process, we will make little gains in ensuring our services are adopted.

Complexity — This is a layered concept. Do people understand UX? For the most part, we are pretty good at breaking down difficult design concepts and the design principles supporting those concepts. However, I have been in more than a few meetings that became heated as a result of UX advocating firmly for a solution based on design principles they believed were foundational. This brings us to another layer of complexity. How easy or hard is it to work with the UX team? Building relationships is important. If you are just too hard to work with, the complexity level will become too high and teams will begin avoiding you or finding a way to work around you (the workaround). From my own personal experience, UX can sometimes make the entire development process simpler while other times they can make it extremely complex. This is the subject of another article I am currently working on, but designers can often turn a simple process into a long, drawn-out journey of discussion and arguments that really don’t impact the user experience or product success at the end of the day.

Trialability — What is the risk associated with involving UX? Is it easy to implement and “try out” UX? This usually isn’t too much of a problem once an organization has begun to build a team and they are on the payroll. This is usually a more difficult problem in convincing an organization they actually need to hire a team. That requires significant effort and fund allocation.

Observability — Can the organization see the benefits resulting from UX implementation? This can be a difficult trait to analyze and plan for. Research can certainly help in this endeavor — especially when you are working on an existing product that has known usability and user satisfaction issues. I have had instances where I could show the before and after of user satisfaction with a finger clearly pointing to better design at the root. Another issue to consider is how much rework or revision a product required. Did UX implementation result in a savings of time or money and result in a better product? Observability is simply measuring the benefits of an implementation.

An innovation can be a number of things beyond simply implementing a new team. Most obvious to this theory is the implementation or adoption of a new technology. UX atypically works on technologies. Building the screens and fleshing out the design is only part of that. Working to ensure a higher rate of adoption is an even greater challenge. This article started with a scenario from a previous position I held. Let’s return to that example.

At GN ReSound, we were trying to sell more hearing aids. In the process, we were attempting to determine what barriers there were in this endeavor. UX had been interviewing and conducting observation research with a number of users. I had also designed a survey that had been sent out nationally and did both the quantitative and qualitative analysis. We found the complexity of the product was a primary deterrent. This revolved mostly around a suite of products we had developed to include the software and Bluetooth connectivity we used to adjust the hearing instruments.

The relative advantage was clear. Not having to hook hearing instruments up to a series of convoluted wires (while they are in a patient’s ears) in order to fine tune the settings via the software was a major benefit. Compatibility was not an issue because we provided everything the audiologist needed at either a very low cost or for free (the software was free). Trialability was a small problem in that there was an investment of time and energy required to learn the software and technology. But, that was a small hurdle we determined did not significantly prevent adoption. Observability was clearly not a problem when everything worked as it should. The complexity was where we struggled the most.

Connecting to devices and managing the software to fine tune settings posed a number of problems our team identified through research with users and work with our U.S. call center. I won’t go into it all here. Suffice it to say, the learnability and memorability of the software and processes to fit a hearing instrument were lacking — despite the technology being superb. This cost us sales, accounts and customers.