Features

A Technical Communication User's Hierarchy of Needs

By Ellis Pratt

At the Technical Communication UK 2015 conference, one of the presenters, Rachel Johnston, mentioned the idea of creating a content maturity model. I thought I'd take this idea further to see if I could develop a model that illustrates a hierarchy of needs for users of technical communication.

I used the phrase “a technical communication user's hierarchy of needs,” because I wanted to create something that considered technical communication from a user's perspective. I wanted organizations to consider the different points where a user interacts with technical communication content, the information they need, and the value this content gives them.

The purpose of the model was to help organizations at the initial planning stage of a project and to assist technical communicators with making the case for a sufficiently large budget.

A Hierarchy of Needs

The idea of a hierarchy of needs assumes what's provided must meet the basic user needs before it can satisfy higher-level needs, if it is to be successful. For example, organizations must enable users to complete tasks before they consider whether the content is aesthetically pleasing.

Figure 1. A technical communication user’s hierarchy pyramid
Figure 1. A technical communication user’s hierarchy pyramid

The categories in our model's hierarchy roughly correspond to Peter Morville's “User Experience Honeycomb,” as well as the common factors in product design. At the bottom, we have the bare minimum, or what's required to avoid litigation. As we move up the pyramid, we increase the utility, usefulness, and aesthetics. Toward the top, we have an information system that is intuitive to use, enables users to be in a peak state called flow, and contributes to the brand image and evangelism of the product.

Mapping the Hierarchy to Technical Communication Products

I can connect this hierarchy to the different types of content you see in technical communication. For example, if an organization wants its technical communication to enable the product to be intuitive to users, the model's hierarchy can help them realize that providing a basic PDF manual probably won't be enough.

In the diagram in Table 1, the hierarchy is placed in the left column. To the right of that are the types of technical communication outputs that correspond to those levels of capabilities.

Table 1. A technical communication user's hierarchy map
Table 1. A technical communication user's hierarchy map

This table can act like a wine list. You can select only the outputs listed toward the bottom if you wanted something analogous to fermented grape juice. Equally, if you wanted the technical communication equivalent to the finest wines available to humanity, you could provide all the outputs up to the top to the hierarchy.

Integrating the Model with Other Models

I arranged the model in this way so that I could also use it to integrate with similar models from content marketing, information development, and product design.

One popular model used in content marketing is the customer engagement model. This defines the depth of the relationship a customer has with a brand. The model typically describes four stages called attract, convert, sustain, and advocate.

If I integrate our hierarchy of needs with the four stages of the customer engagement model, I can create a diagram that looks roughly like this:

Table 2. A customer engagement model
Table 2. A customer engagement model

The purpose of doing this is so you can use the diagram to show what technical communication deliverables will be needed at each stage of customer engagement. Where there are ticks in the table, you could replace these with a list of the outputs that will need to be provided. Again, this could help with making the business case for technical communication. For example, you could say something to the effect of, “What we're providing today is good enough to attract customers, but, if we want to sustain the use of our product, we'll need to provide these other outputs.”

Another model that could be integrated is the technology adoption curve. This model describes the adoption of products by defined groups. The first group of people to use a new product is called “innovators,” followed by “early adopters.” Then come the early and late majority, with the last group to eventually adopt a product called “laggards.”

Innovators may be willing to accept a product that's rough around the edges, with minimal documentation, in exchange for early access to the product. Other users will want and expect more.

Table 3. A technology adoption curve
Table 3. A technology adoption curve

Potentially, the model also could be mapped to personas, in order to identify which technical communication deliverables an organization will be needed for each persona type.

This model could be integrated with models already in used in technical communication, such as the information process maturity model (developed by Dr. JoAnn Hackos) and Hargis et al.'s 1998 quality checklist system. However, my goal is to focus on the value to the user and the organization, rather than the processes by which I get there. This is a model that ideally will be used at the beginning, in the budgeting and planning stages, rather than at the end.

Using the Model

I've made the model and the images above available under a Creative Commons Attribution license. You can download them from my blog at www.cherryleaf.com/blog/2015/10/a-technical-communication-users-hierarchy-of-needs. So far, the response to this model from technical communicators has been positive. Its purpose is to help technical communicators provide a plan that links directly to the goals of content marketers, product designers, and others within the organization. It's likely this model will need refining and developing, so I welcome any comments, suggestions, disagreements, or any other feedback.

ELLIS PRATT (ellis@cherryleaf.com) is director and help strategist at Cherryleaf, a technical writing services and training company based near London, in the United Kingdom. He has over 20 years' experience working in the field of documentation, has a BA in business studies, and is an associate of the Institution of Engineering and Technology.