Efficiently Simplifying Navigation, Part 1: Information Architecture


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 map
A site map diagram gives an overview of the navigation structure of a website. (Image: Web Tuts)

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.

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

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.

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

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.

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

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.

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

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.

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

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.”

Optional Categories

If multiple crucial categories exist, then the number of items might not necessitate their inclusion. If a website has no more than a dozen clothing items, then the designer could simply have users choose whether to see all clothes for men or women and be done with it.

In many cases, though, the opposite happens. Even after all crucial categories have been exhausted, an abundance of items might still be left. So, additional categories would have to be introduced to allow users to further filter the content. This is where optional categories come into play.

Optional categories are important to some but not all users. For example, two meta data categories for “cars” could be “number of doors” and “fuel type.” Some people are fanatical about fuel type and couldn’t care less about the number of doors. Others feel exactly the opposite.

Prioritizing Crucial Over Optional Categories

As a rule, optional categories should be presented after users have gone through the crucial categories.

However, many retail websites, such as for fashion and electronics, list brands (an optional category) on the same level as the type of product (a crucial category).

Crucial and optional categories should be shown on separate levels. (Image: Flipkart)

The problem with this approach is that if users select a brand on, say, a clothing website, they could be faced with hundreds or thousands of items, and they would still have to choose a type of clothing in order to narrow down the content. So, placing optional categories on the same level as crucial categories creates redundant paths, increases the complexity of choice and clutters the navigation.

Offering many filters is not bad. But rather than give users many navigational options at once from the outset, present them with a few crucial options first, and then, once they’ve exhausted those, introduce optional values.

Thus, in the example above, removing the brands from this level and having users select only a type of clothing first would be better. Then, on the next level, give users the option to select a brand.

Optional values should be presented only after users have selected crucial values. (Image: Flipkart)

Dynamic Filters

As mentioned, crucial categories should be presented one by one on succeeding levels. Optional categories are best offered all on the same level.

The only exception is that if the optional categories are mutually exclusive, then they should be shown on the next level in the same menu as the crucial categories. If the optional categories will likely be combined, however, then they should be implemented as dynamic filters.

In the screenshot below, notice how Sears lists crucial categories in the breadcrumb trail, while optional categories are implemented as dynamic filters.

Optional categories that are likely to be combined should be implemented as dynamic filters. (Image: Sears)

This distinction between crucial and optional categories can be explained as follows. Every category is a filter to the available content, while dynamic filters are dynamic because they enable users to select and change multiple values on the fly. In contrast, in a traditional, levels-based navigation system, the user would have to move from one level to the next to select a value. If the categories are crucial, then this would not be a problem, as illustrated above. But with optional categories, the situation is different.

When a user is looking for a shirt, many optional meta data categories can play a role: “brand,” “collar type,” “sleeve length,” “fabric,” “pattern,” “pockets,” “discount,” “price,” “rating,” “popularity” and so on. Knowing exactly which of these many categories a given user would be interested in is difficult. Someone could be interested in none, a few or all of them.

Rather than send users through all of the optional categories, one after another, regardless of whether they are interested in them, the designer could provide a list of dynamic, optional filters on the same level. Thus, users would be able to select only the categories they like.

In contrast, consider the website shown below, which does not distinguish as clearly between crucial and optional categories. Instead, it implements all categories as dynamic filters, including crucial categories.

Crucial categories should not be implemented as dynamic filters. (Image: Nike)

This lack of distinction leads to a couple of problems. First, it takes up vertical space and pushes the other optional filters down, requiring the user to scroll more frequently to view and alter the values.

Secondly, a dynamic filter is known as a “heavy metal” widget: It’s powerful but a hog on resources. Whenever a user selects a single value, the list of results is refreshed to match. This makes sense for providing feedback, but it does not make the interaction any faster. The same result could be achieved much more quickly simply by having users select the same crucial values from a traditional menu.

In fact, Nike’s designers do provide such a menu, allowing us to test this assumption and to compare the speed and efficiency of both interaction models within the same interface.

Crucial categories are best implemented in a traditional navigation menu. (Image: Nike)

Mutually Exclusive Categories

