Technology Acceptance Process: A Release Model for User Assistance

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.