Much of the time we spend with technical documentation is concerned with wayfinding. That is, it is not about performing the actual operation, but about finding which operation to perform, and finding the piece of content that describes the operation in a form that we can understand.
Note that there are two distinct components to this description of wayfinding. It is tempting to think of wayfinding purely in terms of finding the right piece of content. But simple content wayfinding really applies only in cases where the user it thumbing through a well known and well used reference work. That is, in cases where we know exactly what we are looking for, and merely have to locate an individual data point.
At all other times, the principal wayfinding that the reader is doing is finding their way through the subject matter from the starting point of the business problem they are trying to solve to the actual technical implementation of the most appropriate solution.
That journey may involve several pieces of content, and several wayfinding steps. In these cases, the reader will go back and forth between subject wayfinding and content wayfinding several times on this journey — each new content wayfinding step being required to complete the next subject wayfinding step.
![Much of tech comm is about wayfinding. By Karora (Own work) [Public domain], via Wikimedia Commons](https://i2.wp.com/everypageispageone.com/wp-content/uploads/2014/05/Bluff_Signpost.jpg)
Much of tech comm is about wayfinding. By Karora (Own work) [Public domain], via Wikimedia Commons
Their path will be further complicated by their own preconceptions. Most of us don’t start our information search from a pure problem statement. Rather, we start from an often half-baked idea of a solution. The reader’s journey that results is often from a half-baked idea of a solution to an incompletely conceptualized problem, through a process of problem refinement, solution reformulation, and eventually content location.
All of this is wayfinding.
And yet, we often design our content as if wayfinding was an entirely separate problem existing outside of the content. Thus we regard finding the right content as a problem entirely to be solved using tables of contents, indexes, taxonomies, and search engines. We design and write the content as if it could be assumed that the reader is reading the right content — the content they really need — and that if they are not, the fault lies elsewhere, with the reader themselves or with the set of finding aids that exist outside the content.
This idea leads us to other problems. For instance, it leads us to test content and navigation separately. In particularly, it often leads us to test content based solely on the reader’s comprehension of the individual piece based on testing how well the reader comprehends the text as a text.
I have pointed out before that comprehension of the text is not the point of technical communication. Correct action is the point, and correct action can often be achieved without full comprehension of the text. The text often contains information not necessary for action, and the affordances of the product itself often supply much of what the reader needs). Conversely, correct action is not always attained even with full comprehension of the text as a text. (This is extremely common in recent graduates, who can pass tests on content, but cannot perform in the real world.)
But this approach to testing content also ignores the role it plays in wayfinding. If a reader looks at more than one piece of content in their journey, all the content they look at prior the the final piece is likely playing a wayfinding role. Even the last piece may be playing a wayfinding role, if the affordances of the product provide the actual technical know how required — which is often the case. The true test of the content, therefore, is not how it performs as a stand-alone object of comprehension, but how it performs as an effective wayfinding tool for both kinds of wayfinding: subject wayfinding and content wayfinding.
In the ongoing debate about how much linking to provide in content, the arguments for eliminating or limiting links often ignore the wayfinding function of content. Often they are based on stand-alone comprehension tests, which test comprehension of the text or time to read the text, and find small increases in comprehension and reading speed when links are removed. (It is hardly surprising that isolating content from the rest of the world helps when you test how it performs in isolation.)
These would be reasonable arguments against linking if the goal of technical communication were to ensure that readers could read individual texts at maximum speed and then correctly answer questions about the texts. But simple comprehension of texts is a goal we set for school children. It is not the goal of working adults.
The goal for a working adult is to find their way to a correct understanding of their business problem and the correct execution of an optimal solution to it. This almost always involves wayfinding through a body of content and the subject matter it describes.If links assist that wayfinding, they do far more to reduce the time of the overall task than any slight slow down they may produce in reading individual texts.
But it is hardly enough to throw in a bunch of links and hope good wayfinding results. To provide for great wayfinding, you need a systematic approach to linking that is optimized for wayfinding. I noted at the beginning that there are two kinds of wayfinding going on in a tech comm journey: subject wayfinding and content wayfinding. Content wayfinding is the servant of subject wayfinding. No reader is looking for a piece of content for its own sake (that is a purely academic pursuit), they are looking for content that describes a subject on their current subject wayfinding path. Links should follow the lines of subject affinity between pieces of content so that readers can navigate to the content on the subject they need to understand at any given point in their journey.
This requires a highly systematic approach to linking that ensures that the important subject affinities are linked consistently and in the right way. This should ideally be driven by metadata, and by subject taxonomies, where taxonomies are available and maintained.
But you need much more that just linking. The content as a whole should be designed for wayfinding. To being with, links cannot follow the lines of subject affinity between topics if related topics are not appropriately referred to in individual topics, which is often the case when content is designed and written to be read and navigated hierarchically or linearly.
This gets to the heart of what Every Page is Page One is about. Some people misinterpret Every Page is Page One as meaning that the reader is only ever supposed to read one page. Though that might be ideal, in an almost perfect world, that is not what EPPO means. Rather EPPO means that every reader’s wayfinding is different, so that it is not possible for the author to create one perfect sequence that works for every reader. Readers may look at several pieces of content as they find their way through a subject. But because we cannot know where they will start or what order the will read in, we have to write every page as if it were page one. (In a truly perfect world, people would not need any content at all. In the real world, they need to find their way through a lot of it.)
Supporting the merely mechanical actions of machine manipulation for a reader whose wayfinding has been successfully completed is a relatively straightforward task . (There are definitely good ways to do it, and bad ways, but the problem is not terribly complex or beset by many uncertainties.) The hard part of effective tech comm is the wayfinding. All of the seven principles of Every Page is Page One are designed to improve wayfinding.
- Being self contained helps the reader by making sure that the information they need on a single topic is kept together. This avoids trivial and time wasting navigation to follow the thread of a single subject.
- Having a specific and limited purpose makes sure that the reader’s wayfinding is not interrupted by trivialities and unnecessary and inappropriate diversions.
- Conforming to a type helps make wayfinding easier by presenting information in a consistent and navigable format, and by ensuring the information is complete and presented in a usable form.
- Establishing context helps the reader know exactly where they are as they try to navigate the content set, and ensures that the principal subject affinities of the topic are clearly presented so that the reader can follow them if they wish.
- Staying on one level allows the reader to choose when they want to study the high-level view or delve down into the weeds.
- Assuming the reader is qualified helps the qualified reader to find what they are looking for without having to wade through material they don’t need.
- Linking richly allows the unqualified reader to get to content more suitable to their needs, and the wayfinding reader to move through the content as their pursuit of the understanding of their subject moves them.
Readers spend more time wayfinding than executing end procedures. We need to design content to support wayfinding. Every Page is Page One is and excellent approach to creating content that supports robust wayfinding.
Mark, excellent post. Two comments:
1) Subject Wayfinding is also decision support – we need to know what to do, what it does for us, and then comes the content wayfinding – how to do it.
If we do our jobs well, the user will not have to go back and forth too many times (i.e. not more than once).
2) The more expert our users are, the better they are able to understand what the business problem is, find the right Subject path, leading them directly to the right Content. Expertise will not come, as you point out, from reading tomes and answering test questions on it. It will come from good wayfinding, with proper decision support, that builds cognitive demand in intelligent ways, so that the user is lead easily from simply meeting a contingent (and probably urgent) need, to being able to generalise from one topic to the next. An expert user is also capable of evaluating and commenting, not only on the message (content) itself, but how it’s delivered (includes wayfinding). And the feedback these users give us is precious.
I might actually write a blog post on this…
Thanks for the comment, Ray.
1. Agreed, subject wayfinding is decision support. I have long felt that tech comm spends far too much time on button pushing — which people can largely figure out for themselves most of the time — and not nearly enough on decision support — which people often cannot figure out, or at least find an optimal solution for, without significant help.
2. Yes, the more expert the user the less the cognitive gap and therefore the less subject wayfinding, and the greater reliance on content wayfinding. This can raise interesting problems, though, since for the experienced user content wayfinding is often based more on memory and habit rather than logic. As we learn our way around a city we cease to look at road signs. We just follow the familiar path and landmarks. And for a remembered path, eccentricity may actually be more desirable than logic, because it creates more distinct landmarks.
This can create difficulties, both when you want to reorganize content for better overall wayfinding, and when you want to figure out what better wayfinding would look like. Experienced users are likely to be frustrated by any reorganization because it invalidates their remembered routes, and the feedback of those uses will be prejudiced by their attachment to the organization on which their memory is based.
A big difference that Google is making, though, is that is leading us away from relying on memory to locate content. More an more we make no attempt to remember where something is, but rely on search to surface it again the next time we need it. Which is why I think we should be focusing more and more on bottom-up information architectures and content that works well when found.
Excellent post. I think the importance of this thinking for software writers will grow as overall computer literacy grows — HOW to do diminishes in importance next to WHAT to do.
I’m interested in your discussion about affinity. I think that’s the next step for content processing. We need to express affinity between content units (full page-one or not). But we need to do more than that. We need to express affinity according to context. In the same information domain, my context might differ from yours. So the affinities between topics would rate differently as well. I look forward to more on this subject…
Thanks for the comment, cud.
I agree, we do need to express affinity according to context. This, of course, is not something that can be done at time of writing, where the context is not known, or not fully known. It has to be done are near as possible to the time of reading, when the context is better known.
What we can do in our content today to enable that future is to capture the affinities of our content explicitly. We have to get away from expressing publishing and content management semantics in our content, and move towards expressing subject semantics much more fully. That will provide the data we will need to express affinity according to context once we have access to the context data.
Mark and Cud, actually, software exists today to determine affinity – it just isn’t being used in our discipline – but that’s exactly what Amazon, Google Ad Words, etc. do – even the famous “search bubble” that Google calculates to make your search results different from mine with the same search term entered.
I wonder if anyone is working on an application of Amazon’s platform, for example, to DITA topics or other similar structures.
Yes, absolutely. I describe the Web as creating dynamic semantic clusters — drawing together content from may places based on its affinity to a particular search term or the use of a specific twitter hash tag. The Web is all about the ability of software to discover affinities.
I do think we should be taking more advantage of this in our profession. But I also think there is a role for the deliberate identification and management of affinities, for several reasons. For one thing, our current software approach to the detection of affinities is based on statistical analysis, not cognition. It works best where there are large volumes of content and large number of use of that content on which to run the analysis. But these approaches do not work well on small bodies of content, and where there are fewer records of use to examine. It does not do well in discerning and resolving local ambiguities. Within specific domains, these engines need to be deliberately tuned to return the desired set of results — a capability one finds, for instance, in enterprise search products.
For another, managing it ourselves allows us to fine tune it to our specific purposes. We have little or no control over how the users searches, but we have control over the links we provide, and that is worth something to us — potentially a great deal if we are sophisticated about it.
I do think we could do much more than we do now to automate or partially automate tagging. In fact, I think in general that we should be looking at how we can combine explicit semantic annotation with algorithmic semantic discovery to achieve the optimum results. Alas, much of the tech comm community, and their tool builders, continue to ignore both.
Interesting thoughts, broaching the general subject of human cognition and how we can support this as technical writers. This reminds me of how I worked myself through Word’s form letter function way back in college. I only knew I wanted all recipients who’s addresses I had collected in an excel sheet to receive a letter. Without knowledge of the proper search terms it was difficult to get useful information out of the online help. I gave up searching the help and searched the internet instead, which provided a ton of perfect explanations how to proceed.
Little has changed since then.
Isn’t that ridiculuos – internet tutorials written by other users (lacking both perfect grammar and professional skills) are often more helpful than software documentation created by alleged experts. Why? Because they are task-oriented and share the perspective of the end user.
Thanks for the comment, Robert.
Yes, it is interesting that the content written by other users is often more helpful than that written by professional writers. But I think this is simply a reflection of the fact that saying the right thing — using the right terms — is of far greater importance to the reader than saying it with the right style.
There are all sorts of impediments that make it harder for technical writers to say the right thing in the right terms. One of the most basic is that the right thing and the right terms are not the same for all readers. But there are also impediments in our processes and even in our hiring practices that work against it as well.
Ironically, with the great push now on in tech comm for the establishment of uniform taxonomies across companies, and even across industries, the problem of using the right terms may become even more difficult. Formal taxonomies tend to insist on using a distinct term for every subject they cover, whereas in real life, a few common terms are reused over and over again to cover a broad array of subjects — ambiguity is resolved by context and usage, not by distinct vocabulary.
This will lead to corporate content that is internally consistent (a good thing in itself) but more foreign to the vocabulary of the average reader and searcher, which will mean more help searches will come up dry and more Web searches will lead to user content rather than to official content.
This is the world we live in now, and to address it, I think corporate tech comm had to give up on two of the fundamental presumptions that have shaped its approach to creating and designing content for many decades:
1. Users will come direct to our documentation when they need help.
2. Users will learn our vocabulary and our conventions in order to use the documentation.
I’m not sure these presumptions were ever valid, but they are certainly not valid today. We need to figure out a way to add real value in a world in which these presumptions are not valid.