My book (Every Page is Page One: Topic-based Writing for Technical Communications and the Web) is currently in the final stages of revision, and I have been very fortunate to have some of the leading lights in tech comm agree to provide feedback on my drafts. I have received some really valuable responses, but I have also noted something very interesting. So far, no two people have said the same thing about the same passage, not even once.
When you consider that these are some of the smartest and best informed people in the fields of technical communication and content strategy – all in the same field, all familiar with each other, all reading the same books, attending the same conferences, and following the same people on Twitter – that is pretty remarkable. If any group should have similar reactions to a new text in their field, it should be them.
But they don’t.
There have been a couple of places where two people have commented on the same passage, but they have said very different things about it. In one case, one person said they really like a particular analogy I used, while another found it tiresome and wanted an example instead. Several people asked for more examples, but no two asked for an example of the same thing in the same place.
Everybody agreed that the book dragged in parts, but no two people said it dragged in the same parts. Where one said “cut,” another said “expand.” Some seemed to have the hardest time following the argument of a particular section while everyone else sailed through it with no signs of trouble.
You can’t please everyone.
But you can half kill yourself trying. I have reorganized the book completely at least twice. I have written whole passages in response to one reader only to tear them out again in response to another. At a certain point, though, I have to face up to the fact that I can’t possibly read every book that every reader refers me to, I can’t explore every subject in as much detail as the folks who specialize in that subject would have me do (my publisher wants me to cut, not expand!), I can’t make every caveat, defend every assertion, or answer every possible objection. A book that did all that would be unbelievably tedious to the general tech comm and content strategy readership it is intended for.
Is the book better for all this widely varying feedback? Certainly. I am enormously indebted to all my reviewers. Is it the exact book that any one of them would have wished me to write? I very much doubt it.
Audience diversity is the fundamental challenge
In communications of all kinds, the biggest single challenge is the diversity of the audience. Tech support folks speak to individual users. Their challenge is to figure out who the one person is on the other end of the line. Sales people and sales engineers talk to individuals or very small groups, and they spend a lot of time studying them to figure out exactly who is in the room. They communicate with individuals. And however quirky those individuals may be, they can learn and address their quirks individually.
In tech comm and marketing, on the other hand, we address a mass audience. When we know little about that audience, it is easy to imagine them as a kind of average or typical user, as the embodiment of a persona. When we do get to hear from a significant cross section of them in detail, we realize that the truth is very different. The quirks do not average out in an aggregate user with main line interests, intelligence, needs, or background. Rather, that audience is the sum of all quirks. What one reader craves, another detests. What one reader understands, baffles another. The key detail that is vital to one is irrelevant and distracting to another.
John Carroll found that learners have a hard time following procedures because their existing knowledge and experience is more real to them than what the procedure was describing. That would not be so bad if every reader had the same existing knowledge and experience. Then we could tailor our documentation to that exact profile. But of course they don’t. This is why minimalism does not say; address every quirk and question any user may have. It says; leave room for exploration and discovery. Because every user has to cross that bridge for themselves. And when we try to talk them over it, we hinder more than we help.
A bus, not a taxi
Because the audience is so diverse, you cannot write for them as if they were a single person. A document is a bus, not a taxi. A taxi serves a single passenger well by picking them up at the exact spot they are standing and taking them to the exact spot they want to go. That is the service a tech support person tries to provide for the people that call a support line. But taxis are expensive, and companies do all they can to divert people away from the taxi service and onto the busses. They publish knowledge bases and documentation. When you call the support number, the first voice you hear will be a recording suggesting you go to the support site and look for your answer there.
The role of the documentation group, therefore, is not to provide that perfect taxi service for each individual reader, but to provide an effective, but less expensive, bus service. A good document serves many readers who are going in generally the same direction. It allows them to get on and off at regular intervals, and it serves hubs where the reader can transfer to another document to complete their journey.
The problem with a bus service, of course, is that sometimes a user has to walk, especially at the beginning and end of their journey. This, in minimalism’s terms, is the allowance for exploration and discovery. This can seem like failure to the writer, and if the writer were running a taxi service, if they were writing a specific document for each reader based on an intimate knowledge of the particular reader and their particular task, it might be. Then again, Carroll would probably suggest that even in this circumstance, the learner has to participate in the learning to really cement new knowledge, and that errors may actually be essential to learning. A little walking is good for the heart, and maybe for the head as well.
We cannot write a personal manual for every reader. We write one document to be shared by every reader, in all their variety and quirks.
The road paved with good intentions
But, of course, we don’t hear from the aggregate of readers. We hear from individual readers, from individual developers, product managers, sales people, support people, and field engineering people, many of them quoting what some customer told them. And the path of least resistance is to add everything they ask for into the documentation.
Actually, it is not just the path of least resistance; it is the path of no resistance. It is a path that feels like the path of virtue, the path of serving the customer’s every need.
But it is not the path of virtue. It is the road paved with good intentions, and we know where that leads. It is a path that leads to documents so stuffed with every possible kind of detail on every possible angle of the subject that no actual reader can make head nor tail of it.
We have all probably inherited such a document at some point in our careers, and pulled our hair out trying to figure out where all this detail came from and what part of it actually matters or should be retained. Yet chances are that when we have hacked through the thickets and got the document down to the essential core of information it contains, we then sent it for review and immediately begun the process again of well-meaningly fitting in all the suggestions we get from everyone who sees the book.
Everyone wants to have the bus pick up nearer to their front door, or to have direct service between their house and their destination so they don’t have to change busses. However, accede to all these requests, and you will have created a bus route that picks everyone up at their own door and drops them directly in front of their office, but takes so long to get them there that it is time to come home again.
As user advocates, then, writers must learn to advocate not for individuals, but for the community of users as a whole. This does not mean ignoring the feedback from individual users, which is usually the only feedback we get. But it does mean taking that feedback, along with any customer studies or usability tests that we get to do, and any use metrics that we can collect, and considering it as a whole, looking for overall trends and patterns, and responding to the patterns, not the individual requests.
Just as a bus company must continue to monitor ridership patterns and journey times to ensure the system is serving the community well, documentation groups must monitor usage and usability of the documentation they produce to ensure they are meeting the needs of the community as a whole.
And just as the bus company must sometimes say no to the requests of individual riders, the documentation group must sometimes say no to the requests of individual readers.
