Efficiently Simplifying Navigation, Part 1: Information Architecture

Advertisement

Navigation, as crucial as it is to the user experience, is merely a means to an end — the end being to consume content. This is why users have very contrasting expectations about content and navigation. While content is supposed to be unique, surprising and exciting, navigating to it is supposed to be as simple and predictable as possible.

This series of articles, divided into two parts, is a four-step guide to efficiently simplifying the navigation experience, by analyzing the type and amount of content as well as choosing and carefully designing the right type of navigation menu.

Four Steps To The Ideal Navigation System

To build a usable navigation system, a website designer has to answer four questions, in this particular order:

  1. How do I best structure the content?
  2. How do I best explain the navigational choices?
  3. Which type of navigation menu is best suited to accommodate the choices?
  4. How do I best design the navigation menu?

The first two questions concern the structuring and labeling of content, which is often referred to as information architecture. Information architects typically visualize the results of their efforts in a site map diagram.

site map1
A site map diagram gives an overview of the navigation structure of a website. (Image: Web Tuts2)

However, for reasons that will be explained in detail during the course of this series, just providing a site map to navigate would not provide users with the best possible experience. Designing a custom navigation menu that properly accommodates, arranges and progressively discloses their options is also important, thus allowing users to comfortably find, browse and skip choices.

Designing such a navigation menu can be achieved by answering the third and fourth questions mentioned above, which refer to the interaction design of a navigation experience. The first two questions will be addressed in this first part, the latter two in the second article.

Structuring The Content

To properly structure the content of a website, first consider how users look for information, and then structure the content in a way that best aligns with those preferences.

How Users Look For Information

When a user is looking for something — be it a car, recipe, financial service, item of clothing, news article, fitness exercise, entertainment video or any other item or piece of information — they may or may not know the exact name of what they’re looking for. If we assume that users will always know the exact name of what they’re looking for, then we could argue that the best way to take them there would be to provide them with a large A-to-Z index or simply have them type in a search field.

Of course, things are not that simple. As will be explained in more detail in part two, even if users always knew the exact name of what they’re looking for, both an A-to-Z index and search have inherent interaction problems that make them inadequate as the primary or sole means of navigation. Moreover, users often do not know the exact name or do not even care about the item or its name; rather, they have a keyword or feature related to what they’re looking for.

The first step to safely guiding users to the right content, then, is to aggregate and categorize the types of items on the website.

Meta Data As The Foundation Of A Navigation System

The information collected about an item or piece of content is typically referred to as meta data — that is, information about information.

Without getting into specifics, items may belong to distinct meta data categories, whether a category is the political focus of a news article, the display size of a monitor, the director of a video, the collar type of a shirt or the degree of difficulty of a fitness exercise. Of course, multiple items may also share categories, such as price, popularity and publication date.

Users could browse content via these meta data categories. However, as we will see, giving users every possible way to browse content is not necessary or even helpful. Doing so would at best clutter the interface and slow down and complicate the navigation process and, at worst, would confuse, tire and annoy users to the point that they simply abandon the website.

Carefully consider whether and at which stage to show categories to users.

Three Types Of Meta Data Categories

To decide whether and when to present a meta data category, divide your categories into three groups: crucial, optional and irrelevant.

The challenge of information architecture is that classifying a category as crucial, optional or irrelevant very much depends on the preferences of the target audience, the website’s purpose and even the volume of content. However, once you’ve settled on a proper categorization, a few simple rules will help you decide when to show which categories.

Crucial Categories

Crucial categories are ones that would be important to all targeted users. These categories are rare, but there seems to be at least one crucial category for every item, which simplifies both the work of the designer and the navigation experience for users.

Determining Crucial Categories

A small selection of meta data categories for recipes might be “course,” “main ingredient,” “special diet,” “occasion,” “cuisine” and “cooking time.” Of these categories, the only crucial one would be “course.” Not everyone is on a special diet and not every meal is a special occasion, but almost everyone on any given day separates their meals into appetizer, breakfast, main dish, side dish, salad, dessert, etc.

Because the course would be important to all targeted users, it should be the first category presented to them.

courses3
“Course” is a crucial meta data category for recipes. (Image: Our Best Bites4)

However, as mentioned, the target audience or website’s purpose might affect the classification of categories, especially on niche websites.

For example, “cuisine” would not be relevant to all users who visit a mainstream website about recipes. But if a website collects the best recipes from popular cuisines around the world, then “cuisine” could very well be a crucial category for the target audience, whether in addition to “course” or replacing it as the only crucial category. In any case, because “cuisine” is the main theme of the website, showing it first (instead of “course”) would be appropriate.

cuisine5
Niche websites have different crucial categories of meta data. (Image: Recipes by Nation6)

Arranging Crucial Categories

The examples above address only single crucial categories. However, a set of items might encompass multiple crucial categories.

Take apparel. One crucial category could be the type of clothing, such as “shirts,” “pants,” “shoes” and “sweaters.” Another crucial, and mutually exclusive, category would be gender, “men” and “women.” A third could be the occasion, such as “casual,” “work” and “dress.” We could have more crucial categories, but we’ll leave it at that.

