Why We Need to Observe Users
By Leslie Tudor
I love to shop and my husband does not. So? We both buy stuff but we go about it differently. And it's not just a gender thing. Well, it is a gender thing but it's more than that. Have you thought about how people shop and why they buy?
Not recently, Malcom Gladwell, the popular writer for the New Yorker and the author of Blink, reviewed the surprising findings of Paco Underhill and his colleagues at Envirosell described in "Why We Buy: The Science of Shopping." Envirosell conducts extensive behavioral observation of shoppers as they enter and make their way through stores. They use a combination of video cameras and onsite observers. Some of their findings include the following:
1) Upon entering a store, most shoppers will reflexively veer right
2) When shoppers enter a store, they downshift their speed, often breezing by the "Decompression Zone" (the area just inside the door) and, after 5 to 15 paces, slow down to shopping speed
3) People (most often women) do not take kindly to the "butt brush effect" and will leave a table or aisle when others get a bit too close. For this reason, they will avoid narrow aisles.
4) The chances that shoppers will buy something are directly related to how much of the store's depth they navigate and how much contact they have with employees
5) Most men become anxious if they must make their way through women's apparel in order to get to menswear
6) Most men desire a "Garanimals" system, where display shirts are presented with matching ties
Based on these findings, retailers avoid placing valuable items in the Decompression Zone, place their hottest items in the back edge of the zone 5 to 15 paces in towards the Invariant Right, avoid placing women's products that require extensive inspection in narrow aisles, put things that people buy a lot of (jeans, for example), in the back of the store in order to draw shoppers in, and put the menswear up front rather than at the back (ideally giving men and women two separate sections altogether, providing men with what one Banana Republic executive called "clarity of offer - the peace of mind that they won't inadvertently end up in, say, women's undergarments.")
The thing that struck me about these findings is that, as a shopper, if someone had asked me to describe what I do when I shop and to enumerate the pros and cons of a shopping experience, I know I would not have commented on the fact that, upon entering the store, I typically start on the right (which I, in fact, almost always do), that I find narrow aisles distracting and unpleasant, and that I often overlook the items in the front of the store since I quickly make my way to the back edge of the entrance area and center. I might have said that I like brightly lit shops whose items are well organized. I might also have said that I prefer little or no background music. In contrast, if I had been asked to describe my shopping behaviors while I was actually having a shopping experience, the less conscious aspects of my behaviors may have been more accessible to me. Additionally, the possibility of accessing this information would have increased if an objective observer had stopped me at various points along the way to ask "tell me what you are doing and thinking."
Which brings me to the topic of behavioral observation and its importance in the software world. The usability literature abounds with examples that validate what every experienced usability analyst knows: users often have a difficult time articulating what they do outside of the context of actually doing it. And sometimes, even while performing a task, they tend to gloss over the behaviors they take for granted or those that they have done so many time that the motivation has become almost subconscious. For those of us responsible for the design, obtaining good behavioral data preferably before the design process has begun is critical as it can drive the design model and so has significant ramifications for the entire user experience. Usability testing is imperative once we have something to test but we should ideally be testing a design that was motivated by user data.
I am reminded of a project I worked on several years ago in which I was asked to design a product for power engineers that would help them to configure and maintain large power systems. At that point in my career, I had been designing software and hardware interfaces for several years and despite the fact that I knew that I was not the user (not even close on this one), I couldn't help but have a strong preconceived notion of the user interface prior to conducting user research. Once I got past the mystifying terminology ("Slope Thermal Compensation" was not part of my working vocabulary at that point), the hundreds of cluttered screens consisting of mismatched items and incomprehensible error messages, I was able to identify the task objects and their attributes, and imagine how I might form conceptual groupings of these. I knew that my design was based on my own limited understanding of power engineering (gleaned from a few papers I had read) but still - I felt confident that I was headed in the right direction.
My user research consisted of spending 3 solid weeks trailing power engineers in Indiana, following them into subterranean caverns that were connected to narrow vertical, laddered passageways accessed via above-ground hatch domes. For those 3 weeks, I played the dual role of observer and apprentice as I shadowed these engineers day and night, watching as they performed their tasks. Several of these users had suffered on the job injuries that were clearly visible (most often, 1 or more missing fingers), some were war veterans, and some were close to retirement. Some were a bit gruff as well but it was probably their amusement that "that little gal from R&D" cared enough to learn about float voltage levels and rectifier failures that gave me entree into their world and allowed me to trail them with my notepad, peppering them with questions at the end of each day. Not surprisingly, the body of data I collected during those 3 weeks was much more intriguing and meaningful than anything I could have imagined on my own or had gleaned from papers on power engineering. I walked away from that 3 week apprenticeship with a thorough understanding of critical tasks, task frequencies, and the observation that the users' mental models were a far cry from the task flows represented in their current product which was, essentially, a disturbingly random and promiscuous display of data tables for objects like rectifiers and battery strings. As I experienced "aha" moments, I was able to validate design ideas with my users in the moment, making sure that my insights were consistent with their conceptual models. Without this data, there is no way I could have designed an interface that was as well received by its users.
Sure, most SAS users are probably not as colorful as my power engineers, and we get to observe them above ground at their desks instead of making the steep descent into the underworld where we must don safety suits and helmets. And unlike brick and mortar shoppers, we don't need to watch our users navigate through a physical space where narrow aisles and womenswear provoke anxiety. But that doesn't really change anything. We don't already know what our users need - we need to find out. And users have a hard time telling us what they do. The value of onsite usability research is bridging that gap. We observe, we learn, and then we design.
