Jonathan Arnowitz, Elizabeth Dykstra-Erickson
Has your organization drunk the Kool-Aid yet?
There’s no lack of references for the value of user research. It has, thankfully, become quite easy to find a qualified consultant who can convince upper management that listening to customers, and then doing something about what you hear, is good for the bottom line.
We will warn that deferring your product decisions to the vagaries of a select number of customers probably reflects a lack of vision and focus on your part. Setting that aside for the moment, nothing could please us more than seeing evidence of traction for user research in software development.
Jonathan Grudin and Steve Poltrock, in their CSCW tutorials at SIGCHI conferences, have been telling us for years that we should not be designing systems for ourselves: We are most likely not going to be representative of the majority of the system’s eventual users. Our biases reflect our training and experiences in a way that is unlikely to match those of our users. Encouraging user research points product development down a potentially satisfying and remunerative path.
Product designs leap forth full-formed from only a few known foreheads in our universe (an herewith a gracious nod to Steve Jobs). For the rest of us, we know that interaction design requires interacting with others to get it right. While the interfaces we design are the seams between users and systems, the interaction we design connects people to their work, their play, and other people. You have to actually talk to them to understand what they want and how they think. Where ten years ago "ethnography" was a mysterious pith-helmet undertaking, today "customer research" is embraced as a valuable part of the product development life cycle. Customer research takes the form of direct observation via field work, site visits, customer "follow-me’s," usability tests, focus groups, and interviews. These direct methods supplement customer feedback, surveys, market research, and competitive analysis. While none of this is new, what is new is that from C-level management down to product-support technicians, we see a healthy interest in what the customer thinks and wants.
This isn’t to say that intuition is dead and we should all dust off our anthropology books and "go native." What we mean to say is that we hold the principle of design for use in high regard. We see increasing evidence that software development companies are adopting methods that include specific strategies for understanding the user (personas), the use (use cases and scenarios), and the subjective contextual value that a product delivers. So much so, in fact, that user centered design has become a rather unexamined shorthand for user research that can easily become conflated with market-driven design. We work for companies that place high value on interacting with users throughout the design and development process. We frequently observe an enormous data-collection effort that delivers very little value: There’s often no deliverable from user research that generates design decisions, and the research is done for research’s sake. (How often have you seen just the most favorable user anecdotes extracted from a report to support a particular position?) But that’s not user research’s only value. Another considerable value is the recognition your company can derive from being known for working directly with users. And yet another value is the opportunity you get when your company embraces user research: You can empathize, rather than sympathize, with your users, and develop your listening and observing skills. This serves us all in the area of "works well with others."
The next time your project engineer slips quickly out of his first usability test to "fix" your design, or the next time you see your project manager allocate one week for user research (never mind time for analysis!), or the next time your entire team descends (bag lunches in hand) on a user’s workplace to make some all-day observations, or indeed, the next time your CEO misuses the concept of user research, be grateful they drank the Kool-Aid. Once they start enjoying the Kool-Aid, you can introduce more flavors. And if they don’t immediately understand how to use the research, do your part to assist. It’s at least refreshing to hear the Kool-Aid talking.
©2005 ACM 1072-5220/05/0300 $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 © 2005 ACM, Inc.