The question, then, is how best to accommodate and resolve potential conflicts between multiple crucial categories.

At first, placing all crucial categories on the same top level might seem logical. After all, they are all crucial. However, the opposite should be done. Crucial categories are best implemented one after the other, on succeeding levels. To better understand this, let’s look at the information architecture of the website shown below.

information7
A horizontal bar is often used to list the type of products that a website offers. (Image: LL Bean12108)

A horizontal navigation bar lists the types of products available from LL Bean, such as “home accessories,” “hunting and fishing,” “outdoor gear,” “footwear” and “clothes.” However, the designers did something different for “clothes.” Clothes tend to fall into the categories of “men” and “women,” but rather than list a dozen types of clothes in the horizontal menu, the designers decided on a crucial category with fewer values. The user simply starts off with “men” and “women,” and then they get to see all of the types of apparel available in the drop-down menu, which allows for more options than the horizontal bar.

clothes9
Using a crucial category with fewer values for the main navigation bar frees up space. (Image: LL Bean12108)

This presents a slight inconsistency in the information architecture, but the designers accepted it to free up space in the horizontal bar. The solution is fine as long as the inconsistency does not confuse users, which is unlikely in this case. However, placing the category “footwear” (which, understandably, distinguishes between footwear for “men” and “women”) on the same horizontal bar is not as sound a decision.

clothes11
Crucial categories should be presented one after the other, not next to one another. (Image: LL Bean12108)

The problem with this solution is that two crucial categories have been placed on the same level. Both “Footwear → For Men” and “Men → Footwear” are direct paths. However, because both categories are crucial, users have to look through both anyway. But because they are placed on the same level, users are asked to choose between them, which undermines the assumption that both categories are crucial. Thus, one of the above paths could be removed — probably “Footwear → Men.”

Footnotes

  1. 1 http://www.smashingmagazine.com/wp-content/uploads/2013/10/sitemap.jpg
  2. 2 http://webtuts.byethost16.com/build-a-simple-sitemap-generator-with-php
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2013/11/courses.jpg
  4. 4 http://www.ourbestbites.com/category/recipe-index/
  5. 5 http://www.smashingmagazine.com/wp-content/uploads/2013/10/cuisine1.jpg
  6. 6 http://recipesbynation.com
  7. 7 http://www.smashingmagazine.com/wp-content/uploads/2013/11/information.jpg
  8. 8 http://www.llbean.com/?nav=gn
  9. 9 http://www.smashingmagazine.com/wp-content/uploads/2013/11/clothes.jpg
  10. 10 http://www.llbean.com/?nav=gn
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2013/11/cloth.jpg
  12. 12 http://www.llbean.com/?nav=gn

↑ Back to topShare on Twitter

I am a freelance user interface designer based in Greece. Having studied Social Sciences and Philosophy, I believe that a proper philosophy of language is crucial to any well-designed social or digital information system. My main areas of expertise are: Interaction Design, Information Architecture, Empathy, Usability, Nomenclature.

