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.
