In my last post, which now has more than 80 comments, I noted that authoring with DITA seemed to encourage authors to create a lot of little topics. DITA experts chimed in to say DITA doesn't constrain users with topic length in their outputs -- authors can combine topics as needed. However, one commenter noted that short topics are a best practice anyway:
Most users I have written for have no desire to read or skim through a long page of information. They want an answer to a specific problem. For these users, chunking instead to [create] narrowly defined topics is far preferable, even if it results in a longer table of contents. Providing an effective search mechanism is increasingly vital to the usability of any content, and search paired with small topics is an efficient way to get your users the specific answers they need.
In other words, shorter topics make it easier for users to find the information they're looking for, since there isn't as much content on the page to sort through.
I don't single this comment out for its uniqueness but rather for the way it touches upon minimalism and a general style with topic-based authoring.
Is it really true that shorter topics increase the findability of content?
In some cases, I agree that a short topic might make information more findable. For example, when a user formulates a precise search query that connects dead center with the right topic, a short topic that answers the question more concisely than a long page helps the reader get to the information more quickly. Online examples of successful short topics might be Yahoo Answers or Stack Overflow.
Unfortunately, except for simple, direct questions, that kind of search-and-retrieve accuracy with help content doesn't always happen. More frequently, the search fails to connect to an answer in the help, which forces the user to instead browse around for the information.
If the information is fragmented into too many small topics, the browsing becomes frustrating for the user because the table of contents has too many paths and sub-paths and sub-sub paths. This leads the user to attempt more searches, which often turn up fruitless. After pogo-ing around on half a dozen short topics without finding the answer, the user gives up.
Let me expand more on the three main reasons why shorter topics don't always increase the findability of content.
The search-and-retrieve argument for short topics assumes that the user knows the right terms to search for. Yet routinely, interfaces and applications use a terminology foreign to the user. The application might use "widget" instead of "sidebar section," "module" instead of "plugin," "template" instead of "php include," and so on. Without a knowledge of the correct terms, the user won't be able to connect to the right topic via search.
The second reason the search-and-retrieve model fails is because users don't often construct well-formed search queries. If you've ever looked at a list of search queries from a web analytics engine, the queries are short (one or two words), vague, and often hard to understand.
For example, a user searching for information on setting up a widget might simply type "web layout" or "design site." The chances that this search connects with the topic "Configuring and Setting Up Widgets" are small.
According to Jakob Nielsen, users get progressively worse with each query reformulation:
Given that search is becoming old hat on the Internet, you might think users would develop advanced search skills. Not so.
Typical users are very poor at query reformulation: If they don't get good results on the first try, later search attempts rarely succeed. In fact, they often give up. We recently studied a large group of people as they shopped on various e-commerce sites . Their search success rate was:
- First query success rate: 51%
- Second query success rate: 32%
- Third query success rate: 18%
In other words, if users don't find the result with their first query, they are progressively less and less likely to succeed with additional searches. Many users don't even bother: In our study, almost half the users whose first search failed gave up immediately. (See Search: Visible and Simple.)
The third reason the search-and-retrieve model fails is because users often cannot articulate the real problem they're having. Users can't search for concepts they don't yet know. But even if they do know the concept or task they want, it's sometimes hard for users to articulate what's actually wrong.
For example, suppose the user is having computer issues with slow performance, viruses/adware, and lack of storage space. The user needs help and wonders how to fix the issues.
In such a scenario, the user might search for a variety of issues but never quite pinpoint the exact issue. The user might search with queries such as "computer slow reboot not helpful" or "remove viruses reinstall" or "disc drive time performance".
These searches reinforce the idea that the user doesn't exactly know what he or she needs. That's why the user is searching in the first place -- to try to find information. If the user already knew the exact terms and question to ask, he or she probably wouldn't be using search.
(By the way, earlier I wrote about some of these search issues in Browse versus Search: Stumbling into the Unknown Unknown, so check out that post to dive deeper into this topic.)
There's another reason short topics fail. We often assume that because we like to use Google so much, users must also use our site's search box as their default mode for finding anything. Yet Web Usability Blog found that only about 5% of a site's visitors used the search (see Navigation versus search).
Even if you account for ten times more searchers, that's still only half your audience. How are the other half finding content?
If users aren't relying on search to find the information, they're most likely browsing. If you've fragmented your help into 500 little topics, the browsing experience will be one of constant page hopping.
Without a more accurate search, it's unlikely that users will hit the target they seek. While some technical writers believe the user is a skilled hunter with a compound crossbow aiming at a target 30 feet away, the scenario is more like a kid with a toy bow from Wal-Mart trying to hit a target 100 yards away. The search rarely connects with the right topic. The shorter the topic, the harder it is to hit it.
Shorter topics do add more little targets in the field. So the user has a higher chance of hitting one of the targets, but it's unlikely that any of the targets will provide the exact answer the user is looking for.
One solution might be to tag short topics with a common tag, and then output related topics as links based on that tag. This provides a second-level navigation experience but relies on the fact that users will scan through related topics and follow links. You're limited to about half a dozen related links per topic before the list starts to look unhelpful.
Another approach is to make the targets bigger. You make the targets a bit bigger by providing more information in the topic. Rather than fragmenting your help into a lot of little topics, combine and group similar information into a more substantial topic that is likely to address more issues.
How much information should a topic contain, and why is longer better? I'll make those arguments in another post.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), 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.