Designing good interactive software is neither a science nor an art. It is not yet a matter of routine engineering, yet there is far more involved than native skill and intuition. In years of teaching human-computer interaction design, I have often felt frustrated in trying to capture for students the experience of creating useful, useable, and likeable interactive systems.
Many pitfalls and breakdowns lie on the path to learning good interaction design. First, students need to encompass the breadth of concerns that go into designing any real system. Everything from the social context of the users to detailed keystroke analysis may be of significance, and it might even make the crucial difference between success and failure. A method or approach that focuses on one aspect or discipline may be valuable but is only one piece of the larger picture. Often students end up with a fragmented collage of multiple techniques and concepts with no sense of how to relate them. They are faced with buzzword overload, trying to cope with user-centered design, usability life cycle, heuristic evaluation, participatory design, low-fidelity prototypes, GOMS analysis, systems analysis, object-oriented design, and so on.
This wide breadth of concerns also leads to an endless bog of design choices and details where one is easily lost. Students hope for a guidebook—a list of principles that can be followed to get the “right” design. But guidelines are never sufficient. They are too abstract to offer direct application to any given case. Often two general principles apply, with opposite conclusions arrived at (as in the maxims “Look before you leap” and “He who hesitates is lost”). The easy tendency is to come up with a principle and hold onto it for dear life, in spite of context that makes it inapplicable. General principles cannot give a sense of the need to make tradeoffs, which is at the core of design thinking.
With all of this complexity facing them, students (and many practicing designers) are at a loss as to how to get started. Their tendency is to dive into screen designs and code development. They jump to a likely-sounding solution and start debugging it, without taking the time to understand the alternatives and priorities from the user’s point of view. The concreteness of building a prototype provides a clear sense of incremental accomplishment as one piece, then another starts to function. In this software-centric process, it is all too easy to lose sight of the user—of not just what runs but also what matters, what makes sense, and what can be done.
Finally, student designs are often disconnected from previous experience and knowledge, both in the practical world of software and in the research world of relevant explorations. No matter how clever, any design suffers from lack of grounding in the collective knowledge of the discipline.
This is a tough list of problems, and as we like to say in computer science, “There is no silver bullet.” Interaction design is inherently the kind of activity that thrives on experience and wisdom, not on having the right answer book. But a book can be of great help, and this one is a fine example. It is built around a few key insights that go a long way.
The first key idea, as the title conveys, is to integrate a design and development process around scenarios. Scenarios have people in them, they are specific, and they are grounded in the real world. By starting with scenario development in all aspects, students (and practitioners as well) can ground their designs in the issues that deserve attention. The scenarios provide concrete starting points and deliverables, and they tie together the different concerns and aspects of design into an understandable sequence.
The second key is the emphasis on understanding tradeoffs. Every decision reflects a set of assumptions, priorities, and alternatives. Rosson and Caroll show how to make this an explicit part of the design process. In addition to the methods in the book, the extensive references to the research literature give a starting point to pursue issues further when greater depth is appropriate.
Third, the extensive use of a coherent worked-out example from actual experience moves the student away from abstraction toward concrete understanding. People learn more readily from example than from generalities, and the science fair example provides the texture and depth to get beyond a vague sense of issues to an experiential sense of what they mean in practice.
And finally, the underlying wisdom of the book is in recognizing that the real benefit of a good methodology does not lie in its ability to give the right answers, but in its ability to provoke the right questions. In the end, interaction design is, as the book’s title implies, a kind of engineering. Like all creative engineering, it requires the designer to make discoveries, not just apply formulas. A teacher or book can provide directions and suggest methods, but in the end, success depends on getting each designer to ask the questions that are right for the particular users, for the situation, and for the technologies at hand.
During the time I was reading the manuscript for this book, a student came in for advice on a dissertation project he had begun, focusing on interaction design for a new application in civil engineering. My first reaction was, “You need Rosson and Carroll’s book.” It was clear to me that its systematic approach to users and usability was sorely missing in his initial software-driven approach. I could think of no better way to get him started down a more productive path than to give him this book. I expect scenes like this to be repeated often in the future, as Rosson and Caroll’s work becomes available to a wide audience of both teachers and practitioners.