As product designers, we often unknowingly focus on how users will feel as they engage with a new feature or interface. The act of empathizing can become a background process that becomes hard to articulate to stakeholders when they see us expressing a strong opinion. While designers frequently emphasize the importance of empathy, this concept can sometimes be a vague platitude rather than a concrete, actionable principle. Simply stating a need for an “intuitive” or “usable” interface doesn’t fully articulate the complex range of a user’s needs.
We also balance the human and business needs of users who don’t think of themselves as having been born to create spreadsheets.
Now, one of the things we’ve done in Glare is compiled a list of twenty (20) user needs broken into five categories. However, as we’ve done this, there has been push-back as to whether this is necessary, whether this is creating a burden for a designers, researchers, and people looking to bring clarity to the problem space.
In this example, the user brings all of their needs with them at all times. But, the designer is observing the user and the software, empathizing, and identifying primary user needs (in red) that need to be addressed due to context or specific tasks.
We’d like to know, how do you think about user needs?
Do you have a specific list or terms in mind as you empathize?
Do you have a specific resource that has guided you?
What do you think of the list of twenty presented here?
Peter Morville’s honeycomb emerged from the three-circle diagram, which he explains (back in 2004) how and why we must strike a unique balance on each project between business goals and context, user needs and behavior, and content. This was IA focused.
In my experience with product teams, it’s difficult to agree on what a ‘need’ is or what types of customer needs exist. I’ve seen user needs expressed as ‘Jobs to Be Done’ a lot, so this framework has clearly shaped our way of approaching needs. We try to structure the needs in a way that the desired outcome is associated with the core job. For example, “Minimize the time it takes to upload assets to start analyzing insights fast“.
JtbD is a great framework, but it requires research to get started. It’s valuable to get teams aligned in a project for sure, but we’re wondering if defining User Needs as an initial set can be valuable starting point to give teams language.
Any thoughts on the idea of User Needs as a starting point, possibly to help inform a Jobs to be Done framework?
Love this discussion, I really see the potential here, it’s like creating a shared User Needs taxonomy that helps the team speak the same language. It could be super useful for tagging design feedback or auditing existing work. At the same time, there’s a risk of introducing bias if we define those needs too early, before any research. I think the key here is to treat that starting point as a flexible initial list, and then validate those needs as the team learns more about the users.
Curious your thoughts on the list of user needs below. How would you say this fits with your expectations of what user needs are? Do you see a synergy across the needs as defined?
The value of a user need becomes clear when you see what’s missing. That’s how most teams express it. It’s somewhat intuitive.
When design or product teams try to make something more usable by making it easier to understand, they’re really describing how far the current experience is from what they believe “easy to understand” should be.
But that’s very vague and difficult for the business to understand.
If we measure usability through something specific, like comprehension, we can see how much improvement is needed… for example, how to increase comprehension by 10%.
Taking a proactive approach and strengthening a specific user need is a different way to look at it, but it can be really valuable for the business. Would love to hear your thoughts, @Helge.
I think the goal of User Needs and UX metrics in Glare is to calibrate whether we are meeting those user needs. User needs are a hypothesis until proven.
@Helge shared a great resource on making exceptional experiences, and I attempted to show in the framework how we are addressing this gap:
For us we were very often focused on physicians who came to us to learn something. We found that the most important thing we could measure was learning and then speed of learning.
Next we needed to make sure that this learning together with other experiences over time led to the behavior we wanted (physicians suggesting the treatment to patients).
And finally we needed to make sure it was our product that was chosen for the treatment.
User Needs:
An obvious need for physicians might be learning. Speed of learning is also important.
What other needs does this show…why do they need to learn faster, and what problems does the learning solve? There are probably more specific ways to learn, for different purposes.
Audiences
Customer? Partner? What attributes make these physicians’ needs interesting in this system, and how do we find different groups that exhibit those attributes? You may not need a perfect match to figure out the design.
Collecting
What methods will be used to collect data and information to learn about these needs and attributes?
UX metrics
Which UX metrics can we define (based on the audience and user needs) to use across the other blocks to better design a solution that is grounded in data? Here’s our free UX metric cheatsheet. All the attitudinal and behavioral metrics can automatically be collected in Helio.
Across these 16 blocks, we show you how to create more design value by using the UX metrics to define and defend design and product decisions. The framework makes design work.
I think this speaks to the need for specificity to align teams around what they are, what they aren’t, and how we use them. As Adam Silver clarifies:
So instead of ending up with a bunch of these:
→ As a user
→ I need to find messages
→ So I can respond quickly
You’ll end up with a bunch of these:
→ Users scroll through long lists, often missing the message they want
→ They’re frustrated and expect some kind of grouping
→ Different users have different mental models
