Beyond User-Centered Design and User Experience: Designing for User Performance

Constantine & Lockwood, Ltd. PREPRINT Beyond User-Centered Design and User Experience: Designing for User Performance Larry L. Constantine, IDSA Chief Scientist, Constantine & Lockwood, Ltd. Director, Laboratory for Usage-centered Software Engineering University of Madeira, Funchal, Portugal User-centered design is everywhere in the IT world. Just as it was once fashionable to tout “user friendly” interfaces, these days nearly everyone has jumped on the user- centered bandwagon—or is running to catch up. The bandwagon is a roomy one, and user-centered design can be almost anything in practice so long as it adheres to the core philosophy of keeping users at the center of the software development process. This focus on users as the central subject certainly seems to be a step forward from the technology-centered focus of bygone days, when users were all too often regarded as an annoyance to be ignored as much as possible. However, the frustrations of everyday experience with even the best of modern software products and Web sites tells us that something is still badly wrong with the picture. You need only reflect on how many times a day you click on the wrong object or miss a step in a sequence or forget where a function is buried or curse the way some feature works to recognize how much modern user interfaces fall short of their potential. Putting users in the center of the picture and using techniques that focus on them and their experience may look to be reasonable, decent, and proper things to do, but despite the good intentions and noble efforts of designers, progress in usability remains unremarkable. Instead of getting breakthroughs in performance and leaps forward in what can be accomplished with computers, users are often left with a level of tolerable mediocrity marked by missing functions, frequent and irrelevant interruptions by modal messages that belabor the obvious, and multi-click detours to complete the most mundane of tasks. Breakthroughs in usability are possible, however. Consider these, for example. Q In a debriefing at the end of the first day of live use of a newly designed medical records application, a nursing professional was moved almost to tears because, despite a new system and only the briefest training, she found she was already getting more time with her patients. Q After seeing a new classroom information system, a veteran teacher declared that for the first time he felt that designers had understood what classroom teachers really do and what they needed from a computer system. Preprint of article appearing in Cutter IT Journal, 17 (2), February, 2004. © 2004, L. L. Constantine Page 2 of 12 Q Using a radically redesigned integrated development environment, programmers of automation applications were able to complete a typical mix of tasks in half as many steps as previously. To consistently produce such radically outstanding results may require that designers and developers radically rethink how they approach the process of visual and interaction design. It may require them to consider the unthinkable, that there could be something wrong with user-centered design and its pre-occupation with users and user experience. Among usability professionals, user-centered design is so established that even to hint at problems in its premises or practices is regarded as sacrilege. As a co-inventor of usage-centered design (Constantine and Lockwood, 1999; Constantine and Lockwood, 2002), I have more than once been the target of such accusations. After one session at a SIGCHI conference, an audience suggested on an evaluation form that I never be allowed to speak at the conference again because I had I questioned some of the received wisdom regarding the role of user studies and usability testing in user- centered design! User-Centered Approaches Fully forewarned that I may be treading the path to design apostasy, I want to explore what user-centered design gets right and where it goes wrong—and to suggest some ways to fix what is wrong with the process. Where user-centered design gets it right is the easy part. Involving end users and learning about their real needs is a good idea, no two ways about it. Spending time upfront to understand user requirements is an absolute prerequisite for sound design practice, irrespective of your approach or philosophy. Absent the goad of a user-centered approach, many projects would plunge too quickly into software design and construction. The result is the illusion of progress (“We’re in the first week and we’re already coding!”) purchased at the price of premature commitment to particular solutions that invariably compromise utility and usability. (“Too late to fix that, it’s already hard coded.”) To understand what might be wrong with user-centered design and what needs to be done about it, we first need to understand better just what user-centered design is. Beyond its requisite focus on users, user-centered design gets a bit fuzzy. Crisp textbook definitions aside, user-centered design in practice is a rather cluttered collection of loosely related techniques and approaches having in common little more than a shared focus on users, user input, and user involvement. While it may be different things in the hands of different practitioners, at its core, user-centered design is distinguished by a few common practices: user studies, user feedback, and user testing. Through various techniques and tools ranging widely in formality and sophistication, user-centered design seeks to understand users as thoroughly as practical. Initial user studies provide the essential input for iterative prototyping driven by user feedback, which is followed by user testing and, one hopes, further refinement of the product. That’s it. Partisan adherents of particular variants of user-centered design may argue that this characterization omits some cherished technique, tool, or activity central to Page 3 of 12 their preferred approach, but this admittedly over-simplified view highlights what user-centered design is really about and where it goes wrong. Let’s start with design. Design in User-Centered Design A skeptical analysis might conclude that none of its core practices—user studies, user feedback, and user testing—really have very much to do with design itself. Despite its name, there is not much design in user-centered design. Indeed, books on user- centered design often have much to say about users, user studies, human perception and cognition, human-machine interaction, user interface standards and guidelines, and usability testing but relatively little to say about design or design processes. The dirty secret that few advocates and practitioners will admit to is that user-centered design in practice is largely trial-and-error design. Stripped of semi-scientific rhetoric and professional self-justification, most user-centered design involves little more than good guessing followed by repeated corrections and adjustments guided by checking with users. Once the mandatory user studies are out of the way, a potentially workable solution is quickly sketched as a paper prototype. Little has been written about how this initial idea is conceived and few designers can articulate the mental legerdemain involved in its creation, but once you have something, you put it in front of one or more users to find out what is wrong with it. Basically, iterative refinement based on paper prototyping relies on users to tell the designers what is wrong and how to get it right. Done well, it certainly helps users to feel involved and empowered. It can also be reassuring to designers, particularly if they are unsure about their own guesses or lack complete confidence in their design skills. After all, the end product is the result of real feedback from real users. (“Well, we did the right thing and got user feedback even if the result didn’t work.”) For similar reasons, repeated refinement through iterative prototyping is reassuring to clients and management. They get to see early evidence of apparent progress; it may not be real code but at least they get screen mockups. Furthermore, designers can defend the ultimately delivered design as being based on “real data”—real information from real users. So, what’s wrong with iterative prototyping with user feedback? Here are the basic flaws and failings. Q It contributes to the illusion of progress. Q It encourages premature preoccupation with detail. Q It discourages courage. Q It relies excessively on users. As already hinted at, the flurry of paper prototypes can contribute to the illusion of progress. Decisions are being made and design artifacts are being generated, but this does not mean that real progress is being made toward a first-rate solution. For one thing, at the stage that realistic or representative paper prototypes are typically produced—prototypes that are recognizable and make sense to users—it is usually too early in the game to be worrying about what the screens will look like and what functions they will present. The early involvement of users and the need for them to be able to interpret and react to the prototype forces premature investment in realism Page 4 of 12 and the details of the design. Early paper prototyping encourages hurried decisions about details at the level of individual screens and widgets without first considering what screens in what arrangement and supporting what functions best support user needs. Designers are frequently seduced away from the more abstract and often less exciting work of first mapping out a sound overall architecture for the user interface. When paper prototypes are constructed early—often ahead of or even instead of a full analysis of user requirements—detailed decisions can rely too heavily on unverified assumptions. Unlike a properly behaved iterative computer algorithm, the cycle of feedback and change in iterative prototyping does not necessarily converge toward a better solution.

Load more