The Importance of User Research in UX
As a designer, I’ll never stop evangelizing the importance of user research. We’ve talked a lot about the benefits of user research on our blog and we believe it’s a critical part of our process when working with clients to create solutions for their users. Earlier this week, the design channel of Fast Company, FastCo Design, published an article called, How Apple is Giving Design a Bad Name, that scathingly points fingers at the myriad flaws in Apple’s software - alluding to the absence of user research as one of the primary culprits.
The article was written by legendary designers Don Norman and Bruce Tognazzini, both longtime design leads at Apple, laying the foundation for the OS X operating systems with their development of the Apple Human Interface Guidelines. The article reads, “In a uninformed company executives assume all this upfront design research, prototyping, and testing clearly must slow down the development process. Nope. When done properly, it speeds things up by catching problems early, before coding even begins.”
Struggling to convince clients and stakeholders to intentionally include design research as part of their design and development process is a theme I’ve encountered throughout my entire career. My colleagues often share similar experiences. In one of our recent posts, my colleague RJ Owen writes about The Three P’s of UX Design Research being Pitch, Process, and Practice. In the article, RJ even suggests that we consider dedicating 90%of our design pitch to research. He recommends not showing half-baked solutions, but instead clearly articulating how the design team will go about researching and solving the challenge at hand.
The difference is usually immediately obvious between a product that has been built entirely by developers versus one where professional designers have been utilized to focus on creating a better user experience. The difference between a decent user experience and an innovative or game-changing user experience usually comes down to the level of access that designers have to the actual or potential users of the product that they are designing for. The examples below help illustrate how profoundly research can impact the final design.
Back in May 2015, my colleague Pete Kinser wrote a piece called, How Building a Human-Centered Product Helped an Organization Strengthen Its Mission. Pete’s client was building a medicine dispenser for people with cognitive and/or physical disabilities. The client wasn’t sure if it made more sense for the door of the dispenser to slide up or down, so they asked Pete to explore. While doing field research to arrive at a potential solution for a problem his client had identified, Pete made several important discoveries; initial hypotheses about potential solutions to the door problem were wrong. The door didn’t need to open up or down but out. Even more importantly, the initial problem that the client had identified was the least of their concerns. While observing people using the product in their homes, Pete observed many people in wheelchairs struggling to view a screen based interface that had clearly been designed for a standing user. He also observed people with shaking hands struggling with the small buttons of the touch-screen. By observing only a few people in the context of their own homes, Pete was able to make recommendations to his client that would address the real challenges their customers would face when the product went into production. He likely saved them millions of dollars in production costs and helped them begin to understand how critical true user-centered design is.
Pete and I worked together on a research and design project that yielded similar results. The project was done in collaboration with a company that owned and operated the largest networks of gas pipelines across the United States. Through our observations in the field we were able to discover the true goals of the customer and propose an interactive solution that had the potential of streamlining that industry. The primary customers for our client were utility companies, college campuses and industrial complexes that use these pipelines to move natural gas from the producers of natural gas to the power plants that convert natural gas to electricity. Transporting natural gas is a massive business with a tremendous amount of money involved, especially with the prices in gas dropping causing a shift from coal as a source of fuel. When they hired us, after having made several acquisitions of pipelines throughout the United States, our client was averaging around $32 million in revenue each and every day.
The natural gas transportation game functions a lot like commodity trading where sections of pipe experience increased or decreased volumetric demands. Based on a variety of factors including the price of fuel being sold at a specific location, changes in weather patterns potentially increasing consumer demand or making it physically possible to “pack” more gas into a section of pipe, and segments of pipe being closed due to maintenance, people make entire careers of forecasting when to buy, sell, or trade space on pipelines. If they are good at it, some people even become independent traders. Stories of fantastic wealth are not uncommon.
They brought us in to evaluate the software systems they provided to their traders to buy and sell space on the pipeline. Following their recent acquisitions, there were four systems being used across the United States. In many areas, it was necessary for people to use more than one system to move product from pickup to delivery. Our client hoped we would find “best of breed” features and be able to combine them into a unified product for the company.
As our stakeholders began walking us through what they felt to be the most comprehensive and “best” of the systems, it immediately became clear to us that the bar was set incredibly low. Battleship gray screens reminiscent of Windows 95 teemed with tightly packed tables of information with little to no visual hierarchy. Modal dialog windows stacked four or five deep displayed series of buttons with zero padding, as well as text that would sometimes flow over interface elements. State changes would occur that were almost imperceptible, but that were critical for decision making. The performance issues were obvious as we waited for screens to refresh. Inputting strings of seemingly random numbers seemed to be the primary way users would complete tasks, and this was entirely based on recall; the system didn’t “remember” anything. Essentially, the product we were being shown was one of the best examples of what not to do in software that any of us had seen in a very long time. It was clear that no one with a background in UI design had been involved in the design of this system. More importantly, it was obvious that no one had observed or consulted the users when it was made.
We could have dramatically improved the user experience without ever setting foot inside the user’s working environment, but it was going to take us at least a few weeks to absorb the obscure nomenclature of the industry. Terms like allocations and nominations, rate schedules and capacity release, not to mention dozens of abbreviations and acronyms that riddled the interface, were going to take significant time to fully understand. In fact, our ability to understand the details of the industry was the most significant area of concern for our primary stakeholder. “How could you possibly understand all of this in four weeks when it takes months or even years for our own employees to fully understand it?” was a question that was asked of us on several occasions.
The best way, if not the only way, for us to ramp up into this domain was full immersion. We spent the following three weeks interviewing and observing users from each of the four pipelines to learn the nuances of each system. We learned what caused their pain and why. We found out when and why features or information were critical and what tasks were performed most frequently. Most importantly, we came to understand what their goals were and how they made the decisions that would help them achieve those goals. What we found was entirely game-changing.
In almost every office we visited, there were maps. Sometimes these maps were printed, but often they were hand-drawn on whiteboards. We learned how critical maps these were within the process of making realtime decisions about where to route natural gas. These maps were often annotated, and the traders would cross reference web sites that posted realtime data about the condition and capacity of those lines. It was an entirely manual process that took a lot of time and energy. We knew immediately that including digital maps of the pipelines with realtime data would shake up an industry that’s been doing things the same way for the past 20 years.
In addition to these maps, most offices we visited had several large screens prominently displaying weather reports and stock tickers showing the rise and fall of prices of natural gas and other commodities. The traders would sometimes walk across the room to look at a map, glance up at large screens to see weather reports, and go back to their computers to input the decisions they made. When users juggle multiple systems as sources of information for decision making, there’s usually a great opportunity for design. We wouldn’t have seen this had we not been on site.
After a couple of weeks in the field, we understood the software and the business process. We were already sketching preliminary ideas that used an interactive map instead of spreadsheet-like tables for the traders to visually route fuel from pickup to delivery points. These maps were overlaid with information that we discovered was important for decision making. Multiple sources of data could be seamlessly combined into an easy-to-use, information-rich concept. We even had time to validate our concepts with users.
As we reported our findings back to our stakeholders, we were able to do so using the lingo we had picked up along the way. We used direct quotes from users and told stories that resonated within their culture. We were speaking their language now, and their confidence in us grew as a result. In three weeks, their attitudes of hopeful apprehension had changed to wholehearted trust in our process and our abilities as designers to usher them into the digital era. As we transitioned to the design phase, our stakeholders even invited us to an important annual conference to show our research findings and design progress to their customers. Everyone was thrilled. The most frequent question was “How soon can this happen?”
As good UX designers, we could have incrementally improved the product without ever speaking to a single customer. If we had opted for phone interviews, we would have been able to improve things a bit more, by understanding the frequency and criticality of various features. All of that would have resulted in a better interface. But it would not have resulted in the dramatic kind of change that a truly user centered product is capable of delivering. Because we were out in the field talking to people as they used the software we were redesigning, we were able to identify incredible opportunities that would otherwise have been missed. The ROI of having designers in the field doing contextual inquiry was obvious to our client and reaffirming to both Pete and me that we were doing the right thing.
Even technology leaders like Apple can lose their way and begin to forget how important it is to establish and maintain the human connection and understanding that user research provides. I’ve had the opportunity to witness game-changing results through field research multiple times over the past decade. And I’ve come to believe that these stories are important ones to tell, because they serve as compelling reminders about why this type of research is crucial to the ultimate success of our work.
By keeping user research at the forefront of how we help our clients to address their most fundamental issues, we hold the potential to really change the game. If you’re interested in learning more about how user research has impacted our work with clients, let us know and we’d be happy to share case studies with you. If you would like to learn more about our process, please just say firstname.lastname@example.org.