Findability: The Last Mile

By | 2011/06/25

Search is somewhat like an airplane. If you go to a meeting in another city, the plane takes you most of the way. But the plane only takes you to the airport. The meeting is somewhere downtown. You need some other means of transport to take you the last mile to your meeting.

I wrote recently on the impossible expectations that we have of search. Search fails, many claim, because it cannot always get you right to the single exact piece of content that you want. As I argued here, I think that it is unreasonable to ask such precision of search. Even if the limits of language did not interfere, the reader still would not know enough to enter perfect search terms every time. Search is the long haul carrier of findability. But we still need to travel the last mile. And the last mile of findability is being sadly neglected.

Actually, it would not be so bad if search were more like an airplane than it is. If search were more like an airplane, it would always take us to the landing page. And if the landing page were well designed, links would then take us the last mile to the content we need.

The Tardis

The Tardis, credit ©

But search actually works more like the Tardis. Like Google, the Tardis can take you anywhere in time and space, but its navigational circuits are not perfectly calibrated, and the traveller is often left in the wrong part of town. The last mile must then be made on foot. For the Doctor and his companions, this is usually the beginning of an adventure. The Google equivalent, which is to deposit you on a page that is somewhat related to the subject you are interested in, but not quite, is more apt to lead to frustration than adventure, because most pages offer no means for travelling the last mile to the page you really want.

Landing pages might be a wonderful thing if people actually landed on them. I say might, because landing pages usually express the author’s or webmaster’s view of what people should be interested in and how information should be organized, which usually does not match the reader’s view (and cannot, really, because every reader is different). So people use search to bypass the landing page and end up — well, they end up somewhere on your site, somewhere close to what they want, but usually not quite right.

This is the inescapable thing: Every page is page one. Every page is a landing page. Every page is where the long-haul flight of search deposits the reader, and where their last mile to the content they really want begins. And, in most places, there is not a taxi in sight.

The problem is this: we design every page as if it was always the right page. But if we think about it, even for a moment, we must realize that a page is often the wrong page. Many of the readers who land on any given page have not landed on the page they need. They are probably close, at least in the sense that something on the current page is related to what they are looking for, but they are not exactly where they need to be.

Ask yourself this: in your average web search or help system search, how many pages do you look at before you find the one you want? If your answer is just two, then half the pages you visit are not the right page. If your answer is five, then only 20% of the pages you visit are the right page.

By designing every page as if it was always the right page, we are designing pages that do not serve more than half the people that land on them. Having got them close through search engine optimization and all the other tricks of large scale findability, we abandon them in the last mile. Small wonder, then, if they decide to hop a flight to another city and try their luck there.

How do we provide the last mile of findability? I believe the answer is twofold: context and links. A good every-page-is-page-one topic should do two things:

1. Establish its context. The reader has been dropped on the page out of the clear blue sky. They know where they wanted to be, but they don’t know where they are. So the first order of business is to orient them. It must be done quickly and efficiently, of course, but spare a sentence or two to help them figure out what this topic is about and how it relates to other topics. If you are in a large structured information set, you can provide more structured context guidance as well, perhaps something as simple as a box that tells them which product this topic covers, what release it applies to, and what type of information this is.

2. Provide links. Once the reader has their bearings, they are ready for the last mile. Provide them with the links that take them that last mile. Your context-setting material should be rich with links to related material. Remember, search got the reader close. The topic they want is contextually near to the topic they have landed on. Linking on the words that describe the context of the current topic will lead to contextually near topics, providing the means for the reader to travel the last mile. And if you provide a context block that describes the context in formal categories, provide links to related items in those categories. Provide links from this product to a similar topic on a related product, from this release to the same topic for earlier and later releases, from a concept topic to a task topic or an example topic on the same subject. And, finally, provide rich links throughout your content. It is very easy for the reader to hop back on the plane if this topic is not working for them. All they have to do is highlight a phrase, right click, and choose “Search Google for…”, and they are away into the blue yonder. But if that same phrase is a link to your own content, they will probably click on it, and stay in your content.

Links are surprisingly unpopular in technical documentation today. Creating links in traditional DTP tools is expensive, and many of the structured writing tools and processes used today are not optimized for rich and consistent linking either. Authors using DITA are regularly advised to remove links from their content in order to make it easy to reuse.