Dynamic filters are necessary only if the optional categories are likely to be combined. If the optional categories are mutually exclusive, then they should be implemented on the next level in the main navigation menu.

In the screenshot below, the Daily Express asks users a crucial question on the first level: to pick a topic of news, such as “finance,” “entertainment” or “lifestyle.” Then, on the main page of a selected section, users are given a digest of the latest news on that topic. Checking the three or four latest articles is all many users want to do. For those who want to delve into a particular topic, subsections are listed below the first level.

Mutually exclusive optional categories are best implemented as an additional level in the main navigation menu. (Image: Daily Express)

The subsections above can be regarded as mutually exclusive because an entertainment project is usually released either as a book or as a film or as a TV show, etc. Of course, combinations are possible; a book could be made into a movie or a stage play. But would users likely want to see a digest that matches these combinations? If so, then dynamic filters make sense.

Be aware that the answer to this question will depend less on the type of items than on the volume and diversity of items, as well as the particular interests of the target audience.

For example, users would probably not look for a breakfast recipe that is Chinese and low fat and Christmas-themed. Rather, they would look for a breakfast that is either Chinese or low fat or Christmas-themed. So, optional recipe categories are unlikely to be combined in general. However, if a website has thousands of recipes and the targeted audience has very particular preferences, then giving them the more powerful dynamic filters would be helpful.

A large and diverse amount of content as well as particular user interests could warrant dynamic filters. (Image: Food52)

Finally, consider a third group of meta data categories.

Irrelevant Categories

Irrelevant categories are categories by which no targeted user would likely want to browse the content. However, these categories are not irrelevant to the overall user experience.

Two meta data categories for a collection of articles could be “word count” and “image count.” If these categories were implemented as columns in a database, a content strategist could examine the values in these categories and conclude that most articles are too long and lack images, which could be a reason why many users abandon the website before they finish reading the articles. The content strategist could then discuss this matter with the designer or client, which could lead to improved content. Yet, while these categories might yield valuable information for the designer, users would likely not want to browse the articles by “word count” or “image count.”

In short, irrelevant categories should not appear on the website. They would be ignored, would clutter the interface and might even confuse users. The sheer volume of items, though, could turn an irrelevant category into an optional one.

For example, “word count” would usually be an irrelevant category by which to browse articles. But the website shown below has amassed so many articles over the years that the designers thought it necessary to add article length as an optional way for users to filter the content.

Sheer volume could turn an irrelevant meta data category into an optional one. (Image: Time)

The websites above that showcase recipes or apparel are suitable for explaining the subtleties and importance of prioritizing categories, because they typically require many meta data categories. But they do not illustrate one problem that most designers have to face at some point, especially when designing for a corporation.

Corporate Product Categorization

Most recipe websites collect recipes indiscriminately and then leave it to the designer to categorize them. But corporations often have their own internal way of categorizing products. This can lead to conflicting needs.

Consider first a crucial meta data category for cars. You would have a category based on size or lifestyle, with values such as “compact,” “wagon,” “sports car,” “sedan,” “limousine” and so on. This category is crucial because every type of car caters to a particular lifestyle, one that is important to almost everyone who drives a car. A compact, for instance, is small, cheap, easy to drive and easy to park in the city. A wagon has a lot of trunk space, well suited to families. A sports car caters to another distinct lifestyle. And so on.

Yet, many car companies categorize their models in their own way. BMW, pictured below, follows a number-based classification scheme (1, 3, 5, 7, etc.).

Sometimes, a corporation’s categorization works well. (Image: BMW)

While a corporation’s internal classification schemes can cause usability problems, BMW’s scheme actually makes the information architecture more usable. Despite being corporate, the scheme is quite well known to the general public, and the numbers progress logically according to car size, more or less in line with the common scheme of classifying cars as compacts, sedans, limousines, etc. In this case, anything other than the corporation’s categorization might alienate, rather than help, users.

This next example is not as straightforward. Opel likewise lists its car models according to its own internal naming convention.

Internal categorization is not always obvious to external users. (Image: Opel)

