Charles Cooper at The Rockley Blog has written an interesting post on the need to think lke a user when developing a document.

Cooper makes one cogent point:

The fact is, most people, especially those who are new to our product (or concept, or service) just don’t have the background they need to ‘instinctively’ find what they’re looking for. So much of what we think of as ‘instinctive’ is really backstopped by prior knowledge.

Cooper compares using a new piece of software or a Web app to trying to find your way around a new city using a map. You don’t have a feeling for the new place, and the map can be confusing. And much of your store of prior knowledge — about other places — might not be helpful.

From the perspective of the technical communicator, the problem with being able to think like a user is that familiarity breeds … well, familiarity. In most cases, we’re using (at least I hope we are) the applications that we document daily. At the very least, we’re exposed to them. Whether consciously or not, we’re building a store of information about the application — where UI elements are, shortcuts, even our own workflows.

We get so caught up in what we’re doing and what we’ve learned (again, more unconsciously than not) that we can easily lose sight of what the new user, who comes to the application tabula rasa, may experience.

The solution? Well, it’s not that easy. User analysis and personas help. In a perfect world, technical communicators would have constant access to the people for whom we’re creating documentation.

So, what’s you’re experience in this area? Feel free to leave a comment and share your thoughts.

Related posts:

1. If it’s not them, then it’s probably you
2. How much prior knowledge should we expect or assume?
3. Catering to the expert user