We work with a lot of clients that are struggling with their navigation systems. Usually these are large, complex applications that have grown over time (with little or no planning). Therefore, the navigation system is also large and complex. When we’re asked to fix these systems, one of the first things I try to identify is whether we’re dealing with a widget problem, a ic problem in the navigation system or (shudder) both.

When you’re implementing a Navigation system, you have a lot of choices for the kind of widgets to use. A quick sampling:

  • Tabs
  • Tabs & Subtabs
  • Menubars
  • Menus on Tabs
  • Menus on Tabs & Subtabs
  • Left Side / Tabs
  • Left Side / Tree
  • Left Side / Stacked Tab

… and more of these are being created and used every day.┬áIn many navigation systems, these widgets are either poorly chosen or have been implemented poorly. An example:

NSBRI Web Site Navigation System

NSBRI Web Site Navigation System

The home page of the NSBRI web site offers the navigation system shown above. There are seven choices, each with its own unique color and icon. If you hover over any of these choices, a list of topics will appear:

NSBRI Web Site Navigation System (open)

NSBRI Web Site Navigation System (open)

Despite what you may think, you can’t actually click on any of the text that appears (Aerospace/Aviation, etc). In fact, the only things you can click on are the little colorful image/links. But my point isn’t to pick on this site’s design work, but rather to show an example of a broken widget. The widget in use here is just a series of links – it’s just that they have been presented in a way that makes them less usable – the links don’t have any actual text labels (well, they do – they all use the same text), the meaning of the icons is impossible to guess, and once you open up a “menu” it doesn’t act like a menu should.

But all of these are problems with the implementation of the navigation – the widget. They don’t actually say whether or not the items on the site have been properly grouped together. In other words, if we reworked this widget to be more understandable and predictable – imagine we did a perfect job of implementing the widget – would visitors be able to find the information they were looking for in the categories that are offered? If so, then the ic for the site is sound.

Let’s look at another example from something further toward the “web application” end of the spectrum.

Left side tree navigation for PeopleSoft

Left side tree navigation for PeopleSoft

This web application, created by PeopleSoft, allows users to manage their benefits. The tree on the left side is the main navigation system. The underlying ic – the information architecture – of the application is basically sound. However, the widget is problematic. To access a grand total of about 50 screens, there’s an enormous amount of nested folders, which means lots of lots of clicking. So to perform even simple tasks the user must click click click through the tree to pull up the right screen. There are much better widget choices for this. To find them, you might do wireframe mockups, some prototyping, and some usability testing of the alternate widgets.

A ic problem, on the other hand, is a basic mismatch between what the user wants to do and the organization of the screens themselves. In a ic problem the way that screens are organized is so utterly foreign that the user just cannot grasp them. Here’s a simple example:

My Lego Network has ic problems

My Lego Network has ic problems

My Lego Network is a play area for Lego lovers – children (mainly boys) between the ages of 6 and 12. The children create an account in which they build their own LEGO page, visit the LEGO pages of other players, add items to their inventory, and solve puzzles. The navigation system is a tab/subtab based system and the widget functions pretty well. But there’s a very basic problem: most children don’t know what a “Private View” and a “Public View” are. They don’t think of these screens in this way. Despite using this for hours, my son consistently clicks on the wrong things to get to the pages he needs to find. The information in the navigation system – the information architecture, if you will – isn’t working. That’s a ic problem. Fixing this problem doesn’t mean making changes to the tab/subtab widget – it means rethinking the organization. That’s a whole different process that might include card sorting exercises, mental models maps, prototypes of the different arrangements, and some usability testing of the alternate ic.

So, in summary, before you set out to fix a navigation system, it’s important to know whether you’re fixing widget problems or ic problems.

I’m curious: Does the widget/logic split make sense to you? Do you use other terms to describe this split? Do you think the structure of a web application and the information architecture of a web site are the same thing? Do you even draw a difference between a web site and a web application?