A user-friendly documentation is a winning documentation for any technical writer. But creating one can be tricky, especially if you’re writing for a diverse audience that cuts across locations and languages. Here are great technical writing principles that can guide you whenever you’re looking to write user-friendly help materials.
Technical Writing Principles For Creating User-Friendly Documentations
Let’s dig deeper to examine these principles...
#1. Clarify Complicated Concepts More Than Anything Else
One of the key reasons why many product users don’t read help files is because of the jargon they contain. What may seem like a simple terminology to you as a technical writer may be one of the most complicated concepts some users have ever come across.
So if you have a process or anything that is really complicated, the best way to clarify it to users is often through examples. Each example you use, can give your content more and more clarity.
For instance, if you add three examples to clarify a confusing concept or terminology, users will understand it in a clearer way compared to when you add just one example. That said, not every concept or terminology merits an example. But always remember that examples are a major tool in your tech writer tool kit to communicate complex information in a way that is easier for users to understand.
#2. Balance Texts With Visuals
Help documentations and manuals doesn’t have to be boring. If you want your documentations to look sexy, add visuals. There are several options to choose from, workflows, annotated screenshots, diagrams, illustrations or even just pictures, visuals add a lot to documentations.
Visuals balance out texts, provide a different format for understanding, connect to the visual learning modes of the human brain, and is a reference guide to users when performing tasks. Some visuals are tedious to create, but they are absolutely worth it.
That said, if you intend to translate your documentations and all languages are translated equally, or if you intend to focus more on code samples than visuals, you may only do with few images in your content. But that doesn’t mean you shouldn’t strive to communicate with visuals when possible. Always remember, you can communicate visuals to almost anyone anywhere even without texts.
#3. Be The First To Test Out Your Instructions
It will be difficult to assess the help materials you’ve created except you can walk through the instructions and perform the tasks yourself. Testing the instructions yourself seem like a given, and with GUI documentations, it usually is. However, in reality, it’s tricky to do this.
But it’s pretty easy to know when a technical writer has written a documentation solely based on information someone else had shared rather than information the tech writer gathered from first-hand experience. Always do your best to walk through your instructions and try them out yourself.
#4. Work with Quality Assurance to get test cases for what you're documenting
The people in Quality Assurance should be your best friends if you are a technical writer. The people in Quality Assurance always know the system better than anyone else. They set up test environments to ensure the functionality, and they often have a set of test cases (features to try) for each release.
For instance, if you’re documenting an API the QA engineers might already have the calls to test in ready-to-go formats. Relying on some QA efforts can make writing documentation a lot easier.
Nonetheless, in some cases, Quality Assurance may not have the higher level business information about the different scenarios the features will be used for. In many cases, they only test if the feature will work or not. You may have to consult product managers to get a higher level picture of what the feature would be used for. Yet, working with your Quality Assurance team, can make your work a whole lot easier.
#5. Incorporate user feedback in your evaluation
You’ll have to get direct feedback from users to understand the actual value of your documentations. You can’t draw a logical conclusion based on assumption. Whether users understand the documentation or not, whether it meets their needs, and so forth, is really a guessing game unless you get more tangible feedback from the intended people who actually use the help products.
Read more about audience analysis in technical writing, how to get the facts right.
Now because of the need to incorporate user feedback, you should consider having some interaction (even if directly via a call center, social network or forum) to evaluate the help material appropriately. Always remember that, it’s difficult to evaluate your help file from your experience alone. This is one of the 5 major skills you need to become a great technical writer.
And even if you’ve tested all the instructions and realized they work, you may be too familiar with the instructions and walk through them easily. Or you may be missing large pieces of required information or you may have misinterpreted the deployment platforms, scenarios etc.
#6. Publish your help materials in user-friendly formats
Don’t limit your help materials to just one or two formats. Users often have access to several different devices and operating systems. For a start, see the 7 best formats to publish your help materials.
You can use a help authoring tool like HelpNDoc for documenting and publishing your content in several different formats including Windows CHM help files, WEB based documentation, iPhone specific websites, printable PDF and Word documents as well as ePub and Kindle eBooks and cross platform Qt Help files. The best part, HelpNDoc is free for personal use and assessment purpose.