User Experience Research: Good Investment or Waste of Time?
Most projects at Universal Mind begin with a one to two-day workshop in which designers, developers, business stakeholders, project managers, and subject matter experts are invited to collaborate. This is an essential step for the Universal Mind team as we work together to define the project through requirement gathering exercises and quickly learn the specifics of your domain and your unique business challenge. Considering the team’s personal experiences, anecdotal evidence and opinions, a one day workshop/kickoff with your internal project team involves discussion, arguments, and assumptions about what the user’s goals are and what they want or need the product to do.
Whether they realize it or not, business analysts and product owners inside your company often have a poor understanding of actual users in the context where they will be using the software.
The workflows they describe are usually idealized, tidy, and logical. Research uncovers major gaps between what is described by SMEs and what happens in the real world. It’s understandable that SMEs think users want the same things they want and think the same way they do, but in most situations users behave very differently. Finally, the understanding of customers that arises from interactions through sales and marketing differs from the understanding of users that is needed to build a responsive software product.
After the initial workshop, the most successful projects move immediately into a user research phase. Unfortunately, many of our clients typically have a strong impulse to save time and money by skipping user research and immediately diving into building the product. This is a result of the misconception that user research is a “nice-to-have” (but not really necessary) component that increases costs, creates delays, and adds only marginal benefit to the project.
In fact, user research doesn’t need to be expensive. In most cases, it usually reduces total project spend. Exhaustive research may have a lower ROI than research that is what we consider to be “good enough for design.” A surprisingly low number of interviews, performed in the context of use (a process called “contextual inquiry”) can yield significant results in a short amount of time. We sometimes shorten a research engagement once we have found enough information to confidently begin design.
While observing Customer Service Representatives at a high-volume call center, it took the designers less than three interviews to realize that what the SMEs reported as the ideal workflow rarely represented the actual workflow experienced by the customer service representatives. We began forming a hypothesis early in the day of a design framework that would be more flexible and adapted to their real-world workflows and context scenarios, and by the end of the day we had already roughly sketched what would eventually become the new call center application.
This example also demonstrates the fallacy in the second assumption that user research creates unnecessary and expensive delays. After spending a day doing research, the design team had a clear direction and were able to design with confidence and quickly recommend a potential solution. Research also speeds up the design process by minimizing error and giving the designers a more concrete understanding of what is important to the user instead of what is presumed to be important by the SME.
On another project, while conducting interviews with high school students on the yearbook staff, we learned that the most enjoyable part of the process for them is looking through and selecting photos for the yearbook. Prior to our research, we had originally allocated more budget for innovation around streamlining and automating the class portrait placement process. The rules around creating the grid of photos, along with names was something that SMEs had identified as being painful. Interestingly, this wasn’t perceived as an issue to the students. In the end, the client agreed to spend extra time making the features for browsing photos more fun and innovative instead of working on altering portrait placement.
In a third example, user research saved time, money, and helped us to create a much better experience for users when designing and building a self-service portal for one of the largest telecomm providers in the country to manage their telecommunications services. A couple of features that they requested during the kickoff were radically re-prioritized after the research findings were reported back to them.
One of the features was a product configuration tool for building and pricing what we (the design team and the SME/Product team) perceived to be a complicated set of products and services. The design team had a lot of experience designing configurations for many verticals, and the feature request made perfect sense to us. What we found during user research was that the users had little to no need for a tool like this. These were expert users who knew exactly what products and services they needed. We learned that even if we made the tool intuitive, comprehensive, and easy to use, it would mainly go unused at a great expense to the overall project.
Another feature that the client requested was chat. This was during a period when chat tools were becoming really popular, and our initial perception was that the client was including this as a “me too” feature. In fact, they were. This feature was low in priority for the client and likely to fall off the set of features available at product launch. What we discovered during the user research was that an internal communication and collaboration tool was something that these users desperately wanted. We couldn’t understand why they wouldn’t use existing chat/IM tools until they demonstrated their workflow to us or explained the limitations of their own environments. The chat feature got moved to high priority based on our findings and cost much less to design and implement than the configuration tool.
User research challenges and validates assumptions and offers often surprising insights that help the entire product team overcome false preconceptions or a lack of information. Without research, the assumptions become the basis for decision making and design all throughout the project, and weaknesses in the assumptions will diminish the quality of the product.
When you realize that allowing room for user research doesn’t add cost and time to the project and results in higher-quality products and a greater chance of success, the argument to skip user research is an argument to spend the same amount of time and money for a lower-quality product at greater risk of failure.