A theme I deal with a lot, both at work and in this column, is organizations’ asking user assistance (UA) developers to support more products with fewer resources. For UA developers who are experiencing a resource crunch, the obvious solution is writing less user assistance for a product than we would have produced in the past. (See my UXmatters column “Hockey Sticks and User Assistance: Writing in Times of Resource Constraints.”) But that still leaves the problem of how to write less and cover users’ information needs adequately.
Everett Rogers’s seminal model of the technology adoption process [1], charted in Figure 1, suggests an approach that might let us put the proverbial 10 pounds of content into a 5-pound bag of writer capacity. Rogers noted that the phases of technology adoption correspond to its adoption by distinctly different classes of people, who accept new technologies at different paces.
Champion Advertisement
Continue Reading…
Figure 1—Technology adoption process
New products or new releases of existing products, with their sets of new features, often represent technology advances that users will adopt following a similar distribution. Those out there on Vista raise your hands. Those not on Vista… Okay, you get it.
This model of technology adoption could provide a solution for delivering a large user assistance package with a limited team, if you consider the following observation: Although UA developers feel compelled to deliver user assistance in its entirety at the time of a product’s release, users adopt the product in phases, and those phases correspond to distinctly different information needs.
In this column, I examine the different information needs of Everett’s classes of adopters and discuss their implications for time-phased development and release of user assistance.
Adopter Classes
In the following sections, I’ll describe the five different classes of adopters Rogers defined and how their information needs differ. Rogers’s five different classes of adopters:
innovators
early adopters
early majority
late majority
laggards
Innovators
We can make the following assumptions about innovators:
They’re technically savvy.
They have deep application domain expertise.
They expect the going to be tough—and some argue they even like it that way.
Innovators need to install, configure, and deploy the product on their own, and it is unlikely that the product’s user interface can deliver the information they need. Innovators want technical overview documents and setup documents. We can expect them to read reference materials and transfer what they learn to their own contexts.
Innovators discover bugs and unanticipated product deficiencies, so their support network has to be fast and flexible. A social network that keeps innovators and support personnel communicating with each other—sharing problems and solutions—should take high precedence over traditional, unilateral Help.
Although innovators are willing to read technical documentation, they usually avoid reading Help, so delivering user assistance directly through the user interface (UI) as inline text gives it the best chance of being read by innovators. For UA developers, influencing UI text delivers more value than crafting Help topics that innovators are unlikely to read. Leave those for later.
Early Adopters
Here are some assumptions we can make about early adopters:
They’re technically savvy.
They have deep application domain expertise.
They have stronger expectations for usability and user assistance than innovators do.
They don’t have the same drive “to be first and be bloody to prove it” that innovators seem to enjoy.
Early adopters might need prompting—typically through scenario-focused documentation—to learn how they can incorporate the product into their own technical environment or business processes. They might also be involved in doing product assessments or proofs-of-concept.
Reluctant to take the time to read Help, early adopters can benefit from domain expertise and decision-making support that we can deliver through embedded user assistance—in the form of a Help panel or hover text—and instructional text in the UI—such as field format examples. (See my UXmatters column “User Assistance in the Role of Domain Expert.”)
Early Majority
We can make these assumptions about adopters who belong to the early majority:
They take the middle of the road when it comes to technology—that is, relative to the target user population for a particular product. Thus, if the product is rocket science, these users are still smart—just more likely to be your average rocket scientist.
They have a middling amount of knowledge within the application domain—the same rocket science disclaimer applies here.
They have even stronger expectations for usability.
Users belonging to the early majority might also need more prompting to apply best practices or make informed decisions about product setup and use. Tutorials are useful in helping the early majority understand how to apply the product within their contexts. They need to visualize how the solutions work, so they can transfer them to their own contexts.
By this time in the product cycle, you can document the lessons learned by innovators and early adopters and codify them in knowledge bases that early majority adopters would find useful.
Developing troubleshooting topics supports business goals for this phase, which typically include improving product margins. The more user assistance can do to make users self-sufficient, the better.
Task-level Help topics that follow a use-case pattern—that is, emphasize when and where to use features—and give domain-level insights, can be useful to these users. (See my UXmatters column “Use Cases for User Assistance Writers.”
Late Majority
We can make these assumptions about adopters who belong to the late majority:
They might be missing some technical concepts the product’s use requires.
They might be missing some domain concepts the product’s use requires.
They have high expectations for usability and user assistance.
To help these late majority adopters use the product effectively, user assistance might need to provide Help topics that provide remedial conceptual information—much like the deep concepts I discussed in my UXmatters column “The Anatomy of a Help File: An Iterative Approach.”
Laggards
By the time the laggards start to use the product, the documentation should be robust. There is also a large population of existing users who can help them. So, don’t waste additional resources helping this group.
Overview of Adopters’ UA Needs
In Table 1, I’ve provided a summary of the kinds of user assistance that are most useful to each specific class of adopters. This list assumes a cumulative model of user assistance—that is, each class has access to the documentation already developed for the class that preceded it.
Table 1—User assistance needs of different classes of adopters
Innovators
Early Adopters
Early Majority
Late Majority
Product overviews
Theories of operation
Installation and configuration guides
Social networks
Support contacts
Inline UA text
Scenarios
Help panels
Hover text
Inline instructions and examples
Tutorials
Knowledge-base articles
Troubleshooting guides
Task-level topics
Conceptual topics
Conclusion
Taking a phased approach to developing user assistance offers benefits to both users and resource-constrained UA developers. UA developers can focus on the immediate user assistance needs of whatever class of adopters is most likely adopting the product at its current stage in its product lifecycle. Thus, resource-constrained writing teams can focus on providing essential information and put off writing some topics until their own organizational understanding of a product has matured.
Strategies for a phased release of documentation depend on the way in which an organization releases and distributes a product. Dot-X releases—such as 1.1 or 1.2—can provide opportunities for fleshing out the user assistance for software products. You can update Web-based user assistance as needed or convenient. Certainly, as more and more products migrate to the cloud, user assistance can do the same—where we can more readily update it.
Reference
[1] Rogers, Everett M. Diffusion of Innovations. Glencoe: Free Press, 2003.
In your excellent presentation on this subject at the UA Europe 2009 conference in Cardiff last month, you added a final slide labeled �Single Release � Consumer-level user.� My attention must have wandered for a moment, and I�m afraid I missed the point you were making here. Could you explain?
The model I suggest in this column applies most appropriately to rather technical products that have a multi-release lifecycle. If you have only one chance at releasing user assistance and the audience is a general consumer, you should focus on the following subset of UA features:
In his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement. Read More
