Sometimes, you just open a user manual and know that it is bad. It doesn’t look sloppy, it has a lot of material, the hard work of the documentation team can be seen through the lines. And, it is still bad. How did this happen? This, my friends, is an example of a documentation team falling the victim to disobeying the almighty 80/20 rule. In this article, we will teach you how to use it and create user guides of great quality.
The User Manuals That Could Be Good
I guess we all stumbled upon such user guides: lots of topics, hundreds of them, each functionality seems to be mentioned. We go ‘Wow! That looks extremely useful!”. Then, the disappointment arrives - most of the topics appear to be very brief and shallow, mostly, they just describe some feature and do not provide any tips or use cases. Basically, it looks more like a dictionary than product documentation. We can guess that the tech writers responsible for this user guide did a lot of work and put some thoughts into the project indeed. They got the structure right, they covered most every feature there is, we see correct grammar, proper screenshots...But, it is almost useless. How come?
Or, here’s another example. You want to perform some particular task while using an app. You go to their documentation portal and start researching. You come across great content, long help topics, you see code examples, schemes, gifs. Aaand, you still can’t find anything about the feature you need. It is mentioned several times in some topics, but is never properly described. You get sad, need a buddy to talk to, so you phone their support and ask them - how come they’ve forgotten to include this feature into their documentation when it is a great feature that a lot of users would use for sure! What’s up with this?
I bet that creators of such user manuals have never heard about the 80/20 rule. It is not exactly the rule of tech writing. It is the rule that can be applied to almost anything in this world. Do not take the numbers too literally, it is but an idea, a principle you should follow to keep you safe from making such simple mistakes.
The 80/20 Rule in a Nutshell
This rule is also known as the Pareto Principle. It is named after Vilfredo Pareto, an italian economist and sociologist, who noticed that quite often the 20% of effort has the 80% of the effect.
Initially, Pareto studied the economical situation in the country and saw that 80% of land belonged to the lucky few - roughly the 20% of the whole population. The economist started researching other countries, and the 80/20 rule was true for them, as well. Later, he discovered that these magical numbers are very much applicable to what’s going on outside the economy.
The 80/20 Rule in Documentation Authoring
If we look at technical writing through the prism of the 80/20 rule, we can make a lot of useful observations. For instance, try answering the following questions: would you like to describe every feature in a user manual? And then, this one: do you need to?
The fact is - 80% of people are using 20% of features.
Returning to the questions - you have probably answered YES in the first case. Which means you are, probably, a perfectionist. An ideal user guide in an ideal world will definitely include extensive descriptions of each and every feature. You see, in that ideal world, you would have unlimited time and human resources. But we live in the world of agile software development where efficiency and time frames are everything.
So, you’ll have to tame your perfectionism to improve your documentation quality. Don’t let yourself scatter and don’t feel like you need to cover each and every topic and make everyone happy. Practice shows that it is much better to create one tutorial demonstrating how to work with the main features instead of trying to find resources for hundreds of help topics where, in the end, half would be of poor quality, and the other half would never be used by anyone. Time is the most valuable resource, don’t waste it.
For sure, one must analyse the product and the customer requirements before writing some help topics off the list. Plus, after your user manual gets distributed to the end users, make sure to always keep communication channels open. Sticking to the 80/20 rule or not, feedback should become a crucial part of your documentation writing process. You might find out that some functionality is gaining popularity, and its description needs to be more detailed. Or, on the contrary, some help topic hardly gets any views based on the statistics, then, it is not worth paying attention to at the next documentation iteration. If you want to learn more about documentation feedback, here’s another article for you about user comments in technical documentation.
One more piece of advice. Some parts of documentation are irreplaceable - do not try to get rid of the Getting Started section. That’s exactly where you resources should go. New customers should be in the center of attention at all times. It is them who will move your business forward. Provide them the best onboarding experience possible, and it will pay back.
Conclusion
As you see, the Pareto Principle can be and should be applied to technical documentation. Using this simple rule, you can increase the efficiency of work and make your users happy.
Good Luck with your technical writing!
ClickHelp Team
Online Technical Writing & Documentation Tools