Interface designers can often gain insight from past efforts to solve a problem. Imagine that I've been asked to design a new interface for some task, to replace an existing interface. I might find that my user population is a small group of experts who have only limited time to meet with me to talk about the new design effort. Design documents for the existing interface are nowhere to be found. Whatever the reasons for the lack of information, it's useful for several reasons to analyze the existing interface: it may improve my understanding of the task; it will have flaws and shortcomings to avoid in a future design; it may suggest partial solutions that I hadn't considered.

This kind of analysis is a staple of research and practice, and yet it is by no means easy to work backward from a finished artifact to the designer's rationale. (Describing the problem in this way puts us in the role of archaeologists doing field work on virtual artifacts, though usually in less dusty environments.) As an exercise, it's can be interesting to read cases of apparently (or actually) poor design in the real world and come up with possible rationales. Here's an example:

My brother recently had a stay in the hospital. His room was similar to most hospital rooms: it was boring, even just to visit. The only real entertainment was a television in the corner. The problem was that the remote control that the hospital supplied left much to be desired. This remote had a single button to change the channels. When the television was turned on, it was tuned to the lowest channel. Each time you pressed the button, the channel would go up to the next one. When the last channel was reached, pressing the button would turn the television off. Fortunately we were able to locate an aftermarket remote that worked with the television and didn't cost that much. But whoever designed the remote seemed not to consider the convenience of the patient. The little money they saved came at a high price of frustration to a patient who should be taking life easy.

This case turns out to be hard to analyze, even informally, partly because it's hard to conceive of a more ludicrous design. What could the designer have been thinking? Eventually, however, it's possible to think of explanations that are not completely implausible. The device might have been targeted at patients with very little mobility, for whom pressing more than a single button is beyond their capabilities. The device might allow a caretaker to change channels for a patient as quickly and with as little fuss as possible. Leaving interface considerations aside, the device might have been much cheaper to manufacture than a more capable one. None of these explanations is especially good. What makes the exercise worthwhile, though, is that it requires thinking about various factors that make a design appropriate or not: who exactly the users are, the environment in which they work, external constraints on design, and so forth.

Other real-world design cases suggest issues more directly relevant to human-computer interaction, including design tradeoffs and the role of context. From my repository of design cases submitted by students come the following two examples:

I have noticed that every time I go to the drive-through ATM machine at my bank, I have to get out of the car to operate the computer. If I pull up to closely, (which apparently many people do, judging by the multi-colored paint smears), I too will leave a paint sample of my car behind. To me this is not a user friendly system. If I choose to pull up, and not get out of my car, I will have to take my seatbelt off and open the door half way to reach the controls.

There is a women's restroom on the first floor of Mann Hall. The two stalls are extremely small and the doors swings inward toward the toilets instead of outward. The designer should have considered the fact that the users of this bathroom were going to primarily be female students with purses and bookbags on their backs. The way the doors open makes it even more difficult to maneuver in these tiny stalls!

It is easy to see the importance of spatial tradeoffs in both examples. Restrooms are necessary but not "productive" areas in university buildings, and will be allocated much less space than classrooms. Drive-up banking machines similary take up space that might instead by allocated to parking or even to a larger building. Tradeoffs also can be seen in accessibility and cost. These tradeoffs have analogs in interface design: How much space and prominence should this particular piece of information receive? Will the graphical interaction also support screen readers for the visually impaired? Will this interface be usable on a mobile device? Will it be more cost effective to use off-the-shelf interaction components, or should a specialized look and feel be developed?

We can also see the importance of task context in these examples. If you are driving a car through a narrow lane while putting away a bank card, or shifting a backpack from one shoulder to another while trying to close a door, you are trying to do two things at once. The result is sometimes a costly error. It's again easy to see analogs in interface design. A travel planning system on a desktop machine is unlikely to be as effective when encountered in the navigation system of a car or in a subway station. Voice input will be less useful for interacting with bank machines, in voting booths, or in a crowded office. If a user interface is designed in a way that initially seems unintuitive, it may be that the designer had in mind a different set of tasks than the interface is used for.