A Mile Wide and 30 Seconds Deep: A Metaphor for Help from Mike Hughes

by Tom Johnson on Jul 8, 2009
categories: technical-writing

I don't know if it was my long bike ride along a river or my immersion in the writing phase of a documentation project, but this week I've been pondering Mike Hughes' assertion that help should be a "mile wide and thirty seconds deep." I first heard Mike mention this help landscape metaphor in a podcast several months back. Mike also wrote an article called "The Help Landscape: A Mile Wide and Thirty Seconds Deep" for UX Matters a couple of years ago.

Here's the principle, as Mike puts it: "Help needs to be a mile wide—it must cover everything—and 30 seconds deep—tackling only small amounts of detail at any given point." In other words, your help file should be comprehensive, especially covering niche topics, but your treatment of each topic need not be much—a conceptual paragraph and a list of steps perhaps.

Mike bases his reasoning from user observation and two principles. After watching hundreds of people use help, Mike concludes that "Users go to Help only when they're stuck and stay there only until they feel unstuck." It makes sense, then, to focus on areas where the users might get stuck (which might be the niche topics), and to only provide enough information for users to unstick themselves, after which users return to the application.

Mike warns about the danger of providing too much information, citing John Carroll's adaptation of the Heisenberg Uncertainty Principle: "The more complete training is, the less usable it will be; the more usable it is, the less complete it can be" (The Nurnberg Funnel). In other words, providing too much information actually hurts the usability of the information. People have a small "intake bandwidth," as Mike phrases it, when it comes to help. Overload them and they choke.

Finally, Mike references the Long Tail, a concept from Wired Magazine's Chris Anderson. The Long Tail asserts that, in the long run, online stores with niche products outsell physical stores focusing on mainstream products. Amazon.com is a case in point. With help materials, niche topics (those help topics addressing edge cases and infrequent situations or tasks) collectively receive more hits over time than the core how-to topics. With this reasoning, Mike recommends a help strategy that covers comprehensive, niche information but in short topics.

Mike's strategy seems like a commonsensical approach, one that wouldn't receive much opposition, but it's not one adopted by everyone. For example, the help for Microsoft Office tends to be the opposite, with long help topics and a jump menu at the top for navigation. Some of the topics are so long they could be mini-essays. For example, this topic from Microsoft Word on inserting fields, quite typical of other Office 2007 topics, is 14 pages long.

Unlike Microsoft's help, Techsmith's help (for Snagit and Camtasia Studio) is short, but it also doesn't address niche situations. The help is light, especially compared to their pages and pages of forums. At the last STC Summit, I asked someone at the Techsmith booth why their help didn't include more of the information asked in the forums. The booth representative said the help was purposely light to minimize translation costs.

As I document an application at my work, I've been trying to implement the mile-wide-and-thirty-seconds-deep principle. In the previous version of the application, I focused on core topics, for the most part, covering only the essential tasks because I feared overwhelming users with too much information in the table of contents. After the release, as I received questions I began adding them to the help little by little.

With this second release, I'm now writing a help topic for every task I can conjure up, without fear of having a bloated, unnavigable table of contents. I assume people will only turn to the online help when they have specific questions, and they will search the help rather than navigate it. If they want a basic tutorial, they can refer to the quick reference guides (which I'm lengthening) or a variety of video tutorials. But when they search the help, I want the search results to contain the answers, like Google's results.

I'm not sure how a multiplicity of short topics affects search results. Does the mile-wide-thirty-seconds approach fragment search results into dozens of possibilities, requiring readers to click back and forth ad nauseum looking for the right topic? Do the shorter topics provide more accurate results because they don't contain an encyclopedia of information?

I don't know. But I do know we live in the age of Google, and our users have a search-to-find-it mentality. The challenge is figuring out how to sharpen and optimize search results so that, like Google, the results are accurate.

What techniques are you using to optimize your search results? (By the way, you can follow Mike Hughes' blog here.)