Bottom-Up Information Architecture Behind the Firewall

This entry is part 2 of 7 in the series Bottom-Up Information Architecture Q and A

This is the second of the questions from my TC Dojo presentation on Information Architecture Bottom Up.

Q: What happens when the information is behind a wall, such as proprietary applications? How is a bottom-up approach better in that type of scenario?

A: The Web is the ultimate bottom-up information architecture. The Web is far far to big and too complex to ever be navigated top down. Yahoo’s top-down directory of the Web, created when the Web was still relatively small, was recently shuttered, after having been irrelevant for many years.

At the other end of the scale, a booklet of a few pages cannot really be navigated bottom-up. It does not offer enough entry points, and any attempt to search it would be futile. Unless you already knew exactly what was in it, almost no query would deliver any hits. Such a document can only be navigated by scanning or simply reading through. Make it just a little bit bigger, and a TOC becomes practical, while search remains problematic.

Put those small pieces of content on the Web and people will find them with Google. Search works there because it searches everything. Few searches will turn up our small booklet because it is not relevant to most of them. But it will show up where it is relevant.

But it is a different story when it is not on the Web.

The first problem is that if it is not on the Web, people may not try to navigate it at all. For an increasing number of people, the first thing they do when they have a technical question is Google for an answer. If they don’t find one, many will conclude there isn’t one.

I hear some writers say that they want to avoid sending the reader off to Google. But this assumes that the first place the reader looks is in the manual, and that they go to Google only if the manual fails them. That is not how it works today. People are more likely to go to Google first and the manual second or never.

Except in the most extreme circumstances (missile silos, nuclear power plants, Fort Knox) we need to get our content on the Web if we want it to remain relevant.

For various reasons, though, many organizations still exist in keeping their technical content behind a login. Until we can convince management that it needs to be on the Web, we have to create content that works in isolation.

Content does not have to reach the scale of the Web to become too large for a single TOC. Most significant documentation sets are substantially bigger than a single TOC and handle effectively. At the same time, it is not workable in an online environment to offer many individual books or help systems.

People expect to search from one place. When books were delivered in the box with a product, we narrowed the search field down for people by putting the right book in the right box. But when people look for information on our web site, they have to narrow the search field for themselves. If you have only a few products, people may be able to do that by choosing from a list, but if the list gets long or complex, people are more likely to turn to site search.

People turn to search because the information space is too large and complex to navigate top down, and because Google has taught them that searching works.

The problem is, searching a site does not work nearly as well as searching the Web. Search is a big data problem. It is about identifying the preferred resource for a given query, and a Web search engine like Google has millions of data points about the queries people make and the resources they choose to draw on to make good recommendations. Your site search as little or none of that. The search in your help system has still less. Even if they have the technology to search like Google, they don’t have the data.

What all this means is that if people do log in to your site to use your documentation, they are probably going to start by searching, and their search has a good chance of not working very well.

Relying on a TOC alone is not going to help much, because the TOC will probably be too big to be useful, and people are not particularly likely to use it, since Google has trained them to search. In other words, your readers are likely going to try to navigate your material in a bottom-up fashion, and the attempt may well be disappointing.

To improve the odds of the reader’s bottom-up navigation attempts being successful, the best thing we can do is to create a bottom-up architecture for our content.

Since one of the pillars of bottom-up architecture — search — is compromised by having too small a data set and not enough user history, we need to make sure that the other elements of a bottom up architecture work really well.

Those elements are Every Page is Page One topics, and rich and effective linking.

Every Page is Page One topics ensure that the reader always lands on a page that functions independently. They do not have to work their way backwards through a TOC to find a starting point or puzzle out references to points made in “earlier” topics.

Links ensure that if the reader is not in the right place, they have a way to get there rather than going back to the search results. And if the reader needs additional material to fully understand what the current topic is talking about, links make topics on those subjects easily accessible.

