Documentation as a Tool for User Centered Design
Most often, documentation is a post-mortem: “Here is feature X, this is what it does, this is how you use it.”
The value of documentation shouldn’t always be about writing about what a product does and product teams should realize that the process of writing the documentation can and should impact the design of the features. Unfortunately, if the “this is how you use it” part doesn’t make sense most product teams don’t use feedback from the writer, someone who should be a user advocate, to drive a more user centered design process.
Benefits Beyond User Communication
———————————-
Andrew Johnson from TrailBehind wrote this in his post TrailBehind Help Docs as a Design Tool:
> The main benefits [of writing a help section] ended up being 1) simplifying the website and 2) gaining a better understanding of TrailBehind.
> When you are learning anything, reading about the subject helps, getting taught helps, and practicing helps a lot. But what helps the most in learning something, is teaching someone else. I found that writing Help Docs had the same effect.
Documentation can be a valuable tool as it puts you in the shoes of your users. Using the documentation process to help drive user centered feedback into the product is valuable and underutilized. Heck, a lot of the times product teams don’t even test their documentation. They treat it like an afterthought and don’t realize the potential of the experience gathered in writing the content to positively impact the product.
User Experience Proxies
———————–
Technical writers are often the only users exposed to the totality of a product before it ships. Too few teams actually use a user centered design process, but even those that don’t can benefit from listening to the feedback of the writer about their experiences describing what the user should do. In this role they are effectively user experience proxies, and even if they aren’t recognized as such product teams should try to leverage this valuable resource. It is, effectively, free user experience testing. Writers have to write the documentation, you may as well derive some benefit beyond a huge manual.
### Let us know what you think! ###
Do you use your technical communicators as user proxies? How do you leverage your documentation to make better products? Is this more valuable in an agile product development environment? Let us know, we want to hear from you.
-->