I recently spent a day in Venice, wandering through the streets, admiring the buildings, canals, and bridges. Lacking a strong sense of direction, I was never entirely sure where I was. A guide book told me that this effect is deliberate: the curving streets and unexpected crossings were at least partly intended to confuse invading forces.

There are obvious parallels to navigation issues in user interface design. (This occurred to me only afterwards; I am not single-minded enough to have been thinking about user interfaces while following the signs between the Rialto bridge and San Marco.) It's become a commonplace that interfaces should let users know, at all times, where they are, where they've been, where they can go, and how they can get there. Lacking good cues for this information, an interface becomes difficult to navigate.

It's easy to find examples of poor support for navigation in the real world. What's interesting about them is how different aspects of design can combine to make navigation hard.

In some connected buildings on campus, the floors do not match up. For example, to get from the second floor of Caldwell to the second floor of Winston, you must take the stairs or the elevator rather than simply walking straight ahead--if you did, suddenly you'd be no longer on the second floor of one building but on the first floor of another. Even if the buildings were built at different times, the floor levels still could have been matched up. Finding rooms can be hard for people who haven't visited the buildings before.

Independently, each of these two buildings may follow a logical internal structure, but their combination leads to problems. Here's a related user interface story, somewhat artificial but not implausible. Imagine a database program that allows you to add, delete, copy, or modify records. For copying, the application brings up a window showing the fields of the record so that you know what's being copied; for deletion, the application shows a similar window so that you can verify that the correct record is being removed. Following Windows conventions, copying might be activated by a Control-C, deletion by Control-X. Now suppose that your finger slips and you press the X instead of the neighboring C key. If the windows for copying and deletion are very similar, it may not be obvious that you've selected the wrong operation until after you've already press "OK". A mistyped command is no excuse for the designer, because it can be expected to happen once in a while, just as someone may occasionally walk through the wrong door or down the wrong hall in a building.

I recently returned to the U.S. from Europe, arriving at the airport in Raleigh-Durham. I hate waiting, so I'd traveled with only carry-on luggage. I'd expected to go through immigration, then through customs, and then out the door to the parking garage. Unfortunately, you can't leave the international gates without going through the rest of the terminal, and since 9/11, that means you have to go through another security checkpoint. So after customs I had to wait in line with everyone catching a connecting flight, walk through the metal detectors, and then fight my way through the crowd of people re-checking their luggage, all just to leave. (And why do passengers arriving from Europe need yet another security check?)

In this example we see the problem of two groups of people with different goals going through the same procedure, one that is much less efficient for some of the people. I occasionally run into a related problem when I go online when I'm away from my office. In my office, I'm able to look through various online libraries without trouble; my access is authenticated by the network I'm on. If I'm working at a coffee shop, however, these same libraries ask me for user names and passwords that I can only figure out with difficulty, because I ordinarily don't have to deal with them directly. In other words, I'm shunted off to an area where I have to prove my bona fides, even if they're irrelevant to my goals. This may be inevitable, but it makes for less efficient interaction.

At some fast food restaurants, there are two drive-thru windows. The first window takes your money and the second window gives you your food. The problem is that the windows can be too close together. Once you pay and pull up behind the person who is getting their food, there is not enough distance for the person behind you to pull up to the payment window. This causes a bottleneck at the food window. If the designers had put the two windows at least a half car length farther away from each other, three cars could be serviced instead of two. Also, people who have a large order wouldn't back up the line as much, and the person working the payment window would have less downtime during busy periods.

This example is more subtle in its relationship to navigation. The path is clear, in that people know where to go, and nothing prevents them from (eventually) reaching the end. However, it is slow going because there are other people involved and the system is not designed for the most efficient flow. We can see an analogy to bandwidth issues for online services. If a service is consistently overloaded, slowing response time to frustrating levels, users will simply go elsewhere for what they need.

For some interfaces, such as those for interactive games, Robert Louis Stevenson's observation can be appropriate: "To travel hopefully is better than to arrive" suggests in part that the experiences encountered on the way to a destination, including surprises, are what make a trip worthwhile. In most interfaces, however, especially for productivity applications, users will generally be happier if they simply get where they are going with as little time and fuss as possible.