John Carroll’s research showed that people were navigating content bottom-up even before the Web. The Web has confirmed and supported that behavior. Readers bring the habits and expectations of the Web to behind-the-wall content, but many of the Web’s best information finding features are not available behind the wall. Given this, creating a robust and effective bottom-up information architecture is even more important behind the wall than it is for material visible to the public Web.

Series Navigation<< Bottom-Up Information Architecture Q and A – Part 1Bottom-Up Architecture Q and A: Organizing the Site >>

2 Responses to Bottom-Up Information Architecture Behind the Firewall

  1. Alex Knappe 2015/02/13 at 11:12 #

    Mark,
    every time you write an article like this, I’m asking myself „when did he last time set foot into a factory?“. I mean, this is all so true for anything that is related to consumer goods or software. But for documentation in the factory world this fails really hard.
    There’s no Google there, no search, no linking.
    In a factory world, all you’ve got is paper, PLC embedded help systems (at least EPPO works there to some extent) and even more paper.
    Workers in factories have no time for information foraging or skimming through additional material, that might explain one thing or another. They’re on a tight schedule, seeking specific information on a task. Bottom-up architecture does not work in this kind of environment.
    The best a factory worker can hope for in terms of bottom-up stuff, are good cross references and maybe a good handcrafted index.
    This is why there’s another approach to the structure of a document – very much like your recipe analogy. It’s the lifecycle structure that uses the different life states of the product to organize the information. This is a top-down approach, that most of the time works pretty solid on the basis of a well known information pattern.
    I mean, I can see lots of potential for EPPO style documents, even in the paper world – but I think relying solely on a bottom-up approach is the wrong way to go.
    A successful information architecture needs to work independently of the medium. It needs to hold solutions for both approaches and cater them equally to be of any use.
    Using my own example of the lifecycle structure here, I can clearly say: this doesn’t really work for software or many consumer products.
    In short: bottom-up is bad for machinery, top-down is bad for other stuff. We need something that can do both.

    • Mark Baker 2015/02/13 at 15:17 #

      Thanks for the comment, Alex,

      I wrote a post a little while ago about documentation that is part of a larger system. (http://everypageispageone.com/2014/06/30/docs-that-are-part-of-larger-systems/) Things are certainly different in that world. One of the most important ways in which they are different is that when documentation forms part of a process like this, people are trained to use this specific documentation as part of learning to use the system.

      There is no particular reason why top-down should inherently work better than bottom up for these cases. But the fact that you are trained in the use of the docs makes the real difference.

      One limit of such systems is that they tend to be tightly coupled, and tightly coupled systems are subject to cascade failures when something goes wrong. In such cases, the ability to make ad hoc queries can save the day. However, many people put excessive faith in their top-down tightly-coupled systems, even doubling down on these characteristics after a disaster, when decoupling to avoid cascade failures might be a better strategy. This is a much larger question than information design, however.

      You say, ” They’re on a tight schedule, seeking specific information on a task. Bottom-up architecture does not work in this kind of environment.”

      Actually there is no reason to believe that bottom up architecture does not work in this kind of environment. Bottom-up does not mean chaos. It means an order that transcends a simple hierarchy and expresses complex relationship that cannot be modeled in traditional paper-based formats.

      One characteristic of bottom-up architectures is that the work well for the information foraging reader. But that does not mean they don’t work well for the informed and appropriately trained reader. A bottom-up architecture specifically designed for the factory environment might well provide faster access to specific information on a task.

      I think it is important to stress that when I talk about a bottom-up information architecture, I do not mean a chaotic and undisciplined process. We navigate the often chaotic resources of the Web bottom up, but that does not mean that bottom-up architectured need to be chaotic. Indeed, if they did, we would not bother talking about architectures at all.

      Bottom-up information architecture is about creating something far more disciplined and structured than random contributions to the Web or a wiki produce, but that structured architecture is not a static hierarchy, but a dynamic hypertext system.