RSS 
Email 
Twitter
FacebookA Mile Wide and 30 Seconds Deep: A Metaphor for Help from Mike Hughes
July 8th, 2009 | Posted in Technical Writing 6 Comments »
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.)
Tags: Chris Anderson, heisenburg uncertainty principle, john carroll, long tail, mike hughes, search, strategy, ux matters
So, in the example you provide, the topic could be broken up into
- Learn about fields
- Insert codes
- Format codes
- Code syntax
etc.
or some such, yes?
Interesting thoughts, Tom; thanks for pointing us to Hughes’ original article, too.
Quick disclaimer: I work at TechSmith, although I didn’t write the help files mentioned above. What follows doesn’t represent the views or policies of TechSmith, just my own personal opinions/questions about trying to write helpful stuff.
With that out of the way, I wanted to comment a bit and ask some questions.
Trying to replace Google is a mistake (not that I think you’re advocating this appraoch). Content authors are never going to be able to match the massive amount of user generated content available with a quick Google search. Instead, we can rely on the behavior that Google teaches users and do our best to support it. I definitely agree with you there.
In the long tail example, the key ingredient of online stores competing with brick and mortors is location. In this case, the help file is a static chunk of data, like brick and mortor stores. Maybe it should focus on mainstream products/topics? Is it the wrong tool for the task of providing help in the Google age? For one author, trying to cover every niche quickly becomes a Sisyphean task. One person is never going to be able anticipate all the problems that might crop up; in fact, some might not even crop up until after the product ships.
When it comes to niches, there are some topics that receive the majority of traffic, and it’d be foolish to not include these in the help file. But without the data to know which topics those are, how do you pick what to include?
Looking at user forums, Google analytics from online tutorials and other data points are great ideas when you have them available to you. When writing for a 1.0 though, or as a consultant where that data just isn’t there, how do you choose? Throwing as many topics as you can come up with at the wall/user to see what sticks is one way, but it doesn’t feel very efficient. My gut tells me there’s a better way to do it than that.
I’ve always thought the hardest part about writing a help file is figuring out what goes in and what stays out. Maybe if you can manage to get everything in there, the new hardest part is making sure it’s all SEO’d.
And it’s not as if we have Google search algorithms available either. The search available in a CHM file is a bit more primitive. We could easily be overloading users’ intake bandwidth on search results, just as we fear to do in ToCs.
With big products (and after 15 major versions between them, Snagit and Camtasia are very feature rich), it might eventually become impactical to cover all the niches. There’s a real danger of becoming 100 miles wide and 5 seconds deep.
I’m really interested if you had any examples of what niches you thought were missing from the TechSmith help files you looked at (since I’m pretty familiar with those
). I’m also really curious how you’re identifying the niche tasks in your own work.
Great post. It’s really got me thinking about how to provide the help users need and how we assemble and display that information once it has been identified.
Arg, tough subject. The answer is probably in the middle – sometimes people want a short, quick reference topic, and sometimes they want a pretty complete reference in a single topic. I don’t know if I’d break up that field codes article; it kinda looks like you need all the parts to use field codes effectively, so why not keep them together? On the other hand, there are some reference topics that stand better alone, even though they’re related to similar things, like descriptions of all the built-in macros (though you’d want a complete list somewhere with links to the descriptions).
@Harry — it looks to me as though the reasoning goes like this: a *manual* (user or reference) should have all that stuff together, but a *help file* should have the information in smaller chunks. If the user wants a small chunk of info on the fly, should they have to wade through the entire topic?
Does that make sense to you?
Sure, it makes sense. But which one does the user need? Does he or she care about this distinction? One of the biggest complaints I hear from users is that the help gives details without context, and they often need the context to know how to use the details. Of course, there are also people who know exactly what they want and just want to look up the details as quickly as possible. But I rarely hear them complain that there’s too much information in a single topic (as long as it’s not trivial waffle filling space).
Perhaps that’s because if you get one 14-page file that has all the information you need about a limited, targeted subject, you can CTRL+F to search just that page, or use the internal jump links, or scan the headings if you want some quick context.
If the information is broken into four topics that are intermingled with your search results, you have to know the subject well enough already to know you just want to insert or you just want to format. Also you have to know that those two things can be separate steps, so you need to keep scanning the search results to get that context.
So, if you talk to some people the topics need to be small and focused; others say that you need fuller topics that provide context.
Time for something more than anecdotal evidence, I guess…