One of the roadblocks Technical Writers experience quite often, especially in software documentation, is overcoming obstacles in the usability of our doc. In a fast-paced environment like software development, staying ahead of the curve is important, of course. There is always a new program or product to help us write our doc. But will our company invest in it? Is it worth the cost? It’s expensive to train teams on the technology, right? And integrating those new features into existing documentation is not seamless. Competing programs don’t typically work seamlessly with each other. I just read a post about the most valuable tools to tech writers, and while many agreed that Madcap Flare is the tool du jour, that came as no surprise, since a handful of the writers referenced in the article work at MadCap. Other tools noted included Camtasia, Adobe products and even my personal nemesis, Acrolinx (In a later post, I’ll explain why I am not an Acrolinx fan, but let’s save that for another day.)
While the tools we have at our fingertips certainly have a great impact on the work we are able to produce, we as writers can lean on those tools too greatly if we overlook the simplest of design elements and forsake the foundation of what our documentation must be in the first place: usable.
We know that Technical Documentation has a utilitarian function. It has a use purpose: it meets a need of the user because the user requires documentation to, say, install a product. So we have already jumped the first hurdle of the UX measure by designing something that fills a customer need. Check that off the list.
The second hurdle is Usability. We must jump this hurdle by creating something that is easy. In a UX model, we are tasked with creating something that can be navigated with ease. This is where our tools come in handy (or not). If our customers cannot use our documentation easily, we have not cleared this hurdle. Think of the handheld electronics that come packaged with the foldout instructions in print so small that one needs a magnifying glass to decipher even the battery installation. Do we really want to continue that trend? Of course not. Creating easily-used documentation is key.
The next area is Desirablility. Normally, in the past no one thought of technical writing, least of all something like software documentation, as having a desirability factor. Well…I’ve spent a good bit of time creating some YouTube videos that are not necessarily going to win any MTV awards, but they are not exactly difficult to watch. If my customers desire the video over the lengthy text, so be it. This is why a tool like Camtasia or Captivate9 is my favorite tool today.
If my customers feel no pain in clicking through the doc I’ve created because the experience is smoother than tabbing a PDF, it’s a win. In today’s field filled with rich media, documentation is often more off the page than on. Creating pleasing ways of reaching customers with information is an essential piece of the puzzle. So, if I can set up something for a customer whose reaction is more or less, “I like the way this looks,” or “I’ve had a satisfying experience,” then my goal is achieved. It’s why I often marvel when any company is reluctant to jump on board when a technical writer shows management the latest tool toward potential great documentation. (If any of you in management anywhere are listening – equip your writers with the stuff they need to get truly creative. You are unlikely to regret the monetary investment in truly slick presentations, but you are very likely to regret being late to the game. I’m just sayin’.)
Last on the list is to create an overall satisfying Brand Experience. When the other hurdles have been cleared – and generally only when the other hurdles have been cleared – the Brand Experience can be a positive one, because the Utility (need), Usability (ease of access), Desirability (want or perceived want) have been met, and they lead to loyalty. According to J. Josko Braus, of the University of Rochester, brand experience is primarily a sensation or a feeling, but it is part of a brand’s “identity, packaging, communications and environments.”
Braus points out that when customers first engage with a product, they are engaged with its “utilitarian product attributes,” so in this case, my customers are engaged with product documentation (after all, as a technical writer, I’m really selling my doc, but on behalf of the product at large. My customers will associate that documentation with my company’s name, logo, and more, but only on a broader scale. I can hope that customers will be delighted with the overall experience of the end-product, but only after they are satisfied with the Brand Experience they’ve had with my doc.
I could get all academic here, and take you down the rabbit-hole into the debate surrounding Brand Experience, but my focus is on User Experience and how it centers in documentation. If Usability is all about being able to use something, then the User experience differs here because I want my users to be able to have a good feeling about using my documentation – to experience it in a way that enhances their overall engagement with the documentation.
Think of it this way: a usable stapler is one that performs the task. It staples papers together.
And yet when you have mastered the hurdle of mere utility, you can also move ahead with usability, desirability, and brand experience. Because who wouldn’t prefer a really good-looking stapler?