Every document is written for a reader, which means that every writer has a theory of the reader — an idea of who the reader is. In technical communication, the reader is a user (of a product or service). Every technical writer, therefore, has a theory of the user. This theory may be explicit or implicit. It may be written down or it may exist only in the writer’s head. It may be consistent, or it may change from the beginning of the document to the end. But it is always there, and it always matters.
However the theory of the user manifests, it profoundly affects how the document is written. It dictates not only the choice of vocabulary and sentence structure, but the information that is provided. It determines if the writer will describe a concept in detail or merely refer to it as if it were already familiar to the reader. It determines if the writer will instruct the reader to perform some task for themselves or ask someone else to do it.
The theory of the user may be based on intimate knowledge of the user (if, for example, you are writing to a friend or a family member). It may be based on general knowledge of the user (you are writing for colleagues of for people like your colleagues). It may be based on personal experience of doing the task yourself (a programmer writing for programmers). It may be based on a description of the user (such as a persona). It may be based on controlled testing and observation (such as through user studies or usability testing). It may also be based on little no experience or information at all (not uncommon for a tech writer who has no access to their users).
Unfortunately, many technical writers don’t have a lot of hard information on which to base their theory of the user. While most would agree on the values of personas, customer visits, and usability testing, these things are expensive and time consuming and it is hard to find either the time of the budget to support them.
What should you do if you don’t have the information you need to formulate a good theory of the user? Easy: make one up.
Write down your theory of the user
No matter how much or how little information you may have about the user, you should write down a complete theory of the user. If you have all the information you need, great: write it down and consolidate it into a single document or collection and call it your theory of the user.
If you have only partial information, write it down and make up the rest.
If you have no reliable information or experience to draw on, make up the whole thing.
Writing down your theory of the user is important because every bit of content you write is going to be based on this theory of the user — either the one in your head or the one you have written down. But, if the theory is only in your head several common difficulties arise:
- You will be inconsistent in your theory of the user, and thus inconsistent in how you write for them. From hour to hour or day to day, you will be thinking about different types of users, and writing for the user in your head at any given moment.
- If you are rushed or you are finding it difficult to construct a passage or explain a concept, you may conveniently inflate the user’s qualifications in your head, turning them into someone who already understands the concept and does not need it explained.
- If you are struggling to understand some advanced concept, or simply trying to fill time until some needed information becomes available, you may conveniently imagine the user to be more junior or less knowledgeable than they really are in order to fill up billable hours writing tedious explanations of the obvious.
- You may fall into the easy habit of modeling your theory of the user on yourself, leading to an idiosyncratic view based on the particular holes, and even errors, in your own knowledge, leading to an equally idiosyncratic document.
- Your collaborators — other writers, SMEs, editors, testers, product managers, reviewers — may have a different theory of the user in mind. This will result in arguments, inconsistencies, and demands for changes that don’t make a lot of sense based on your theory of the user, but may make perfect sense based on theirs.
So write down your theory of the user and use it to guide everything you write. Even if it is based wholly or partly on guess work, at least it will make you more consistent, and set a consistent base for others who contribute to or review your writing. If you subsequently get more information to improve your theory of the user, you will at least have consistent information set as a starting point for revision. This will allow you to come up with a reasonable plan, and a reasonable schedule, for making any necessary changes to the content based on your new theory of the user.
Share your theory of the user
There is probably a huge amount of knowledge about the user percolating in the heads of different people in your company. No one person necessarily has a complete picture. For instance, support engineers spend all day talking to users, but their view may be skewed because they only talk to people who can’t figure stuff for themselves. Salespeople also spend all day talking to customers. Their view may also be skewed, though, because they talk to people making buying decisions rather than those actually using the product. On the other hand, they often know more about the kinds of problems people are buying your product to solve than anyone else in the company.
Getting access to all the knowledge that people in your company have can make a huge difference to the completeness and correctness of your theory of the user. A great way to get at that knowledge is to write down an explicit and detailed theory (making reasonable guesses where you don’t have the details) and circulate it for review and comment. You are much more likely to get good information from people if you send them a complete theory than if you send them a document with holes to fill in. Asking them to fill in the blanks feels like you are creating work for them and they may not do it. But when they read what they consider to be a major error, they won’t hesitate to correct it.
Send it to everyone who has any kind of contact with, or knowledge of, your users. Also send it to anyone whose work depends on having a correct theory of the user, even if they don’t necessarily have any more concrete user experience or information than you do. UI designers and product developers also base their work on a theory of the user, and even if theirs is based on guesswork just like yours, everyone will be much better off if they are working to the same guess, and if the product, UI, and documentation are all created based on the same theory of the user. The resulting product may not meet the real customer’s needs perfectly, but at least it will be consistent and predictable, and that can make an imperfect product much more bearable.
So send it to everyone. Get executive approval to demand reviews from people in all the departments you send it to. Get an executive mandate to have the theory of the user included in the official project documentation and made a requirement for all projects.
Send it to:
- Writers
- Testers
- Trainers
- Course developers
- Designers
- Developers
- Sales people
- Sales support
- Tech support
- Field engineers
- Product managers
- Marketing
- UX people
- Content strategists
- Information architects
- People who manage all of the above
Collect all of the results. If your get contradictory information from different groups, get them in a room and hash it out. Compile a new theory of the user based on all the feedback and circulate it again. Get it signed off by as many people as you can.
One of the welcome effects of this exercise is that many of the people that you ask to contribute to this document will come to see it as a valuable document. Increasingly, their managers will see the value as well, and will start to make their teams responsible for commenting and contributing. Other teams will start to use the document as well (so be prepared to be made responsible for maintaining it — that’s a good thing). Now you may find yourself in a position to request funding for more user research.
Defend your theory of the user
Once you have your theory of the user document compiled and (hopefully) signed off by a broad spectrum of the company and included in the official project plan, defend it.
No matter how much the plan may be based on fact or on guesswork, once it is compiled, treat it as gospel. Use it to guide how you write you content, and also how you define your content types. Make sure that editors and reviewers review against theory of the user (and explain to them that their feedback is of limited value without an agreed theory of the user as a reference point).
If someone asks you to include content that is not consistent with the theory of the user, explain to them how doing what they ask would violate the theory of the user. If they say the theory is wrong, ask them how it should be changed and (ideally) ask them for the money necessary to validate their claims.
Tie your theory back to evidence where possible
The information on which your theory of the user is based will come from various sources of various degrees of reliability — some based on formal research, some on experience and anecdote, and some based on guess work. So it is important to retain a record of where each piece of information came from. You probably don’t want to record all of this inline where everyone in the organization will have to wade through it, but it should be readily available to anyone who does want to know the evidence for the assertions in the theory. This is a good application for some form of progressive disclosure, allowing the reader of the theory of the user document to click to reveal the evidence for each point if they wish.
Recording the evidence for each item in the theory of the user document can be useful in making the case for resources to conduct user research. If you can show obvious gaps — or disagreements — in the evidence supporting the theory of the user, this can motivate people to fund the research needed to fill the gaps.
Continuously improve your theory of the user
Recording a complete theory of the user, even one based on your best guesses, is important both to keep your content consistent and to highlight the importance of the theory of the user to others in the organization. But you must beware of the pitfall of allowing your recorded theory to be treated as established fact.
You must remember, and continually remind others, that the theory of the user is an imperfect document always in need of improvement. Keep looking for better information to improve the document. Keep pressing for time and money to do more research. Keep pressing to be included in research efforts conducted by other departments and incorporate their findings into your theory of the user document.