The problem is that the structure of this product line-up is not clear, and it is not made easier by the fact that users have to interact with a slider to see all of the models (although this problem relates more to interaction). Users have no easy way to understand how the products relate to each other and, thus, have no easy way to filter them according to preference.

If the categorization scheme does not work well for users, then a familiar external one must take precedence over the internal one.

Notice how Volkswagen (below) has its own way of naming and categorizing car models: “Jetta,” “Passat,” “Touareg,” etc. But the company prioritizes a common external categorization scheme over its corporate one. The result is a menu that is easy to understand and that enables users to focus on the part of the line-up that they’re interested in.

Prioritizing a common categorization scheme over a corporate one can make a navigation menu easier to understand. (Image: Volkswagen)

Of course, a client might not like to see their corporate classification scheme relegated to second place. However, as the information architect who has been hired to make the content on the website easily accessible, you are responsible to communicate this necessity to the client.

Explaining Navigation Options

Structuring the navigation options according to user preference is an important step in simplifying the information architecture of a website. But if users cannot understand their options in the first place, then even the most sophisticated structure will be in vain. So, take a moment to consider how best to explain the navigation options.

Give users only as much information as they need to understand their options. Anything more risks tiring them, cluttering the interface and slowing navigation, even to the point of abandonment.

Don’t give them too little information either. If users have to guess where links point to and then are disappointed by where they end up, they will soon lose confidence in the interface and leave the website.

Designers can choose from three methods to explain navigation options:

  1. labels;
  2. labels and pictures;
  3. labels, pictures and descriptions.

To choose the right method, assess how familiar the labels are to the target audience.


If the labels you would use are very familiar, then they alone will suffice. Large pictures and long descriptions are not necessary to explain what “jeans,” “shorts,” “shirts” and “jackets” are.

Labels suffice for familiar items. (Image: Rock Revival)

While keeping labels short is commendable, brevity should not be achieved at the cost of clarity. Acronyms and jargon, such as UX and BMI (body mass index), could work as long as the target audience is familiar and comfortable with them.

Sometimes, though, a term alone may be clear but the context in which it appears makes it ambiguous. Many websites of large organizations contain persistent horizontal navigation that points to aspects of the organization’s main work as well as context-sensitive vertical navigation that points to sub-departments. This can lead to duplicate labels. The University of Bath (pictured below), includes the label “Research” in the global horizontal menu at the top and in the narrower vertical menu on the left.

duplicate labels
Large organizations with many sub-departments are prone to duplicate labels. (Image: University of Bath)

While this could confuse users, careful design will avoid ambiguity. In the screenshot above, the menu heading “Explore the Department” is a good hint that the “Research” label below it refers to the department, not to the university as a whole. To be absolutely sure, we could lengthen the label from “About Us” to, say, “About This Department.”

Another way to give labels context is by adding numbers that indicate how many items are in a given category.

In some menus, the number of items in a category is displayed with the label. (Image: BJ’s)

These numbers are frequently included as values in dynamic filters.

In many interfaces with dynamic filters, the number of items in a category is displayed with the value. (Image: eBay)

While many users like seeing such figures, consider carefully when to actually show them. For instance, guessing how much content a website has just by looking at the home page is usually difficult. So, explicitly showing how much it has could win over users, because they would think, “Surely, this website has something for me.”

Quantifying the volume of content on the home page can persuade users. (Image: O’Reilly)

Of course, you probably wouldn’t want to disclose such a figure if your website does not have much content yet.

Likewise, when a user is browsing categories and is interested in a certain topic, they will want to explore the relevant category even if it has few items and even if another, less relevant category contains more items. If anything, displaying numbers at this point would slow down the browsing and clutter the interface.

In certain situations, statistics can impede users. (Image: Digistore, Ministry of Education, New Zealand)

The same goes for dynamic filters. Would users select a category according to the number of items it contains? If so, then displaying the numbers makes sense. If not, then the only kind of feedback you should give is to gray out or remove values that have zero items.

Otherwise, once users have selected a category, displaying the number of items in that category or, in the case of dynamic filters, displaying the number of items that match the selected values is useful information.

