The 80/20 rule, or Pareto's Principle, states that 80 percent of the effects come from 20 percent of the causes. Applied to help authoring, this could mean that from 100 help topics you write, about 20 of the topics will be viewed 80 percent of the time.
Designers recognize the applicability of the 80/20 rule on design. Heat maps show that people only focus on about 20 percent of the page. This is where good designers will focus their energy.
Webdesign Depot explains:
Assuming this is a good indicator of where a user's eye is focused, this supports the concept of the 80/20 rule. The most intense areas on the map could represent the 20% of the page that the user's eyes interact with 80% of the time.
From that knowledge, as designers, we can make decisions that will help enhance and optimize the areas that the user is going to be habitually drawn to. (The 80/20 Rule Applied to Web Design)
If this rule indeed holds true, how should the 80/20 rule affect the help content we create?
All too often we treat software documentation on a topic equality basis. Every topic usually gets our full attention and care. We slog through one topic after another, moving slowly but surely as we prepare our help system.
Instead, why not figure out the 20 percent of topics that most users will be interested in, and then pour the majority of our time into developing content for those topics?
For these high-use topics, we could add screenshots, videos, quick reference guides, FAQs, and more. Figuring out these topics is to identify the core -- the beating heart -- of the help content.
To increase the visibility of these high-use topics, we might also put links to these top 20 percent topics on the homepage of the help, or in special portals. This way if we don't have context sensitive help, users will get to the information they need.
But you may object that it's only in hindsight that we can identify of our most influential topics.
This is true, but perhaps this is where the real change comes. I noted a few months back that we approach help authoring backwards. In a phased approach, the first release of help might contain a text-only skeleton of help content. The second phase, after you identify the frequently accessed topics and questions, could contain more multimedia and visuals.
Regardless of the approach, my point is this: I spend far too much time creating content no one is asking about. I should instead focus our time and energy on the content that matters.
The 80/20 rule is such a fun rule, though. Why stop here when there's so much more territory to cover? Here are a few more possible applications of the rule.
During your 8 hour day at work, you accomplish your most influential tasks in about 1.6 hours. (This is probably the time you actually spend writing, while the rest is taken up by meetings and other distractions.)
Although you put in hard work throughout the year, only about 20 percent of your effort makes a difference, while the rest goes unnoticed.
80 percent of the effect comes from just 20 percent of what you say. A full five minutes of praise followed by a brief but bitter and cutting negative remark sours all the positive.
A page with impressively written instructions but which is missing a critical step makes the entire procedure baffling and the experience negative for users.
In a blog post of 1,000 words, only 200 will be memorable.
80 percent of the funding in your department probably goes toward 20 percent of the products.
20 percent of your products probably make 80 percent of your company's profit.
80 percent of the book you're reading will be a waste of time.
80 percent of your time spent on the project will be in useless meetings. Except that a few key meetings, maybe 20 percent of them, will make meetings worthwhile enough that you can't miss skip out on them entirely.
Of the 10 tweets you post, 2 of them get retweeted a ton of times while the rest fall into thin air.
Twenty percent of the blog posts you write will garner 80 percent of the traffic, while the rest languish unread.
80 percent of your team's output comes from just 20 percent of your employees (don't fire those ones).
A novelist who writes 8 novels really only gets notoriety for 2 of them.
A musician who becomes famous is recognized for her 2 songs, while 8 of the others are easily forgettable.
20 percent of your child's activity will lead to 80 percent of your headache (e.g, screaming. jumping).
Your users will probably only use 20 percent of the features in your application.
80 percent of the calls to the support desk will be about 20 percent of the features of the application.
Those short few words of praise when you're critiquing someone's writing mean more than 80 percent of anything else you say.
I probably only use 20 percent of my English vocabulary, but I use these words 80 percent of the time.
My wife is right about 20 percent of the time, but her aggressiveness and memory helps her seem like she's right 80 percent of the time.
At conferences, 80 percent of the sessions you attend will be mediocre; the 20 percent that you do attend will be memorable and worthwhile.
As a breadwinner, you're gone from your family most of the time, but that 20 percent of the time you're at home counts for about 80 percent of your influence.
20 percent of the punctuation marks available to you are used 80 percent of the time. (Think about the comma and period, rather than the colon, semicolon, dash, and ellipses.)
20 percent of your users give feedback, but their feedback influences 80 percent of the product decisions with the team because these users are so vocal.
20 percent of the tech comm gurus are responsible for 80 percent of the influence in the industry.
20 percent of what you eat contributes to 80 percent of your weight.
20 percent of your brain contributes to 80 percent of your thought.
20 percent of your dates contribute to 80 percent of your children.
Okay, I'll stop.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.