Advertising
  1. 1

    I’m sorry but I have to object to your matter-of-fact tone in which you state your opinion on the subject of Information Architecture and in particular on classification of contents. Not to mention that some of the things you mention are just flat out wrong.

    For one, there is no such thing as a “crucial category”: not in Information Architecture theory and most certainly not in practice. What often exists though is a ‘preferred category’ or rather ‘preferred taxonomy’ in which contents is structured. This taxonomy only gets to be ‘preferred’ based on domain knowledge, and thus differs from site to site (read audience / user-base) and is simply based on which ‘entrance’/starting point the largest portion of your audience feels most comfortable with pursuing. Nothing more, nothing less.

    Moreover, bluntly stating that only labels from the ‘crucial category’ should be contained in the primary navigation is flat out wrong. The millions upon millions dollars spend on usability studies by Amazon, Nike, etc. are testament to that: a system of navigation (primary, secondary , what have you) is good when it works for the largest possible percentage of your target audience. It’s as simple as that. Of course, we can’t achieve perfection, but we can surely try. That’s what usability tests are invented for.

    The fact that a site such as Nike, which you seem to eagerly dismiss based on your rigid definition of how content should be classified, has labels from multiple categories/taxonomies is because they want to cater for different shopping intents. Most people probably want to enter through ‘type of clothing’, but others may want to look for ‘sale’, or ‘price ‘(think people buying gifts) , or seasonal/topical (think people that want to freely browse all clothes independent of clothing-type for wintersports, beach, street, etc.). A ‘preferred category’ really is nothing more than the category/taxonomy that takes up the most space/labels in the primary navigation. I personally don’t even see a practical use of using a distinction between ‘preferred’ and the others categories, but perhaps that’s just me.

    I could go on, but I don’t want this ending up in a rant. I appreciate this article, since Information Architecture is often overlooked yet extremely important. I believe we share that notion. However clearly stating the things you describe as your opinion rather than fact would go a long way.

    Cheers,
    Geert-Jan

    2
    • 2

      Anastasios Karafillis

      December 3, 2013 12:56 pm

      Hi Geert-Jan,

      quite frankly, you seem to have completely misunderstood my arguments as you can already find the answers to your objections in the article itself. But I will repeat and apply them to your comments specifically.

      First, it is difficult to see how your definition of “preferred” categories differs much from mine of crucial categories. If users prefer one category over the other, does it not mean it is more important to them than any other? My definition of crucial categories is that these are categories that are deemed important to all targeted users, while optional ones are deemed important to some. I provide so many examples for this distinction that I have to assume you read too quickly to notice them. And, of course, classifying categories depends on the audience/user base. This is why I gave examples (of recipes sites) of how the target audience of niche and mainstream sites can have different preferences, to use your own terminology. Again, I assume you overlooked that part as well.

      The only difference I see is that I suggest to put only a single crucial/preferred category on the first level and to relegate optional/less preferred categories to the second level, while you want to place all options on the first level. This may seem like a nice service, at first, but, in fact, this could unnecessarily increase the complexity of choice, duplicate paths and clutter the navigation menu. And while I support user research, after all, I always mention the target audience, it can only help you so much.

      For example, it is true that even on a mainstream site users sometimes arrive with a very specific mindset, such as “I want anything that is low fat”. But even those users will have to divide their meals at some point into low-fat breakfast, snack, dessert, salad, etc …, especially if your site offers thousands of recipes. So why not have all users simply select the course first, which is something that is deeply embedded in their life-style, and then have them select a special diet “in addition”, just as in the flipkart example I gave? If you need another example, take a look at the following page:

      http://allrecipes.com/Recipes/Healthy-Recipes/Low-Fat/Main.aspx?prop24=hn_browsedeeper&evt19=1

      The site has more than 2000 low-fat recipes. So, understandably, the designers wanted to give users an important category to narrow down the large amount of content in a meaningful way. And to do so, in the low-fat dropdown menu, they gave them, exactly, the course. But since you insist on user research, consider someone who has conducted more usability research than all of us combined, Jakob Nielsen. I often disagree with him but, in this case, I agree that a poly-taxonomy that you suggest can easily become a crutch for users, as you can read under point 4:

      http://www.nngroup.com/articles/top-10-ia-mistakes/

      Finally, I would like to say that I do not consider your comment a rant, just filled with weak points. It is true that authors who publish content via such a prestigious site as the smashingmagazine have a high responsibility because web designers turn to such a site to learn about web design. But, of course, authors can make mistakes as well. This is why a comment section is so important as it allows other professionals to correct the authors so designers do not take wrong advice. And therefore, I would want to encourage you to state the many other mistakes you saw that I allegedly made, although this comment of yours did not have a single valid point I have to say. But maybe your next one will.

      0
      • 3

        Can’t we all just get along? OK, I’ll add a few things:

        You say “This may seem like a nice service, at first, but, in fact, this could unnecessarily increase the complexity of choice, duplicate paths and clutter the navigation menu.”

        On the first part I coincide, but I think providing, say, 1 alternative path isn’t unwieldy. For example, starting from brand (for loyal folks) or budget (said: price) on a gift web site could make a lot of sense — perhaps because the gift buyer has a rigid price ceiling in mind, and she really doesn’t know what to buy for her loved one.

        The second part about duplication is only true is you create the duplicate paths or convey the orientation to user confusingly. It is completely possible that the below gets you to the same precise location:

        1. Select [Under $50]. Select [Bracelets].
        2. Select [Bracelets]. Select [Under $50].

        If it’s the same finite state, then it’s not duplication. It’s just allowing for a different mental model. “Under $50″ would be enabled by the selection of multiple values in a (browsable) facet called “price.”

        Lastly, many people think that the web site menus have to model the taxonomy. In fact I find that its best to think of taxonomies in the abstract. They define what something _is_. Then menus can apply the abstractions to make common decisions more obvious and require fewer steps. In other words, the link “Womens Running Shoes” is likely a choice in the menu, but it doesn’t have to be “Shoes > Women > Running.” Rather, it could be Category: “Shoes” & Gender: “Women” & Type: “Running.” Order of selection can be rather arbitrary but the menu can convey it in the most digestible syntax.

        1
  2. 4

    IA is very important topic! What’s missing here is a process behind formulating navigation and application structure.
    There are several steps which lead to meaningful IA. “Crucial categories” and other may crystallize during discovery but those are not important. Important how one gets there. We really should be talking about creating Personas and assigning User Stories and/or Use Cases to each one and so on. During stakeholder and user interviews UX designer may conduct card sorting or paper prototype testing (just to name a couple activities). These are very important arguments in rationalizing final IA.

    1
    • 5

      Anastasios Karafillis

      December 5, 2013 4:37 am

      Hi Alexei,

      good point. Knowing your users is very important. Without this knowledge, classifying categories as crucial or optional would be pointless in the first place.

      Be aware, though, that conducting the type of user research you suggest may not be inexpensive. Of course, you could argue that not conducting user research would be even more expensive for a client.

      You may find the following article interesting in this respect:

      http://uxmag.com/articles/love-hate-and-empathy-why-we-still-need-personas

      as well as the discussion in the comment section.

      However, notice also that user research has its limitations. The best thing users will often do is to give you an honest answer, not necessarily a useful one. For example, surely many, not all, users will tell you that they like a certain brand. There is nothing wrong with that. But rather than asking users the same question, brand or type of cloth, on two levels, why not ask them first about the type of cloth and then about the brand? After all, if you have thousands of items, users would have to answer both questions anyway.

      Another example is that users will only tell you that they do not like using a certain product, but not necessarily why. For example, when Apple introduced the three columns layout for Apple Mail, many users did not like it yet without being able to specifically point to what exactly bothered them. In that case, one would have to use their empathy and ask themselves how users would use that product. I discuss this point in this article:

      http://www.uxbooth.com/articles/user-interface-design-getting-the-basics-right/

      I agree that user research is important. I mention this throughout the article a few times, although I did not specifically address the topics you mentioned. The article is quite long as it is. But even user research can only do so much for you and, ultimately, it will have to be a combination of many things that will have to come together to create an engaging, easy-to-use interface.

      Hope this helps.

      0
  3. 6

    I agree with Geert-Jan Brits and Alexei Rebrov and I don’t particular like the rebuttle that Anastasios Karafillis made to Geert-Jan Brits and thought this was quite rude.

    There seems to be a mixing up of categories and attributes. A category is a collection of items. An attribute is part of an item. This whole concept of calling everything a category I don’t believe is accurate. It appears you call a category a cruical category (such as shoes), then you call an attribute an optional category (such as colour) and then other attributes (such as word count) you call an irrelevant category. I think this whole thinking is flawed but I won’t go into details why. I hope this is ok and I don’t get critised by Anastasios for providing a weak point, but if I do, oh well, it will probably say more about the Author than me.

    3
    • 7

      Anastasios Karafillis

      December 5, 2013 2:30 am

      Hi Marc,

      this discussion reminds me of someone saying: “Everybody thinks they are right, only I think that I am right.”
      See, you do not have to go into details as to why my arguments are flawed but you should not be surprised that I am not particularly impressed by someone saying: “You are wrong but I will not explain exactly why.”

      What is more, by your logic, it seems that you can criticize me all you want but if I dare to respond, I am a bad person, no matter what I respond. Not too impressed by that logic, either …

      But I would still like to respond to your objection about categories. I would say that a collection of items is collection of items. However, what makes them a collection of items that actually belong together is the fact that they match a certain category. And the name of the category simply describes the reason they belong together. So, why separate between the two? But maybe it is just semantics and we are somehow on the same page.

      And finally, as to my comment to Geert-Jan: He challenged my arguments, so I responded by giving another example in addition to the one I already gave in the article plus I added a link to Jakob Nielsen where he supports the idea of not duplicating taxonomies. That is all. And if Geert-Jan thinks that there are many other mistakes in the article, then I honestly encouraged him to name them, simply to avoid spreading misinformation, whether it is mine or his. Again, that is all.

      But if giving examples and arguments and encouraging meaningful discussion is considered rude, well, then so be it.

      0
    • 8

      @Marc: in case you’re interested: http://www.uxmatters.com/mt/archives/2011/08/categories-facetsand-browsable-facets.php. Imho, one of the seminal blogposts on the subject.

      Btw: I appreciate you (and @Ishka) rebuking the author for that reply, which I for a moment thought to dignify with a response. Then that second passed.

      0
      • 9

        Anastasios Karafillis

        December 5, 2013 3:18 am

        Hi Geert-Jan,

        this is the second time you threaten to provide powerful arguments.

        How about actually providing them?

        -1
    • 10

      I’m confused. Aren’t you just arguing semantics now? In my interpretation of the article, I thought the author was merely stating you need to break your products, recipes etc into as few main groups (categories) as possible for ease of the user, as long as that is best for your target audience. Secondly, you have smaller groups (categories or attributes) in which users can refine their search. Regardless of the naming convention the author used, how is it wrong?

      0
    • 11

      I don’t know if it’s wrong to call them all categories, but it may be confusing. In practice, I term the main taxonomy the “category tree.” I call everything else a “facet.” Those facets that behave like categories in that values can be browsed to in the absence of a category selection, I call “browsable facets.” See http://www.uxmatters.com/mt/archives/2011/08/categories-facetsand-browsable-facets.php . Technically they’re all taxonomies. I guess you could call them categories, but I avoid using that term for anything other than the main category tree for clarity reasons. Usually, it goes like this:

      1. There is 1 category taxonomy. It’s usually a tree.
      2. Everything else is usually non-hierarchical taxonomy (a facet). That’s out of necessity. It’s difficult to present multiple hierarchical taxonomies because of the “split ends” problem anyway. Technically a facet could have hierarchy, but in practice they usually do not, or only in a limited way, for this reason.

      Browsable facets contain values that a different mental model might prefer as a first decision. Usually it goes like this:

      1. They cover most products. Think brand or material.
      2. They could reasonably be conceived as categories. I also say they’re “surrogate categories,” but I picked browsable as the term because “values can be browsed to in the absence of a category selection.”

      Someone here said:

      > For example, it is true that even on a mainstream site users sometimes
      > arrive with a very specific mindset, such as “I want anything that is low fat”.
      > But even those users will have to divide their meals at some point into low-fat
      > breakfast, snack, dessert, salad, etc

      Respectfully, I believe this is false. We have to draw the line somewhere, but we can’t presume to know the intent & priorities of the user. Someone on a low-fat diet may be looking for ideas.

      And hasn’t everyone eaten pizza for breakfast at least once?

      1
  4. 12

    It is a shame that the author took Geert-Jan Brits comments so personally and was so rude. Makes me not want to read this blog anymore, if that is how the blog authors react to their readers concerns. Otherwise an interesting article to include in IA thinking.

    1
    • 13

      Anastasios Karafillis

      December 5, 2013 2:31 am

      Hi Ishka,

      Ishka, my intention was never to be rude. I work hard to provide facts and arguments in both my articles and comments. That is all. But if you still think that I was rude and you do not want to read my articles, that is o.k.

      However, the smashingmagazine has a large variety of authors with very different styles and personalities. Punishing the other authors for my behavior would not be fair.

      1
  5. 14

    I think the problem with this article is not whether the author is right or wrong, but instead is just the lack of evidence for the statements made and advice given.

    The article presents opinions as facts, with almost zero explanation on why they are valid. The author needs to provide evidence. Something like a case study on how these companies were able to show an increase in sales by A/B testing tweaks in the menu.

    Until the author author backs up statements with evidence, they are just opinions. Whether correct or incorrect.

    1
    • 15

      Anastasios Karafillis

      December 6, 2013 5:32 am

      Hi Chava,

      I would say that common sense beats A/B testing and I will explain why. But first consider a few problems of A/B testing.

      Any testing can provide useful insights but you have to be very careful with properly evaluating your results. For example, many sites may have found that using a call-to-action button with rounded corners is more effective than one with sharp corners. Does that mean that rounded corners are better than sharp ones? No, the rest of the interface used rounded corners, so the sharp corner button looked out of place.

      You should take the results of A/B testing with a grain of salt. Maybe they were based on a wrong methodology. Maybe the changes worked for that particular project but not necessarily for yours. By contrast, if you have common sense, you can proceed with much more confidence. Here are a few examples, taken from the article, of how common sense can help you remove any unnecessary information from your navigation menu, which is the premise of this article:

      1. The nike site provides both a traditional navigation menu and dynamic filters to select the very same values. You can test yourself which is faster. Fact. Remove the other one. Common sense.

      2. Both “Men > Shoes” and “Shoes > For Men” are straightforward paths but both do the same thing. Fact. Remove one. Common sense.

      3. Icons help process and distinguish choices. I would say this is so obvious, no testing is required. Nonetheless, I display the same menu with and without icons. Ideal for A/B testing. Feel free to test it.

      4. If you have a headline like “Pope says Catholic Church should focus more on poverty” and the description states that “Pope Assisi says that the Roman-Catholic Church should focus more on helping people out of poverty”, then the description provides no new information. Fact. Users know what the article is about only by reading the headline. Fact. Description is redundant. Remove it. Common sense.

      5. People cannot understand brand names like “Tribeca” without pictures unless they work there. Fact. Add pictures. Common sense.

      6. If I am interested in a category, for example, “Watches” I will not select another, undesired category, for example, “Cars”, just because it has more items. Fact. Remove figures. Common sense.

      7. The business of search engines is to provide context to their results. Fact. Articles provide context for recommended reading. Fact. Social media is by definition unambiguous. Fact. Consequence: Remove outside context from headlines. Common sense.

      I could go on but you see how powerful common sense can be. I would say that these statements are so obvious, I would not want to spend any time and money to test them, something that many smaller web sites do not have at their disposal anyway.

      Hope this helps.

      1
      • 16

        @Chava I have to agree with Anastasios here. It’s almost impossible to test these things and conclude anything other than “it depends” and “it works for me.” This is because it will depend on (in eCommerce) what you sell, how much you sell, etc. It’s also impractical to rip your IA apart even with unlimited resources. It would cost too much and disrupt search marketing with certainty.

        However, the word “menu” raises an interesting point. The above concerns apply more to the actual taxonomies (that is, categories & facets) than the menus. Menus use taxonomies. They don’t have mirror them. Mega menus in particular almost always make multiple selections at the same time. You can often redo them using the same facet-enabled taxonomy-plumbing, and doing so is less disruptive than redoing taxonomies for sure.

        That’s one of the huge benefits of faceted classification. It’s less rigid and adapts to new problems over time. Being able to redo the menus without too much disruption is 1 manifestation of that power.

        0
  6. 17

    Interesting food for thought. Thanks for the article

    0
  7. 18

    Anastasios, this article is packed with info and is a good read. I read some of the comments posted and your responses, and one thing I’d point out about this particular comment:
    “I want anything that is low fat”. But even those users will have to divide their meals at some point into low-fat breakfast, snack, dessert, salad, etc …, especially if your site offers thousands of recipes. So why not have all users simply select the course first, which is something that is deeply embedded in their life-style..”

    is that many users of a site like this may also want to plan their entire day of meals rather than just one. So selecting which meal you want first might not be the best option. In particular, if you are someone coming to a site like this for specific needs like say gluten-free meals or something.
    Additionally, if you are an ecommerce store that broke down your categories in this way (selecting a meal type instead of low-fat foods) it would rule out many products that could possibly make a sale, as the shopper would only see products from the breakfast category. So, I would say selecting a category like low fat first would be ideal.

    Anyway, you’ve obviously spent a lot of time writing the article and it has some good points, so no reason for anyone to get flamy about it.

    1
    • 19

      First, let me say that I highly appreciate the amount of effort that was put into this article and will look forward to Part II, if the author is not jaded or burnt out from his experiences in the comments and can continue.

      A line of research posits the raison d’etre of reason itself as argumentation, so it is not surprising that the author, who has put so much work into the article, would defend his position so staunchly. Still, yes, it could be done in a more emotionally intelligent manner. That is something that will come with experience and emotional maturity. The experience of anger or extreme motivation and the resulting hashing it out in the comments will eventually get old, and the author will realize that argumentation can be civilized, even refined. That, my friend, is collaboration, even creative critique in other circles. The relationships just such an environment can foster in the comments is what makes a blogger. In general women are much better at that.

      Design is communication, regardless of its medium. Master its many objects, tools, and methods but even more so its many channels.

      In the process, in design in general, in each individual’s goals and means of accomplishing them, there is no fact. Fact is a myth. As is perfection. People differ. And there are always just-as-good alternatives. Rigidity of approach or solution will lead to missed opportunities and lost insight. Fact oppresses more than it empowers. Be wary of its promises.

      In the case of LL Bean, sales are likely boosted by multiple overlapping taxonomic systems in the same horizontal menu. Understanding the differences between individual psychologies is likely the key to employing such a device, as not all users are left-brain, ‘one category to rule them’ men. Some are shoe-wearing women. And their browsing patterns are more important than your, just the lowly designer’s, skewed understanding and mental model. IA cannot be devoid of UX, as information, no matter the architecture, is really only data if not aesthetically usable.

      When creating rigid systems like ““Footwear → For Men” and “Men → Footwear””, then, try to take the other perspective. Analyze your discourse – it holds power over you.

      Along that same vein, common sense is as mythical as fact – it really isn’t held in common. It changes from person to person, from demographic to demographic, hence personas. And it can be educated, just like Donald Norman’s Visceral > Behavioral > Reflective emotional design, and educated uniquely. Listening to the many voices of the voiceless your ‘common sense fact’ oppresses will make you a much better designer. Diversity is a gift.

      May we all be existential connoisseurs.

      0
      • 20

        Anastasios Karafillis

        December 13, 2013 10:42 am

        Hi Jason,

        I would like to preface my response by saying that your comment is no less an enrichment of this comment section than any other comment, whether they were favorable of this article or not.

        Now, if you will, embark on a philosophical journey to the depths of the digital era and how it changed human behavior.

        Before this era we call the digital era, when humans went to a restaurant and studied the menu, they would find that every meal was listed only once. The designers of the menu may have done this for two reasons: They could have feared that listing the same meal twice would confuse their guests as to whether the two meals were the same. And second, they would have to print more pages. Interestingly enough, neither men nor women complained.

        Then, in the digital era, listing an item more than once became as easy as copy/pasting it onto a new page. This power has often led designers to add more data than is necessary for users to accomplish their tasks. A phenomenon that many philosophers would discuss with the seemingly paradoxical premise that less can be more…

        But then again, the digital era also brought empowerment. Before the digital era, when humans walked into a department store, the store map, equally, would list all items only once. Womens shoes on the first floor, Mens shoes on the second. Then, when the women went to the first floor, they would find that the shoes were sorted only by size. If they were interested in a certain brand, fabric, pattern, … they would have to pick up and examine the shoes, one by one. A painstaking endeavor, at times.

        But then, in the digital era, it all changed. The designers gave the women a tool they called “dynamic filters”. The women quickly selected exactly the values they envisioned, and a sea of 20.000 shoes made way for a handful of desired items. Finding the needle in a hay stack never was so comfortable and swift.

        And so, correctly balancing power and simplicity became the key to a successful digital interface and the premise of this article.

        0
    • 21

      Anastasios Karafillis

      December 13, 2013 1:02 am

      Hi Tim,

      the scenario you mention that users want to plan their entire day, and not just to quickly pick a low fat breakfast, is a very good one but I would argue that the dish type actually helps in this regard.

      If users choose “low fat” first and they are still faced with thousands of recipes, how would they proceed from there? Obviously, additional filters would come in handy, in which case I suggested the dish type. This would structure their research in a meaningful way. They could first focus on low fat breakfasts, then low fat appetizers, desserts, salads, etc …

      In addition, I do not see too much of a problem as to the e-commerce scenario. It is easy to miss a recipe if users have 2000 recipes thrown at them at once but it is unlikely they will leave the site or miss a recipe just because it is structured into dish types. Instead, if they like the content, they would think “They have great low fat breakfast recipes. Now, lets take a look at their low fat desserts next.”

      Of course, whether users take the path “low fat > breakfast” or “breakfast > low fat”, it would be the same thing, so I suggested to remove one. I apply the same logic to clothes. Imagine the following conversation:

      “Do you want to see our shoes, shirts, pants, sweaters, etc … ?”
      “I don’t care as long as it is Nike.”
      “Well, here are our 10.000 Nike products”.
      “Um …, lets start off with your Nike shoes …”

      But if you feel this approach is too radical, you may want to take a hybrid approach, instead, as the first mainstream site I discuss in the article does. They offer the dish type to browse the recipes before anything else but if you scroll down a little, they also offer special interests, which are deemphasized compared to the more popular dish type but still easily accessible for those who are interested.

      Of course, if the site amasses thousands of healthy recipes, at some point, they would have to consider adding the dish type as an additional filter on the second level as well.

      Does this address your point or did you mean something else? If so, feel free to point it out.

      Anyway, thanks for the comment.

      0
      • 22

        I would argue that selection of Diet: “Low Fat” is a perfect example for browsable facets. You can avoid duplicate paths by separating menu from taxonomy in your IA and allowing for user to directly select “Low Fat” with the same exact value in your metadata as she would when she filters by “Low Fat” in, for example, “Dinner.”

        As another example, Diet: “Diabetic” might illustrate this need better. A diabetic might want to see only those meals that have a low carbohydrate count.

        That way, he could skip the deep fried Twinkies and skip to the vegetables. His primary concern is his diet, not the meal. He might be planning all his meals for the day. Also, the distinction between lunch and dinner can be murky.

        0
  8. 23

    It is funny how comments are left on the “fact” that author took some comments personally and was rude when it is really a shame that comments are being written on wrong assumptions like they were facts in a first place. My first reaction to Geert-Jan Brits’s comment was that Geert-Jan Brits managed to take the whole article very personally and authors reaction seemed to be very constructive and respectful to Geert-Jan Brits. See what I did? I presented my personal opinion as personal opinion and not a fact.

    Like author, Anastasios Karafillis, mentioned comment sections is a great place for constructive criticism for the purpose of providing as accurate and correct advice as possible. And for author of article to respond to comments like he did makes me want to read this blog more then ever.

    Great article. Thanks.

    0
  9. 24

    Thanks for the article Anastasios, very interesting reading. Well done.

    From my perspective (Colbenson.com where we work on findability mostly for style and fashion for stores like zara, mango or adoreme ), I believe Search shall share a balanced and unified level with navigation.

    If we see Search and Navigation as non-connected aspects of Information Architecture then we making a common mistake.

    Don’t you think that defining an Information Architecture is more of a bottom up approach? The naming, order, position, graphical aid and depth of category nodes is dictated by user demand.

    Is all about empathy, about hitting names for categories and logic that dissolves with People’s intentions (whether they are driven by a desire or by a commitment).

    I believe we can’t set a “primary or sole mean of navigation”, and is not about navigating, nor about searching, is about either discovering or locating.

    Most online stores fail to deliver an experience that is optimized for these two types of intentions (discovering and locating).

    When you don’t know what you want you tend to click or navigate, but not necessarily on taxonomies, when you do know what you want then you demand a shortcut and search is then utilized. This is why as an average Site Search Conversion is 4 times Navigation Conversion (most stores don’t even know this). On mobile this is 7 times higher (on our experience).

    To be honest, I don’t like how the conversation goes and how is it that our industry continues to produce such poor non-emotionally driven user experiences. In the future all these samples will be seen as horrendous deliverables!

    The good thing is that everything is to be done ;)

    0
    • 25

      Anastasios Karafillis

      December 17, 2013 10:17 am

      Hi Angel,

      you might find the following link interesting in this regard:

      http://uxmag.com/contributors/tony-russell-rose

      What I meant with “not the primary or sole means of navigation” is that users would probably be put off if they found that the only way to navigate a site is to use a search box.

      Typically, when users arrive on a home or landing page, they first look for some sort of trigger words, such as product categories, which are usually accommodated in a traditional navigation menu. Only if the navigation menu fails them, they look for secondary means of navigation, such as search, site maps or A – Z indices.

      The reason I suggested search as a back-up solution is that it can be a tricky affair for both designers and users. Search relies heavily on a sophisticated metadata database, although I agree that there is no reason to separate the information architecture of the navigation menu from the search engine. However, in addition you would need clever algorithms to account for possible miscommunication between site and users. With search, users very much have to guess which query will get them closer to the desired items. By contrast, a traditional navigation menu readily presents only the available choices.

      I would compare a traditional navigation menu to menu in a restaurant while search would be like a waiter that asks “What can I get you?”. I would first give the guests a menu and if they cannot figure it out, I would send over a well-trained waitress to help them. Although, a waitress is easier to communicate with as she can easily give recommendations, explanations and follow up questions, which is not as easily done with a search box.

      Of course, if the users know the exact name of the item, both search and A – Z indices would work much better. An A – Z index is like a telephone book, which is easy to use because everybody knows how to navigate an alphabetical list while search is like calling an operator, who does all the work for you. In fact, search could be even better, as calling an operator may take longer and be a bit more expensive.

      Hope this helps.

      0
      • 26

        Thanks so much for your response Anastasios,

        Just to clarify:

        Is not one single intention landing on a page and requiring therefore Navigation or Search to find. There are various intentions that could be grouped in:

        a) Browser: Does not know. “Lets see what’s on”
        b) Committed: Knows. “I want this, or feel like that”

        Evidently one can be a Browser and then a Committed ;)

        Thanks too for pointing me out to Tony Russell’s posts. Didn’t know! ;)

        Best!

        am

        0
      • 27

        “This is why as an average Site Search Conversion is 4 times Navigation Conversion”

        That may be true, but it may reflect:

        1. The poor state of IA planning.
        2. The almost-magical power of bag-of-unigrams (keyword) search to cover many cases very well when the user has intent and the fact that a tolerable implementation is a well-understood commodity invented and tweaked since the 1960s.

        A search box has no scent in the absence of at least a partial unigram + autocomplete. It only works well when the user knows a few terms about what he wants. It works much less well for discovery or if the subject is difficult to describe for the searcher or has many synonyms. Sophistication can get around some of the synonym problem, but even Google struggles.

        There are some interesting blends, though. There’s auto-complete and its friends. Some sites show products and categories as well in that list. That works well to improve scent. Lots of people go straight for the search box, but in the context of faceted search the user is then free to combine a search with a category & facets.

        So it’s not either or. A user could type in a vague query like “camera,” and then select “Cameras > Digital Cameras.” Then he could select “Sony.” A robust IA doesn’t prevent the full use of all taxonomies from keyword search: Some IAs allow for “search within” within a category as well.

        0
  10. 28

    Hey Anastasios thanks for the cool article
    informative!

    Im eager for part II. I hope you are still doing it? Im learning a lot more about this area and the design aspects are things Im keen to learn a lot more about

    When will Part II come out?

    thanks
    j

    0
  11. 29

    It seems that are many views of organising information. I struggled with this tension for a long time. It forced me to take a step back and look into all the different ways of organising information. The result was an e-book that you can download for free. It is called “Organising Digital Information for Others”, http://www.pebbleroad.com/books/organizing-digital-information-for-others

    I try to make sense of the different types of organising information from ‘lists’ to ‘categories’ to ‘trees’ to ‘facets’. The use cases are similar to the ones presented in this article. The book may help to explain some of the arguments and counter arguments, eg about facets and the need for them to be mutually exclusive.

    I hope you find this resource useful.

    1
    • 30

      Jaimie Sirovich

      May 17, 2014 10:45 am

      This is a pretty nice introduction for the price of $0.00. I read (skimmed) it front to back and picked up some history and background I didn’t know. I’m unsure of a few little things:

      0. I know it’s sensible to split facets from categories & trees, but it’s worth observing that the category tree is more or less a special facet that happens to be infinitely hierarchical and capable of performing an opening move. Facets can be hierarchical as well, but it’s best to keep only 1 facet hierarchical because of the “split ends” problem. See http://www.uxmatters.com/mt/archives/2011/05/tweaking-your-facets-part-i-supporting-hierarchy-with-multiple-selection.php

      1. You say facets must be mutually exclusive. Nothing stops an inverted index from counting and presenting a similar or related list. You’ll find certain correlations between values in different facets that actually cause a problem when deselecting in multiple selection.

      2. The topic at hand here is which values should be permitted as an ‘opening move.’ This is an area that gets little treatment. We’re so used to the category mindset that we forget it might be useful to select certain facets in the absence of a category. The most obvious case is someone buying a gift for someone on a budget if she has no idea what to buy — but she has a budget of $50. You might want to add that to your handbook. My term for the facet that can behave like in this way is ‘browsable facet.’ I’m yet to find a better term, but James Kalbach calls everything that you can select first an ‘opening move,’ which I also like for a more generic terminology for the idea — including when a category is used.

      0
  12. 31

    The one thing I’m not clear on is how to decide why a category is crucial and why it isn’t. I see the explanation “important to all users” versus “important to some users” , and I understand the means by which to do this with common categories such as recipes, but what about more esoteric categories specific to a client? How might one build that up? Card sort? Thanks a ton!

    0
  13. 33

    I am grateful for your post. I would like to comment that the tariff of car insurance differs from one coverage to another, simply because there are so many different issues which bring about the overall cost. As an example, the brand name of the auto will have a large bearing on the price. A reliable aged family auto will have a more economical premium compared to a flashy fancy car.

    0
  14. 34

    What is the relationship between meta data, category and categories? I just feel confused the moment I translate them into Chinese.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top