Icons are another type of element that is sometimes appended to labels. When well crafted and recognizable, they can be a very useful addition. While not necessary to explain the user’s options, icons makes it easier to process and distinguish between the options. In the screenshot below, I’ve removed the icons from the menu entries. Notice how the labels are still enough to explain the options. Everyone knows what “cars,” “motor homes,” “motorcycles” and “trucks” are.

Labels alone very often suffice but take longer to process.

However, putting icons next to labels makes it easier for the user to recognize and distinguish between the options.

Icons make it easier to process and distinguish between options. (Image: Mobile.de)

Icons alone can cause confusion, though. Even if an icon is familiar, users might be uncertain about what it represents in a particular context.

Labels And Pictures

Labels and icons work well for familiar items. For less common ones, images are required. Consider brand names. In the screenshot below, car models are represented as plain text in the menu.

Brand names require more than just labels to be understood. (Image: Subaru)

However, I don’t know what a “Tribeca” or “Legacy” is. So, the labels are not enough to help me decide which product to explore. Labels with pictures, as shown below, are a better solution.

Labels and pictures are a better way to explain unfamiliar terms. (Image: Mazda)

When to use pictures or icons in navigation menus is an interesting question. Obviously, to explain a very specific item, such as “13-inch Macbook Pro” or “Samsung Galaxy Note 3,” nothing but an actual picture of the product will do.

Explaining a product category is not as simple. In some menus, the categories are explained with icons.

In some menus, icons are used to explain categories. (Image: Flipkart)

In other menus, those same categories are explained with pictures of actual products in those categories.

In some menus, pictures of actual products are used to explain the categories. (Image: Target)

For product categories, icons are more appropriate than pictures. A well-drawn icon makes a menu look much more professional than a recycled picture of a product.

Also, using a picture of an actual product to represent a category could raise questions among users, subconsciously. “Why does this particular product represent this category?” “Is this the best they have?” “Does the range of products center on this particular kind of item?” “If I am not looking for this kind of item, then is this not a good website for me?” These apprehensions would be reinforced if the first items they see in a category are very similar to the one they saw in the menu. An icon, by contrast, simply communicates that a category contains a certain kind of product, nothing more, nothing less.

The trick with icons, though, is that they have to be of a certain standard. An icon can easily look amateurish if not drawn well. And if it is not readily recognizable, it could even confuse users. So, while icons are better suited for product categories, if you’re not confident that you can make them professional and recognizable, then you’re better off with pictures.

Labels And Pictures And Descriptions

Sometimes, even labels and pictures are not enough to explain products. Service providers with complex solutions, such as banks, insurance brokers and ISPs, often give their products names like “50 Plus” and “Web on the Go.” A large picture of a married couple talking to a broker or a girl talking on her smartphone might not be enough to indicate the service being offered. For such products, a description of a couple of lines and a label and picture are most helpful.

Complicated products might require labels, pictures and descriptions to be understood. (Image: Naspa)

Headlines and titles of articles are a different kind of label that may or may not require accompanying images and descriptions.

Many authors suggest front-loading headlines with key information and keeping them as short as possible.

A common recommendation is to keep headlines short and to front-load them with key information. (Image: BBC)

While the headlines above are short and to the point, this style of writing has its risks and is not appropriate for every website.

The first question is whether and how to write descriptions. The BBC’s headlines are actually accompanied by descriptions, but I removed them in the picture above to isolate the headlines. The shot below restores the descriptions, which you’ll notice are basically verbose rewordings of the headlines, without substantially new information.

Descriptions should contain information not already conveyed by the headlines. (Image: BBC)

If headlines are supposed to be packed with key information, as they are above, then descriptions would not be required. If anything, users would be slowed down by reading them because they could just as well have navigated to an article after reading only the headline.

However, showing headlines alone or writing headlines in that style is not always best or even advisable. If an article is merely a short news report about an event, then a headline such as the BBC’s is a good choice. But if an article goes into more detail, then a headline, picture and description could be more effective and engaging.

The headline in the screenshot below is more catchy than informative, while the key information is delivered in the couple of lines below. Also, a picture has been added to set the tone of the article.