I think this is a terrible mistake. Linking is the last mile of findability. And the last mile is the only mile that actually delivers the goods. Without the last mile, the whole journey is for nothing. Use SEO as much as you like to bring readers to your content, but if when they arrive they cannot travel the last mile, their journey, and your effort, will be for nothing.

Think about this before you adopt your next authoring tool or platform: Linking — rich, accurate, consistent, reliable linking — is the last mile of findability. If you don’t have a rich linking strategy, you don’t have a complete findability strategy.

6 thoughts on “Findability: The Last Mile

  1. Yuriy Guskov

    “Every Page is Page One” principle resembles textlets which I’ve described at What I mean there, that any page can be considered as “textlet”, that is, text-based mini-application, which may (in simple cases) replace an application.

    In fact, any page can be considered as “black box” which allows some input (answers) and responds with some output (answers). Which means that any page may be even tested as “black box”.

  2. Mark Baker Post author

    Hi Yuriy

    I can certainly see the point that the distinction between content and application is blurring.

    However, I can’t see content as a black box. Grammar is not a function; content requires a more active engagement on the part of the reader. Nor can we be assured that any two readers will derive the same result from reading a given piece of content, and therefor it cannot be considered a black box, which should always produce the same result given the same input.

    1. Yuriy Guskov

      You are absolutely right. The same content may provide different output for the same input. This is why applications fail too and requires testing, debugging, and maintenance, because developers cannot predict everything. But it does not prevent to consider any application as “black box”. Though any user sees and uses application differently.

      Btw, this is why, one of main ideas of my proposal is that identification matters more than information ordering and associating. Different people have different opinion about Bhutan, they have different associations and order information about it differently, that is, it may be a part of very different taxonomies or ontologies, whatever. But the fact we talk about namely Bhutan (not “Bhutan” hotel) matters more. And all associations and ordering are derivatives of identification.

      That is, it is not the task of information creator to give all keywords (which he or she considers as significant). The main task is specify as precise as possible what is information about. This resembles a little your favorite theme about topics. That is, one piece of information should have only one topic or subject (or abstract, that is concise content of an article), which identifies information itself. That is, information creator should at least test if information may be answered with input, which corresponds to the main topic. After that, he or she may test if inputs (which considered as important) are answered with the information. Of course, all possible inputs cannot be covered, but at least, some ones should be.

  3. Pingback:   Weekly links roundup by Communications from DMN

  4. Alexander

    The article has very valid points! And in the context of the “last mile”, the Table of Contents is what may be doing some good job in helping a reader with the last mile. It adds some context to where they currently are.

    But we are still seeing help authoring tools that provide you with links to help topics, while those links open only that single topic page without TOC 🙁 In many technical manuals, TOC is what makes it easier to find what you need if you are landing in a slightly different place to where you want to be.
    Another unpleasant thing in such situations is when you are landing to a help topic, the TOC is properly displayed, but the TOC structure is collapsed. It does not show where you currently are, and hence adding little difference!

    So, a tip for readers:
    Traditional elements like TOC, and the See Also section make a difference when it comes to the “last mile”. Pay attention to those.

    1. Mark Baker Post author

      Alexander, thanks for the comment.

      We have to make a distinction between where you are in the subject matter and where you are in a book. Where you are in a book is not context. And if you divide your content up into books, there is no guarantee that the place you need to be will be in the same book you landed in. Often, in fact, this turns out not to be the case, as people may land on a guide topic when they should be in a reference, or in a reference when they should be in a guide.

      Of course, while where you are in the TOC is not itself context, it may incidentally provide real context information. But TOCs, being hierarchical in nature, can only locate you in one aspect of the subject matter. If you need to move along another axis, TOCs don’t work.

      If you create a TOC of the whole docset, it becomes very hard to navigate.

      Also, the traditional Tri-pane help format is becoming very old fashioned now, and is generally being deprecated, especially for any content that is going to mobile. The establishment of context in each topic, and the use of rich linking, do far more to make a topic set navigable than including a TOC on every page.

      I realize, of course, that you are shilling for your Click to Help product, which, from what little your website reveals, appears to be a conventional HAT moved to the cloud. But your claim on that site that you can just upload and existing manual and get workable help is one that has been pretty well discredited by now.

      It is interesting to note also that while your home page talks about the SEO benefits of putting your help on the web (which is true), there is no sign of any documentation for the product itself on the Web. Why not practice what you preach?


Leave a Reply