Optimizing Designs for New Users
In my last article of this series, I wrote of Everett Rogers’ Diffusion of Innovations theory and how it can be used to speed the adoption of a new idea, product or design. Along those same lines, this article will focus on transitioning users to a new interface or platform. We are still discussing adoption, but with a slight twist. We are now focusing more on change management, which is essentially adoption and focusing on a platform, product or new feature.
There are a couple of scenarios where the concepts discussed in this article may be particularly applicable.
- You may be rolling out an entirely new system. Perhaps the old system is a legacy system and you are replacing it. Or maybe it is a revised version of an existing website you are completely overhauling. These are design projects where you are likely changing the entire site or platform architecture while also giving the product a new look, feel and adding or updating the existing functionality. In short, the new system will pose a major change for your users in how they navigate, interact with and use the product to achieve a set of given tasks.
- In another scenario, it may be you are attempting to transition users from a competitor’s system to your system. You may have conducted a competitor review, matched the findings to produce an updated roadmap and built out new features to give your platform a competitive edge. At this point, you may essentially be attempting to migrate (or steal) users from your competitor’s brand to your own.
The scenarios are different in these two examples. But, the goals are the same. You essentially desire to transition users to a new design or product and make the process as painless as possible. I had this same problem — one I described briefly in part 1 of this series.
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. 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.
At GN, there was the notion our product might have a level of complexity preventing new users from migrating to our brand. That is, we were interested in the design features in our software that might serve as a barrier to new user adoption.
What we found in many cases was new users would try out our product or application, find the learning curve too steep and move back into their comfort zone (i.e. their original brand of choice). Users were simply returning to what they were familiar with.
Familiarity (even with a less usable product) is often difficult to contend with if you are attempting to gain market share. However, often users revert back to their previously used products for various reasons — most notably, the new product doesn’t provide significant benefits or features over their brand of choice.
Familiarity and complexity are intertwined. The example I always give is a remote control. These devices are almost always rife with complexity. We, as users, manage to overcome the complexity and gain a sense of familiarity with the device. Even if you designed a better remote control, it’s likely your users wouldn’t be too happy if you gave them the device. Even though it is more usable, in many cases the user has become familiar with the less usable and more complex older design.
Familiarity can be gained with a product. But, in order to speed adoption, the effort a user must expend to gain familiarity must be balanced with two things. The complexity (from Rogers’ theory) mustn’t outweigh the relative advantage of learning the new product. That is, if I decide to learn how to use a new design tool (Sketch for example), the complexity of learning that tool can’t exceed the threshold of the relative advantage. If the advantage of learning the tool is worth the effort in overcoming the complexity of the software, I’ll adopt it.
A note on new users versus experienced users: There was a notion among my colleagues at GN concerning the issues experienced by new users. They had dubbed these problems “Migration Issues.” My contention was these were really just usability issues that both new and experienced users must contend with. The difference between these user groups (new vs. experienced) is prominently one of familiarity as I mention above. Personality types, determination, tolerance for technology and the value of the product as well as other variables, of course, play a role in a customer’s decision to adopt your product. But a new user and an experienced user will generally have the same usability issues (experienced users have just figured out how to get around those issues). I believed addressing those issues would conceivably satisfy all user types — expert, experienced or novice.
All of this is not to say there are not different needs between the expert and the novice user. After all, the Novice-Expert Ratio Method exists for a reason. And there are certainly pathways and tools you can give a new user to speed adoption the expert will likely not need or use — tools that may enable the new user to breach the learning curve and mitigate the complexity of the innovation. Since complexity was what we were struggling with the most in relation to Rogers’ theory, we started with basic usability principles.
When defining usability, Jakob Nielsen outlines 5 basic qualifying components:
The two we were most concerned with in relation to new users was Learnability and Memorability. Satisfaction would have been a distant third, but more of a concern for all users — novice or expert. Learnability simply refers to how easy it is for a new user to learn a system or interface. Memorability refers to how easy it is to remember what was learned in addition to remembering how to perform tasks and procedures in a system.
The systems we create in healthcare are, atypically, very complex systems often requiring us to design for learning. Some organizations (and software platforms) attempt to address this by building robust help systems with search and filter functions. While I have seen some pretty good attempts over the years, these help systems are less likely to be used by a novice than an expert. And if they are not well designed in terms of their search and underlying taxonomies, they will be used by no one.
Help should be contextual. That is, give me the right information at the right time when I need it most. This requires an in-depth understanding of the user and pain points in their workflow when using your product. However, contextual help is the “low hanging fruit” in terms of providing higher learnability in a system. Tooltips, walk-through tutorials and coach marks are also easily implemented learning tools. The visual aspect of design can also induce learning (as well as memorability). (I would highly recommend Interface Design for Learning: Design Strategies for Learning Experiences (Voices That Matter) by Dorian Peters for more on this topic.) Essentially, you have to give a new user a starting point and walk them through the interface providing help along the way. But, you have to keep that content available for future use, which brings us to memorability.
Have you ever had to change the page numbers in Microsoft Word? For example, perhaps you have a document (like a thesis) requiring Roman Numerals in the front matter and regular pages throughout the rest of the document. But, there should be no numbers on the chapter heading pages and the subsequent pages must not skip a number. This is a common requirement for dissertations. It can be done. But it is hard to remember how to do if you don’t format dissertations as a profession. Another example: My Toyota Camry currently has the maintenance light on. It just needs an oil change, but since I use synthetic oil, I don’t change it as often as the chip in the car thinks I should. I have to look up how to turn that light off every time it comes on. These are examples of systems in which memorability is an issue.
The Microsoft example is a little less common. But the Camry example occurs every 5,00 miles — just long enough (and a complicated enough of a process) for me to forget how to address it. Memorability is important for all users in a system. But I would argue it is more important for new users when learning a system. Once again, knowing the user and their pain points is key to identifying where you need to employ this technique. Latent help messages in a system can help but are usually a workaround for poor usability. In the Camry example, it would be ideal to simply have a button to reset the maintenance light. In the Microsoft example, changing a set of page numbers in a section could be made simpler — perhaps just a right click function to apply a number to only a single page or the ability to select multiple pages and set a range of numbers.
Establishing good learnability and memorability are key aspects of addressing complexity in a system to speed adoption. But, there are other aspects of users to consider. In About Face: The Essentials of Interaction Design, Alan Cooper has a chapter covering this (Chapter 10, 4th Ed. “Optimizing for Intermediates”). In this chapter, Cooper and his co-authors delineate three levels of users in relation to experience — beginners, intermediates and experts. He indicates the distribution of these users follows the standard Bell Curve with intermediate users comprising the largest proportion in the middle. New users fall on the left and expert users fall on the right of the Bell Curve.
Most users remain in a state of “perpetual intermediacy” and if you think about your own behavior with applications, you’ll find this is generally true. I’m not an expert at using MS Word, but not a beginner either. I fall into a state of perpetual intermediacy with that product where I know it well enough to complete most of my daily tasks. Experts, on the other hand, are essentially power users who will want access to powerful features, shortcuts to many things and will often require the use of obscure features.
The object with this model Cooper provides is to move the beginner, as quickly as possible, from a novice state to an intermediate state. Consider this: No beginner wants to stay a beginner forever. You either gain a basic set of proficiencies with a product or you abandon it. If the learning curve is extremely high and memorability extremely low, many users will be unlikely to obtain that state of intermediacy, become frustrated and will be more likely to abandon the product.
Jared Spool has a similar model he has recently written about in his article, What Makes a Design Seem ‘Intuitive’?. Essentially, Spool contends users approach a system with a given amount of knowledge. He refers to this as their “Current Knowledge State.” In order to use the system proficiently or accomplish a given set of tasks within the system, the user must have what Spool terms as the “Target Knowledge State.”
The distance between the current knowledge state and the target knowledge state is what Spool refers to as the “Knowledge Gap.” It is quite possible for a user’s current knowledge to match the target knowledge they need to use a system. (Thus, they have no knowledge gap.) Many times, however, this is not the case and we have to move a user from their current knowledge state to the target state in order to fill the knowledge gap and facilitate proficient use of the system.
Spool states it best:
“Users can complete their objective when current knowledge equals target knowledge. There are two ways this can happen. You can train the user, thereby increasing their current knowledge, until they know everything they need to know. Or, you can reduce the knowledge necessary, by making the interface easier, until target knowledge only requires the information the user already has. In fact, most good design involves both: users are trained (through explanatory text and other devices) while the designer reduces complexity, reducing the gap distance from both directions.”
Let’s return to Cooper’s model. What aspects can a UX designer use in an interface to increase adoption or to make it easier for a user to transition to your product? Here are some tips:
- Help — as mentioned above, tooltips, pop-outs that explain features, on-boarding tutorials and features of this nature are perhaps the best methods of increasing learnability. But, these features must be latent. That is, they should not get in the way on subsequent use, but should allow a user to access them again (or remain hidden until hovered over) should they need them. This is especially true of an application the user might not use daily or weekly. We are likely to forget how to do things, which is where memorability comes into play and how help features can aid.
- Menus — Cooper aptly notes beginners often use menus to develop familiarity with a system and what it accomplishes. Make sure your labels and menu items (as well as the action dialogs they invoke) are clear. Card sorting and sometimes search log analysis can help in informing designers as to what the user’s verbiage is.
- Navigation and Menu Simplification — If you use Adobe products, you know what a complex menu-driven interface looks like. It’s an interface designed for an expert. Thus you should design your interface for an intermediate user. Hide navigation items that are rarely used — slim it down. This, of course, requires some metrics on how the system is used. So perhaps that is a first step. However, a streamlined interface will prevent overloading the user with options.
- Degree of Dislocation — Cooper uses this phraseology to indicate how suddenly an interface changes. In short, if your interface changes significantly as the result of a command executed by the user, make sure this occurs later in the user manipulations (deeper in the system) and not in the outer layers of a system.
- Irreversible Functions — an example would be restoring your phone to factory settings. Ensure these features are not easy to get to and afford forgiveness. There is nothing that will turn a new user away quicker than not allowing them to recover from a catastrophic error and making them feel stupid.
- Transference — make it simple for a new user to transfer settings, connections or to translate new terminology. An example is how easy Apple makes it for you to switch to a Mac and get your files from an older PC to your new computer. Or, when Google+ came out, they helped you find your connections on Facebook. Translating terms can be a little trickier, but you can provide methods (cheat sheets) for users to understand the linguistics in a new interface depending on your application.
Adhering to these principles will not only satisfy new users and enable them to more quickly adopt your product, but will also satisfy your perpetual intermediates and often address issues expert users find annoying but work around anyway. In the end, new users may require special tools to enable adoption, but generally speaking, a usability issue is still a usability issue and it is usually one that exists for all users regardless of their level of experience.
As I noted in part 1 of this series, an innovation can be a number of things. It can be a new process, a new technology or even a new team like UX being introduced to an organization. Applying Rogers’ theory to any and all of these innovations is a means to enable and speed adoption. The key is to investigate potential barriers to adoption and ensure the relative advantage, compatibility, complexity, trialability and observability have been optimized. Identifying where the barrier lies within Rogers’ theory will enable you to address key issues in adoption.
In the case above, we identified complexity as the primary barrier. We addressed this through applied usability principles and were eventually able to increase market share. This was no overnight process at GN and the work took more than a year. However, having a framework was a key component in guiding us towards a solution.
In part 3 of this series, we will explore the different means of communication for an innovation, the varying user personality types and how each of these affects the adoption process. Part 3 will also pull everything together into a cohesive framework for practical application.