In Raiders of the Lost Ark, Indiana Jones stands in the map room of the lost city, holding a staff that will aim a beacon at the location of the buried lost ark. Armed with a critical piece of information unavailable to his "competitor," he realizes he must shorten his beacon staff by half. When the beacon shines on an obscure section of the city map, he discovers that his adversaries are "digging in the wrong spot."
I see a lot of designers digging in the wrong places. I see them focusing on design issues that enhance specific features but don't actually address the users' ultimate needs. I see them knowing how to design, but not always knowing what to design. I see them designing very wellthe wrong things.
Design for usability involves two kinds of skills, you see: not only designing solutions, but also redefining problems. Most of us start out by becoming skilled at designing solutions; some stop there. The difference doesn't seem to depend on experience, which is easier to rectify than lack of skill. I've seen some pretty skilled designers who, with more experience, will make significant advances in the usability of information technology. But I've also seen experienced designers produce good solutions to the wrong problems. These folks need to develop their skills at redefining the problem.
Redefining the problem lies between definition of requirements and design of the user interface. Unfortunately, knowing where to dig doesn't have a clever name, but I'll call it macro-design. You might think of it as more general than interaction design-and more specific than user requirements analysis. It's not just designing screens and pages; it is more about knowing what interaction or navigation metaphor works best for the task or problem. Although it addresses the problem at a lower level than user requirements specification does, it still includes rethinking the problem.
In one recent project of mine, the requirements were fairly clear about what the software would do. (I still did some user observation to understand the user's perspective.) One key requirement was to make it "user friendly." The original designers thought, "Well, what could be more user-friendly than a wizard?" However, the program and user tasks lent themselves more to a progressive disclosure (dialog-driven) interaction than to a wizard. Therefore, the resulting wizard acted more like a dialog-driven product. In certain cases, the users actually had to hit the "back" button to go forward. And in other cases, the "back" and "next" buttons did the same thing. These designers could have used more macro-design skills.
These designers had no clue where to dig, but they dug a deep hole anyway. Unfortunately, they don't know what skill was missing from their design effort. When I suggested that the wizard was inappropriate and that the task lent itself to a different interaction design, one of the designers actually asked me if we couldn't just fix the wizard.
That doesn't mean it's right. In the tech industry, for example, so many people are designing the wrong things that these things tend to become de facto standards.
For instance, a common micro-design effort in database products involves refining the report generator interface to make it easy for users to create a report. The problem is that getting a report is not the user's goal. The report is typically a remnant of the limitations of legacy technologies, but it is almost a de facto design standard.
A macro-design approach understands that a report is not the desired result. Lacking context, reports are only a step in the direction towards answering the real questions. Users will do something with the report, which in and of itself has little meaning. The macro-design skill lies in determining what the users should do with the data in the report and in designing for that result.
The macro-skilled designer looks beyond the report to deliver answers that the users need to guide their behavior and actions. When they work with data, users are typically looking for two things: trends and exceptions. To be meaningful, these require contexta relationship with other data. Typically, reports contain rows and columns of numbers that lack context. Data is defined as the numbers, information is the relationship between the numbers, and knowledge is the relationship of that information to the external world.
For instance, if you give the user a piece of data, such as 95, it has no meaning. Tell them 95 is the temperature, and it means more but still not enough. Tell them, however, that chicken must be cooked to 140 degrees and theirs is only at 95, and they have knowledge on which they can act. So when I see someone focusing on a database's report generator, I know they're digging in the wrong spot.
I like to classify knowledge into three types:
- What we know we know: the knowledge we use every day. It forms the basis of our decisions and actions. Good design depends on taking advantage of what users know.
- What we know we don't know: We know that heart surgery happens, but we don't know how to do it ourselves. This is the first stage of awareness.
- What we don't know we don't know: This is where most businesses are with respect to usability awareness. Though they have heard terms like "usability" and "user experience design," many have no idea that there is a process dedicated to designing products from the users' perspectives.
So how do you move from not knowing what you don't know to becoming aware of what you don't know? By thinking about the what before the how. When you see a problem, think about what the user will need to accomplish, and work backwards to see what it takes to get there from where you already are.
For instance, in the "wizard" project I described earlier, I was asked to avoid (as much as possible) any changes to the existing screens. This forced me to focus on the navigation. Since these users were highly skilled workers, comfortable with technology and performing these tasks on a fairly regular basis, I considered what the result might look like for them and then contemplated how they would get there.
As it turned out, the users saw their tasks in two parts: preparation and results. So I divided the screens into two groups: preparing the task and looking at the results. Interestingly, the original wizard treated these two steps as a single process, requiring the users to wade through preparing the task again, each time they wanted to look at the results. No matter how well they designed the wizard, it was still going to be the wrong design!
The discovery that the task was two steps enabled me to arrange the screens for each step. The notion of a progressive disclosure design quickly followed, and the navigation became almost self-evident. I had only to add two screens, and even then I used objects that already existed in various parts of the original design. I just moved them to a single screen where it made more sense.
My clients often tell me that I won the bid because I was able to describe their problems in clearer terms than they themselves could. An important feature of macro-design skills is the ability to abstract the problem from the scant information most clients provide in their user requirements.
"Ladies and gentlemen, we just learned that our navigation system blew a fuse about an hour ago. We don't know where we are or where we're headed, but there's a good tailwind and we're making excellent time."
Does this sound like some of your design projects? Then you might be digging in the wrong spots. Without a navigation map, you won't know if your screen designs fit the users' task flow.
So how do you learn to dig in the right spot? First, learn to recognize that you are in the wrong spot. If you keep running into design issues that require changes in your design approach, you are probably trying to force-fit the tasks to your design concept, and that would be the wrong spot. Typically, macro-level design has more to do with metaphors and organization as revealed in a navigational structure.
In the infamous "wizard" project, the user's tasks include testing an object called a plate. The software allows the user to prepare and run tests and to review the results. The original design focused on the plates, requiring the users to select plates and then set up the test to run. But the users see the tests as primary and the plates as incidental. The original design was like telling a printer to use paper and ink instead of telling it to print my document.
Let's try a macro-design of the plate-testing task. Using one color of sticky note for the task steps and another for the objects used in the task, create a high-level task flow diagram. Capture the beginning and end of the process, the task trigger and the desired outcome. (Ignore intermediate results such as reports.) (See figure 1.)
Then work backwards from the end result toward the trigger that starts the task. Identify the objects and actions that are necessary to achieve the succeeding step. Don't be surprised if you discover new objects, actions, or task requirements. This is what differentiates this bottom-up approach from a traditional, top-down, task flow methodology. (See figure 2.)
Complete the task flow around these key objects. See if you can identify a task metaphor that would lend itself to a navigational structure and organization around the key objects. (See figure 3.)
This exercise illustrates the importance of identifying the objects on which the users focus, and it shows how this leads to a more appropriate task metaphor: tests, not plates. My redesign effort reorganized the task flow around the tests and their results.
Probably the best example of folks digging in the wrong spot is all those clever but unsuccessful ways we've long had of setting the time on a VCR. Setting the time enabled us to use the VCR's advanced features, such as automatically recording a show. The interface designs failed because everyone was solving the wrong problem. The real problem is simply to synchronize the VCR to the station. Time is just an arbitrary metric.
Once the problem was restated as a synchronization problem, VCR manufacturers began including a chip that automatically picks up the time code pulse included in some TV signals. The technology to solve the problem has been around since before the product, yet everyone was creating new technologies trying to solve the wrong problem. It wasn't until someone took a step back and redefined the problem that it was finally solved.
Usability practitioners agree that we rarely "get it right the first time." From this we can conclude that we are almost always digging in the wrong spots. We must make a habit of taking a step back to review the users' goals and make the necessary corrections in our design approach.
We owe it to ourselves, our clients, and our users to have a clear task metaphor and navigation scheme before we design a single screen. This will help us make sure we are digging in the right spot.
ABOUT THE AUTHOR
As an innovator, mentor, and writer, Larry Marine has led the usability efforts at the consulting firm Intuitive Design for over 10 years. His active participation in and contributions to local and national usability-oriented organizations combined with his demonstrated design acumen, earns him recognition as a usability professional with skills in both macro- and micro-design. If only he were as adept at his other passions of golf, cycling, and skiingmight as well ask to win the lottery!
©2004 ACM 1072-5220/04/0100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2004 ACM, Inc.