Joe Pairman, HTC Corporation

Mark Baker is right—everyone in technical communication should read Weinberger. Too Big to Know reminds us of the incredible richness of the Internet and shows how the networked contributions of many experts combine to create a new kind of knowledge. This trend has two implications for technical communication. One is that we should make use of networked knowledge to improve our own processes and practices in everything from cross-team collaboration to tools usage. The other implication is that when we create content, we should do so knowing that our contributions are not a final stopping point but just part of a much larger conversation.

Baker’s focus is on the latter of these two implications. In reminding us that we are part of a conversation, he is trying to shake up a sometimes insular and self-protecting field. When technical communicators ask how to get more respect for the profession, Baker replies with another question: In a world where information is freely available from many sources, how can you add most value to your organization? While in fact many groups are further towards answering this question than Baker imagines, any group that does not have a convincing answer should start to work on one now.

As well as asking questions, Baker suggests some answers. One answer is that minimalist information design no longer adds value. There are three main threads to this argument. One is that such information design is associated with frozen, inflexible documentation that is written once and is never updated to reflect users’ increasing knowledge or changes in the product. Another thread is that minimalist documentation suppresses the “why”: that it is all about tasks, with no background information. The final thread is that the web already performs all the functions that minimalism recommends (see blog post The Web Does Minimalism). However, these threads of argument are based on misconceptions. In fact, minimalism done right is more valuable than ever in a networked world. It certainly does not contradict Weinberger’s view of a vast and rich (yet lumpy) porridge of knowledge. And it is a very good fit for the guiding principle of Baker’s new doctrine, to focus on “those parts of the

life cycle where injecting information into the marketplace makes the most difference to sales and to margins” (see article It’s Time for a New Doctrine of Technical Communications). Let’s look at the three misconceptions in more detail.

Minimalist Information Design Results in a Frozen Documentation Set that Does Not Address Users’ Needs or Prior Knowledge

Minimalism starts with a focus on users’ real goals. In contrast to the older style of documentation that attempted to give a thorough description of each and every part or UI element, minimalism strategically focuses on the information that makes the most difference to users’ experience with the product. Of course, there are tasks that users are perfectly capable of doing anyway without needing their hands held. Minimalist documentation omits these tasks. Moreover, it aims to actively exploit users’ prior knowledge.

To be sure, a product may be used in many different ways, for example by users with different roles. It may well make sense to target certain information at certain users (for example with navigation or filtering enabled by appropriate metadata). But the principle is the same: rather than trying to write everything for every conceivable need, we should listen to our users, look at the whole picture of information availability and usage, and prioritize the information that is most needed and most effective.

The question is then whether, having gone to some effort to design minimalist documentation, we are then stuck with using that same documentation for a long time. (This kind of frozen book format is actually what Weinberger means by “topic”—a fixed area of authoritative coverage that acts as a stopping point, beyond which questions are somewhat discouraged.) The answer is no. Once the initial analysis and design is complete, it becomes far easier to update content as needed to address changing user goals or new product features. Because we have not committed ourselves to documenting every nook and cranny of a product, updates are still focused on the subset of procedures that address real user needs.

Minimalism Suppresses the “Why”

Baker writes that “technical communication suppresses the why to focus on minimalist instruction.” Yet “the why” is crucial to minimalism. It is important to provide procedure intros to orient the user: to confirm that she has reached the right page and to indicate how the procedure fits into the larger goals that she may have. It is also important to provide more in-depth supporting conceptual information for those users who need it, though this is often better linked from a procedure rather than embedded in it.

The web certainly contains a lot of non-minimalist technical documentation consisting of pages of procedures, with little information on why one might want to carry out those tasks or on the big picture behind them. These procedures are best described as job aids. Carroll and Van Der Meij write that “Job aids … succinctly present the step-by-step minutiae of procedures, these are de-skilling characteristics, and not at all consistent with minimalism” (emphasis mine).

There is another kind of “why” that Baker may be alluding to—the kind of easy access to primary sources that Weinberger praises. On the internet, when someone presents a scientific fact, it is usually a matter of minutes to find sources that confirm or contradict that fact. Given a few hours, a good set of related data can often be gathered. Yet, in technical product communication, this kind of “why” is rarely relevant. Users prefer information that addresses their goals directly, without detours into an organization’s justifications for implementing a feature in a certain way. And, unlike the scientific data that Weinberger describes, it is not as if comparing the same procedure from ten different sources will result in some kind of statistically significant super-procedure.

So, minimalism does not suppress the relevant “why,” just the information that is not helpful to the user.

The Web Does Minimalism

There is a large amount of product information available on the web. Google does a very good job of matching search queries to relevant content. And where search doesn’t turn up anything useful, many people ask and find answers on forums and other social media channels. Baker feels that with careful searching and questioning, the web itself yields the kind of information that one would get from a minimalist documentation set—in fact better than that, because of the sheer amount of content. The implication is that it may no longer be worthwhile for an organization to invest in minimalist information design.

There is certainly a large amount of user-generated instructional content on the web. There is everything from detailed procedures, through personal experiences and tips, to helpful responses on forums and in comment sections. Yet, to borrow a phrase from Weinberger, its nature is sticky and lumpy. Some products have more user-generated content than others. Within that content, far more exists in some languages than others. Users may find some topics more interesting to write about, and these interesting topics often do not tie up with the actual knowledge gaps that exist. In addition, the applicability of any one piece of content may vary widely, from covering all variations of a product, to applying in one specific, time-dependent case only. User-generated content is an amazingly rich resource, but for many products, it is not sufficient in itself. In contrast, good minimalist documentation guides its audience in the key tasks they need to learn.

What happens if user-generated content covers many of the same tasks? It is probably still worth developing minimalist topics for these tasks. Users want to learn quickly and painlessly, and minimalist documentation is designed to enable that. It omits needless verbiage and obvious information, presents tips and error correction where most relevant, and makes meaningful connections to the big picture. Above all, it is designed to empower users, and most users respond very positively to this approach. Such documentation is also often very easy to access. The careful research and design of titles and intros means that it is easy to find needed information, whether via internal search tools or external web search engines. (This, combined with the high search result ranking often given to the “official content” of an organization, means that it can be very effective to put documentation on the web, when possible.) And the impact of good documentation can extend beyond those who read it directly. It often influences the unofficial support exchanged on social media or given from one friend or family member to another.

In contrast, where official documentation is poorly designed or missing, web searches can sometimes require patience and persistence. They work well for very specific queries, such as the example Weinberger gives of an operating system error message. Where a question is more general, multiple searches may be needed and many links may need to be followed before the right information, at the right level, is found. The users of some products, such as open source operating systems, may enjoy the hunt for information. Other users are not so happy to be forced to work hard for answers, and customer loyalty can suffer as a result.

So the web does not necessarily “do” minimalism, but minimalism does very well on the web. And it fits in very well with Weinberger’s vision—a room where there is space for everyone; where “the richness of the overall web of content and links enables a healthy mix of types of content-based networked expertise.” And make no mistake—technical communicators can indeed be experts—not in the sense of Solomonic scepter-holders, but in a very practical sense of being in an ideal position to research, design, and deliver very effective information at the right time.