Users design for themselves, and don't always know what they want
In last month’s column, we talked about ways to include users in the design process by employing Subject-Matter Experts (SMEs). While it is always advisable to understand the user perspective, there are certain dangers that are associated with an overreliance on user input. As we’ve mentioned in the past, improperly conducted user research can be a liability that could lead you down the wrong path. These kinds of mistakes are extremely costly and easily avoidable. The trick is to know where the pitfalls lie and ensure that you navigate them properly. This month, we’ll talk about ways to be a critical consumer of user research.
Users don't always know what they want!
Users often have some difficulty being objective and thinking outside the box when it comes to factors that affect their own lives on a day-to-day basis. Even UX professionals, with all our experience developing innovative products, occasionally react to the introduction of a new product that could greatly influence our lives by asking ourselves: Why didn’t we think of that? The answer is that we, as users, become so accustomed to our own needs—and the pain points we encounter in trying to satisfy them—that we fail to perceive them. As a result of this phenomenon, what users report they want may not ultimately reflect what they actually need.
Numerous times, we’ve conducted home visits or other contextual research and seen pain points to which users have learned to turn a blind eye. We’ve discovered countless workarounds users have employed to address awkward processes that they fail to report. And when we inquire about them, users typically respond that they’ve just learned to live with these problems. For this reason, we make a point of not relying entirely on users’ self-reported data. A little objective observation of actual user behavior goes a long way and can uncover substantial differences between what users do and what they say they do. If you fail to encounter the same responses to problems, you may be designing to fit a need that doesn’t actually exist.
If you can manage it within your budget and schedule, spend some time with actual users and observe what they do when engaging in the behaviors that are of interest to your team. Keep a close eye out for deviations between user-reported actions and actual user behavior. When you notice a deviation, ask about it.
For example, if a user reports that he normally uses the keyboard and mouse fairly equally, but you observe him using a lot of keyboard shortcuts and avoiding use of the mouse, you can ask him: Is this how you normally use your computer? You seem to be able to use your keyboard to do a lot of things. When do you usually end up reaching for your mouse? In this situation, people often alter what they have said previously to indicate more keyboard-based interaction, with mouse interaction under specific circumstances.
In almost all cases, you are better off relying on directly observed behavior rather than self-reported information. We have a saying around the office: Behavior never lies.
It’s not unusual for us to hear someone request a design change or fight for a feature with the justification that the users want it, when in reality, users won’t really know whether they want it until they have had a chance to experience it personally.
Video calling provides a great example of this. Users have requested video communications for decades, but video calling hasn’t really taken off despite the technology’s being available for quite some time. Instead, phones have gone mobile and text messaging has emerged as the next major progression in communication. So, rather than demanding a more immersive interaction through video calling, the market has gone in the other direction, favoring quick communications that are less immersive than a phone call.
To address this reality, give your users a taste of a proposed new product or new functionality before you go full-steam ahead with engineering. You can use some mockups to fake the functionality and put it in front of users to see how they react. This will give you a much more reliable idea of whether a product or feature really addresses a need.
Uses are not trained interaction designers
When you ask users to evaluate your product and its user interface, you’ll often get suggestions for how to modify the interface. In such cases, take user feedback with a grain of salt. Keep in mind that users don’t have extensive training or experience in thinking about how people interact with products in their daily lives.
For example, users tend to focus on a single interaction element at a time rather than seeing a product as a whole. As a result, their feedback concerning how to improve a certain feature may interfere with the use of other features. We’ve seen users have difficulty locating a low-use feature, then request that we give the feature much greater prominence on a Web site landing page, when this would have been inappropriate given the feature’s value and would have de-emphasized other features of higher value. Instead, we were able to solve the problem by altering the Web site’s architecture, so users were able to get to the feature through a more intuitive process—by selecting a broader category on the landing page.
Interaction designers have a great deal of training and experience in crafting usable products and services. It is essential that product teams rely on their knowledge when designing products. We’ve seen product managers override the recommendations of qualified interaction designers in an attempt to satisfy idiosyncratic user requests. Doing this is usually a step in the wrong direction.
User research can easily provide value by determining whether a design needs improvement, but actually obtaining guidance on how to modify the design takes much more thought. Understanding the reasons why users encounter difficulty with a design is key to determining what modifications an interaction designer should make. Once you have discovered the underlying reasons for a usability problem, an experienced interaction designer can use that information in modifying the design. Ideally, you should then test the newly modified design to ensure that it really works for users.
Users designs for themselves
Every user is unique, and all users vary to some degree in how they would actually interact with your product. These variations in personal wants and needs tend to bias users’ design ideas toward accommodating their own idiosyncratic behavior. Users often make requests for changes to user interfaces that might work for them, but would have a negative impact on the majority of the users in your target market.
We’ve done exercises in which users designed their perfect product only to discover that no two designs were alike. There are times when you must trade off design elements to accommodate other features. For example, we’ve had certain users request that we place a Print option in a specific location to maximize its availability, while other users requested that we place another feature in exactly the same location.
In such cases, it’s important to prioritize design elements. To do this successfully, you should first identify your product’s core and high-use functionality, then maximize the availability of this functionality in your user interface. If you simply try to implement all of your user’s requests, you’ll likely fail to prioritize your product’s functionality properly and end up with a design that doesn’t work for most users.
To overcome this tendency to design for specific users, make sure that you get input from multiple users, compare and contrast their feedback, look for trends, and identify underlying concepts and mental models to ensure your user research provides good design guidance. The essential point is to avoid taking user-generated design ideas literally, and instead, try to understand the underlying reasons users have made particular design requests, then incorporate those reasons into your design thinking.
Conclusion
Acquiring user perspectives on product concepts and designs is an essential part of the product design process. What you do with these user perspectives is just as important as doing the research. Make sure that you do not take user feedback or requests for design changes at face value.
Keep in mind that users are not trained product-design professionals, so it’s important that you understand the underlying reasons for their design recommendations at a deeper level rather than just taking them at face value. Failing to do this can lead you down the wrong path and harm your product’s adoption in the marketplace.
Design by user is just one way in which user research findings are often misapplied—even when you’ve conducted the research properly. It also shows that the saying some research is better than none is not necessarily true. There are possible liabilities associated with improperly conducted or misapplied user research. We hope that, through education, we can help people avoid falling into these traps.
(Image source: research.ulowa)