Labels, pictures and descriptions are often the best way to explain in-depth news articles. (Image: World)

Understanding what this article is about from the snippet is not hard. Moreover, by using the headline as an efficient attention-grabber and the descriptions to explain the article and the picture to set the tone, the entire snippet gives the author much more room not only to inform the user but also to convey the perspective of the article.

Finally, consider advice often given about headlines, which is to write them so that they are easy to understand outside of the context of the website. After all, a headline can appear in search engine results, in social media and in other articles. Some authors even go so far as to devise formulas for this purpose.

Many authors try to write headlines that are understandable beyond the original website. (Image: Baymard Institute)

Just be careful not to create redundant information when adding context to a headline.

The headline pictured above does not provide enough context because the website is about Web design, and multi-column layouts could play a role in home pages, menus, articles and more, not just in forms. So, “Form Field Usability” primarily adds context within the original website. Writing for outside context is not always necessary, though, because other people who refer to the headline will be eager to provide their own context.

Search engine developers know that users will eventually abandon them if search results do not meet the users’ expectations. So, they constantly work on increasing the relevance and success rate of their results, whether by adding rich snippets, pictures or previews or simply by improving their algorithms — that is, by adding context. Likewise, if a headline were to appear in the “recommended reading” section of another article, that article would provide the necessary context. Finally, in social media, a headline shared by a person or brand that someone follows is unlikely to be seen as ambiguous.

In Sum

Information architecture — that is, the structure and labeling of content — is the foundation of usable navigation. Designers can efficiently simplify a website’s information architecture by structuring content in a way that naturally narrows and supplements the navigation options of the target audience, as well as by explaining those options in a way that minimizes the cognitive load on users.

The recommendations given in this article can be summarized by the following two lists, broken down into “structuring content” and “labeling items.”

Structuring Content

  1. Collect and categorize meta data about the type of items you want users to navigate to.
  2. Group the meta data categories as crucial, optional or irrelevant. Crucial categories are important to all, optional categories are important to some, and irrelevant categories are important to no targeted users.
  3. Present only a single crucial category, with its values, on the first level.
  4. If the items on the second level do not exceed a certain amount, then additional categories are not necessary. Otherwise, offer the next crucial category, one by one, on each subsequent level.
  5. After exhausting all crucial categories, present a page that lists all items that match the user’s selection to that point.
  6. If the remaining items still exceed a certain amount, then present optional categories all on the same level.
  7. If the optional categories are mutually exclusive, implement them on an additional level. If the optional categories are likely to be combined, implement them as dynamic filters.

Labeling Items

  • If the label for an item is familiar, it will suffice by itself. Keep labels as short as possible, without sacrificing clarity. Present the total number of items on the home page and on the category page, but not in between. Consider icons, too, which make it easier to process and distinguish between the options.
  • If the labels are not familiar, consider adding pictures. Use icons to explain categories, but only if the icons are well drawn and recognizable. Otherwise, use pictures.
  • For complicated services and products, consider adding pictures and descriptions to the labels. The descriptions should provide genuinely new information and not just reword the labels. Also, be careful not to create redundant information when adding context to a headline.

Once you’ve simplified the architecture, users should be able to interact with the choices to their satisfaction. Thus, you will also have to design a navigation menu that accommodates the choices and that makes the interaction comfortable. The process of designing navigation menus will be discussed in part two of this series.

Further Reading

You might be interested in the following resources:

(al, il)

↑ Back to top

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.

  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.


    • 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:


      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:


      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.

      • 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.

  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.

    • 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:


      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:


      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.

  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.

    • 7

      @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.

      • 8

        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?

    • 9

      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.

    • 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?

    • 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?

  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.

    • 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.

  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.

    • 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.

      • 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.

  6. 17

    Interesting food for thought. Thanks for the article

  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.

    • 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.

      • 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.

    • 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.

      • 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.

  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.

  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 ;)

    • 25

      Anastasios Karafillis

      December 17, 2013 10:17 am

      Hi Angel,

      you might find the following link interesting in this regard:


      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.

      • 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! ;)



      • 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.

  10. 28

    Hey Anastasios thanks for the cool article

    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?



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