In this column, I want to further explore one of the issues I mentioned in my inaugural column. I call it the problem of the perpetual super-novice. What is this? Simply put, it’s the tendency of people to stop learning about a digital product—whether it’s an operating system, desktop application, Web site, or hardware device.
After initially becoming somewhat familiar with a system, people often continue using the same inefficient, time-consuming styles of interaction they first learned. For example, they fail to discover shortcuts and accelerators in the applications they use. Other people learn only a small portion of a product’s capabilities and, as a result, don’t realize the full benefits the product offers. Why? What can operating systems, applications, Web sites, and devices do to better facilitate a person’s progression from novice to expert usage?
Champion Advertisement
Continue Reading…
First, I’ll take a moment to define some terms. Here are three classifications for levels of user expertise I typically employ when discussing this issue:
beginner—The beginning user has never before or rarely used a particular digital product. For beginners, almost every interaction with a system is exploratory. Their physical movements—and the on-screen representations of their movements—are mostly explicit and thoughtful. During this phase, users are trying to figure out what a product does and how they can use it. They are actively acquiring knowledge and creating and modifying their mental models.
novice—The novice user has ascended the learning curve somewhat. Novice users have committed certain basic operations of a system to memory—either cognitive or muscle memory. They are comfortable within a circumscribed portion of a system’s total functionality. Their mental models of how and why a system behaves as it does are by no means complete—and in fact, might be quite inaccurate. But their limited knowledge has no adverse effects, so long as novice users stay within their comfort zones. If novice users need to learn some new area of functionality, their behavior reverts to that of a beginner while learning.
expert—The expert user not only has mastery over many aspects of a system, the user’s mental model of the system is complete and accurate enough that learning a new area of functionality occurs rapidly and easily. Expert users not only know a product; they know how to learn more about the product.
Certainly, people become experts when there is a strong extrinsic motivation to do so. For example, you might learn how to do a mail merge in your word processing application, because, well, the boss just asked you to do a mail merge. But in the absence of extrinsic motivation, it seems that many people stay novices or, at most, become a form of knowledgeable novice that I call the super-novice. Super-novices know a lot about the limited parts of a system they use regularly and almost nothing about the other parts.
The thing is, people’s mastery of systems in other domains tends to expand naturally as people become more and more experienced with the systems. For example, a novice bicycle rider at first sticks to the basics—mount the bike, pedal, brake, turn, dismount. As new riders gain more experience, they tend naturally to explore the capabilities and performance characteristics of a bicycle. Can I hop a curb? What happens if I lock the brakes? How easily can I pop a wheelie?
Most desktop and Web applications do a so-so job of encouraging users’ exploration and mastery of the application. Can we do a better job of helping people ascend the learning curve? If so, how? These questions become especially interesting in light of the fact that many systems can easily track where, how, and in what order people perform certain interactions. Are there teachable moments that UX designers can exploit to encourage exploration and help turn novices into experts? Taking this approach would seem to blur the traditional hard line of demarcation between the application itself and its associated user assistance. But maybe it’s time that line should get blurred!
Defining Learning Goals
To encourage exploration and mastery, I suggest that designers more explicitly define their users’ learning goals, so they can address these goals during creation of a product’s workflows or information architecture and when designing features and functionality. And what better place for this information than in your personas or user profiles? (What? You’re not creating personas before doing design? For shame…)
For example, imagine, if you will, that you’ve been asked to create a persona for a statistical analysis application that your company produces. Let’s call the system Statistiphilia and our persona Harriet:
Harriet the Statistical Analyst
Background: Harriet has just finished her Masters in Psychology, with an emphasis on statistical methods and experimental design. She is looking forward to taking a position as a researcher at the State of Texas Department of Behavioral Sciences Research, where she will be evaluating program efficacy across time for various state-funded and state-run programs that provide low-income teenagers and young adults with job market preparation and life skills.
She has solid knowledge of many basic and a number of intermediate statistical analysis methods as well as research design. For her thesis, she designed a study that evaluated the efficacy of a job-training program that is run by a local charity, using a combination of survey data and objective measures of participants’ performance on various tests and evaluations.
Overall Learning Goals: Harriet is motivated to learn more sophisticated analysis techniques, because her job entails performing meta-analyses across multiple programs and program types, as well as using longitudinal evaluation methods with which she is not presently familiar.
System Experience Learning Goals: Harriet is familiar with other statistical analysis applications, having used both SPSS and SAS extensively during her graduate program. She has never used Statistiphilia before. However, she must use it in her current job, because that’s what her department has purchased for all ten of their statistical analysts. Her goal is to learn how to use Statistiphilia to perform each and every statistical analysis method she knows from SPSS and SAS, as well as new methods she knows she’ll need to learn to do her job.
She would also like to learn how to do a better job of managing large data sets, as well as efficiently publishing her analyses to the department’s intranet site, without exporting them to a Web authoring application.
Helping Users Learn
Once we’ve defined users’ learning goals, what then? Can we design user assistance that harnesses users’ intrinsic motivations and better supports users’ knowledge acquisition without making it more intrusive and annoying? It’s here that we run up against a conflict: When people make use of a product, their main goal is almost always to complete a task, not learn more about the product itself. And when they are of a mind to learn about the product, they often aren’t using it, or don’t even have access to it.
But maybe there are ways of activating intrinsic motivation from within a system. First, let’s think about what kinds of learning goals people have for digital products. They typically have one of these goals:
They want to learn how to automate a task or accomplish something they’ve never done before.
They want to learn how to do something they’re already doing in some other way, and do it either more efficiently, in a more expert manner, or with more fine-grained control.
Now let’s think about how people behave when they’re intrinsically motivated to learn more about how something works. What do they do? They do things like
asking other people
searching reference content
searching the Web
browsing forums and other archival sources of information
Knowing this, can UX designers do anything to leverage these types of behaviors? I recommend the following ways of helping users learn:
Provide contextual user assistance. Within a system, provide the means for people to explore ways to do new things or to do better things that they’re already accomplishing in some way. Consider devoting a portion of each screen or module of an application to providing people with user assistance that has the aim of increasing their acquisition of system knowledge. Update this information frequently and dynamically. This kind of knowledge-acquisition content is distinct from classic procedural Help, which as Mike Hughes has pointed out in his UXmatters column is usually not very helpful anyway.
Record users’ interactions to discover teachable moments. Encourage your interaction and information designers to discover what people need in order to learn—by, among other techniques, measuring what people do in an application and profiling their usage patterns. This will provide you with some insight into where people spend their time and what—as well as where—the teachable moments might be. This could be as simple as building an RSS feed reader directly into your application.
Crowd-source content. If your company can’t afford to have a content development team create and manage all the necessary content, an alternative is to crowd-source your knowledge-acquisition content. Let people in the user community create content, so you can amass a repository of expertise-acquisition content for your application. Then let users share such information with other users by publishing it online. (You’ll probably want to authenticate users and do some level of content vetting.) Finally, other users can tag the information, rate it, share it with others, and so on. Of course, you should provide people with useful means of managing all this content. In this way, information regarding what people are learning about and what content is useful to them makes it into the application itself.
In Summary
Are these recommendations different from those you might have seen elsewhere? Not really. I’m suggesting that, among other techniques, application providers leverage community building and crowd-sourcing to provide a means for people to become more proficient users. The real difference lies in the degree to which I advocate for explicitly focusing on learning.
Sounds like the 80/20 rule at play. Once the users have enough to fufill their needs, any additional refinements are not so worthwhile it seems.
What we do know is that clippy doesn’t work. Machines pretending to understand frustrates users.
And I think Paul is right. There is a huge social network in learning that gets ignored. Perhaps we could build chats and forums into an application. Let people ask other users who are in the midst of the application for tips or help or be inspired by the kinds of documents and so on others are making. “Wow! How did you do that?”
I suspect there is also a natural tendency for interaction designers to lean on the built up knowledge, often arbitrary, of users. That is, because Pam has seen the New Document icon in Microsoft Word, other applications utilize that same icon in the correct hope that people will recognize it. One drawback of this is that the interaction designer doesn’t focus so much on building up visual/ gestural concepts that the user can leverage to new situations.
Because Pam learns New Thing as a blank sheet of paper, there is less way to apply that to New Contact for example. Instead, we could use some animation, showing a flow of new items from the space and let the user learn something that could be applied to many more situations.
Mike, I have run across only a few communities that I considered strong, but it’s probably a function of the applications I use. I’m sure there are more out there. I think Intuit does a good job with their Quicken forums, I’ve seen a big improvement over the past five years.
Keith: I like the way you put it: “Machines pretending to understand frustrates users.” I’m not 100% following you on your last example though. Could you elaborate on that if you have time and the inclination?
Paul
I think it’s a little unfair to compare riding a bike and wheelies—which is essentially a play activity, or hobby if you’re an adult—with MS Word and mail merge. You should compare two work domains—one of which doesn’t involve IT. I would be surprised if you found a good comparison—a domain that gives as little training for the tools of the trade, yet which expects some level of proficiency in the use of a large number of tools. If you did, I suspect you would not find much difference in usage proficiency patterns.— Marcin.
Paul—It also depends on the time spent on an application. I have been making presentations for a long time now, but because it’s only once a month or something, I never felt the need to get deeper into the usage part. Whereas, since I am a heavy user of Word, I am definitely not satisfied with the novice user status and without any extrinsic motivation, just to make my life easier, I question, explore, remember the 80% of functionality that novices don’t care about.
In my opinion, each user, subconsciously, weighs the time to be spent in learning anything against the returns he or she will get out of it.
I once listened to a research paper—and I wish someone would track down a reference for me—that discussed a two-stage learning curve for software applications. The productivity-against-time curve had the traditional steep section as people started off, and then leveled out. But the researcher noted that, given time, users would move from that plateau, through a second steep learning curve, and on to a higher plateau. That reflects Paul’s desire to move people through one learning curve, from beginner to novice, and through another learning curve, on to Expert.
The problem this researcher was studying was the negative effect of software version changes on productivity. He found that it was very rare for users to climb the second curve and postulated that this was because, before they got to that point, a new version would be forced on them. He claimed that it is typically only when a user becomes very comfortable with a product that they might attempt the second climb. But if the software was upgraded to a new version, their comfort zone was destroyed, and their productivity dropped while they re-climbed the first part of the curve for the new version.
I don’t know if that’s clear without the diagram and some hand-waving, but the point is that most users will not become experts if the software they are using changes too rapidly.
Contextual Help is very useful, and users are usually quick to determine whether it’s really related to their primary task at hand.
Do you think technology has historical baggage that results in users not wanting to try new things due to past bad experiences? Or fear of breaking something? Or is this starting to change with the Gen Y?
Hi Paul. Great article. I personally have to set it as an explicit goal to learn more keyboard shortcuts for the software I use all day everyday.
I think computer and console games do a great job of teaching players how to use the controls and understand system concepts. Many games have some kind of initial tutorial that teaches players the basics of using their weapon, jumping, and so on. This kind of Help seldom gets in the way of enjoying the game, brings players up to speed quickly, and a lot of times is fun. Many games also use load screens to show tips.
I think we have a lot to learn from game designers.
Isn’t this the famous “paradox of the active user” that John Carroll wrote about? There’s quite a body of research—“stable suboptimal performance” is another phrase that I really like. And “the efficient usage of computer software does not automatically follow from either good design or experience of its users” (Bhavnani & John, 1997).
I think this is true—at least for complex software activities. Good design makes tasks simpler, but some tasks just aren’t simple.
Just back from hearing Paul deliver a presentation on this very topic—in Edinburgh. (Hi Paul, I was the guy with the MacBook.)
This idea fits into many areas of my work—technical writer / information architect / content manager—and I’m still getting my head around some of the finer points.
I’ll be posting my thoughts on my blog tomorrow, but thanks again!
Assistant Professor and Coordinator for the Masters of Science in User Experience Design Program at Kent State University
Cleveland, Ohio, USA
ShermanUX provides a range of services, including research, design, evaluation, UX strategy, training, and rapid contextual innovation. Paul has worked in the field of usability and user-centered design for the past 13 years. He was most recently Senior Director of User-Centered Design at Sage Software in Atlanta, Georgia, where he led efforts to redesign the user interface and improve the overall customer experience of Peachtree Accounting and several other business management applications. While at Sage, Paul designed and implemented a customer-centric contextual innovation program that sought to identify new product and service opportunities by observing small businesses in the wild. Paul also led his team’s effort to modernize and bring consistency to Sage North America product user interfaces on both the desktop and the Web. In the 1990s, Paul was a Member of Technical Staff at Lucent Technologies in New Jersey, where he led the development of cross-product user interface standards for telecommunications management applications. As a consultant, Paul has conducted usability testing and user interface design for banking, accounting, and tax preparation applications, Web applications for financial planning and portfolio management, and ecommerce Web sites. In 1997, Paul received his PhD from the University of Texas at Austin. His research focused on how pilots’ use of computers and automated systems on the flight deck affects their individual and team performance. Paul is Past President of the Usability Professionals’ Association, was the founding President of the UPA Dallas/Fort Worth chapter, and currently serves on the UPA Board of Directors and Executive Committee. Paul was Editor and contributed several chapters for the book Usability Success Stories: How Organizations Improve by Making Easier-to-Use Software and Web Sites, which Gower published in October 2006. He has presented at conferences in North America, Asia, Europe, and South America. Read More
