NOTE: This blog entry was written about my old portfolio site.

As technical writers, sometimes we have to fight to prove our value to the companies we work for or to our fellow coworkers. The work we do often makes a soft contribution to the bottom line that can be hard to quantify in dollar . For that reason, I wanted to provide a simple example from my recent experience of how documentation—not necessarily even good documentation—can help close a sale. The case study is: my portfolio site! (Very meta, I know.)

I just launched this portfolio site a few days ago. This site is run on WordPress and uses a template that I purchased from a site called Theme Forest. I did some Google searches and shopped around for themes, narrowing it down to about three themes I liked the best.

I chose this theme because it had accessible, good-enough documentation. The theme documentation wasn’t perfect. It was organized a little strangely and could have benefitted from using more task-based headings. There were other stylistic conventions that I thought were a little odd. But the documentation was publicly available (which meant I didn’t have to buy it to access it) and I could read it to get a sense of how easy/difficult it was to do what I needed the theme to do.

There were themes that I objectively liked better. Some themes had slightly nicer graphic design and features. But when I got serious about buying a theme, I started to think about questions like:

• How easy is this theme to install?
• Is it clear how I will use this theme to add the elements I want on my site?
• As I look at the demo and read through the steps needed to re-create it, can I see myself being able to do it?

The documentation, while imperfect, checked enough of those boxes and allowed me to simulate in my mind what it would be like to use the theme to do what I want. The documentation closed the sale for me.

I’d argue that this happens with products more than you might think. If a customer is getting serious about buying a product and moves from being merely interested to actively considering it, they’re going to begin thinking about more than just price and features. They’re going to think about user-friendliness and the resources it would take to actually ramp up to begin using the product.

While it can’t really make up for a poor product UX design, good documentation can help tell a story for prospective customers about how easy the product is to use. As they read the documentation, future customers can begin to visualize themselves or their team as they install and begin to run the product. The clearer and better that mental image is, the more they can see themselves using the product. And that gets them closer to buying.

One final note: this example is also another good argument for making your docs open and accessible (as opposed to being behind a login wall or pay wall). If your docs are not easily accessible, your user will treat it as though there are no docs at all. Having accessible docs is more important than having well-crafted docs. So do everything you can to let your docs live out loud.