From an Ops standpoint, this distinction shows up often.. Teams jump straight to people’s “wants,” and then wonder why the work doesn’t solve the real problem. When we focus on actual needs (the things blocking progress or causing friction) that’s where the magic happens. It keeps the work grounded in what really moves the product forward.
My approach:
In a given situation a person is motivated to action by their need for progress (progress = to achieve or overcome something). The type of action they choose depends on/ invites them to evaluate different products they can hire supporting their behavior.
People ‘want’ products to support their behavior motivated by their ‘need’ for progress.
e.g. If I just moved into my new student flat and need too furnish it today I can hire IKEA to get the job done.
Looking at the world through the lens of situations means investigation all influences having a positive or negative effect on what the person is trying to achieve.
When trying to identify what the most significant influences are I prefer to use an anthropological type of approach. Some of these influences could be (depending on situation)
Culture
Social Structure
Environment
Identity
Economic factors
Technology
Relationships
This list is very broad / high altitude. Usually you would find influences that are more specific (sub-categories of these)..
Interesting, so these start to feel like what we call audience attributes. Attributes make audiences measurable. We briefly considered using attributes as the main label, but ultimately kept audiences as the primary structure. Attributes sit inside each audience.
In Glare terms, attributes describe the traits that shape how different people experience your design, not as marketing labels, but as meaningful contexts that influence usability, trust, and satisfaction.
Core attribute types:
Behavioral: frequency, experience level, or product usage patterns
Motivational: what drives engagement (speed, mastery, trust)
Contextual: where and how they use it (device, environment, workflow)
Lifecycle: new, active, power, dormant, or churned users
Demographic: role, region, or background when it adds insight
First: We used situations as a frame to better understand what influenced what we were trying to achieve. Situations broadened our understanding of what has influence and where we can have influence.
It helped us understand what to design for.
e.g. in our work we found that physicians wanted both energy and to learn as a network from a learning experience. So we needed to design for these and measure if we were successful.
BUT, it’s only ONE part of what is helpful to measure. I’m not sure I can find these examples in you list, or maybe it’s another layer entirely? Not attributes, but influences?
–
Second: I hope I can ask two specific questions that came out of our work with physicians. And where in the entire Glare framework I would find help to solve these.
We learned that:
a). physicians needed to learn and wanted ‘learning’-experiences to #1. Help them learn #2. give them energy and #3. help them learn as a network.
b). physicians needed to teach patients about their disease and wanted our content to #1. Help them build a better relationship with their patients (teaching is more about the building of relationships than the transfer of knowledge)
In Glare let’s give this a whirl using sitruations, across three layers:
Situations (frame the problem)
Professional learning under cognitive load
Peer comparison and shared practice
Fatigue, time pressure, and identity as experts
This answers what forces are at play.
User Needs (what must be satisfied)
Understand: gain usable knowledge
Feel: energized, not drained
Belong: learn with peers, not alone
This clarifies what success means to the user.
UX Metrics (how you measure it)
Glare helps you translate those needs into signals:
Comprehension
Do doctors and patients reach the same understanding of the condition, options, and next steps?
Trust
Does the experience increase confidence in the information and in the relationship itself?
Sentiment
Do patients feel reassured, supported, and clear rather than anxious or overwhelmed?
The goal is to go beyond saying “learning matters.” You are testing whether the experience actually delivers learning, energy, and shared meaning. You can start to test your hunches using the same metrics before implementing or building a solution.
I particularly like ‘perception’ as an aspect. When doing AI implementation, this is the toughest thing for people to articulate and also why AI implementations can fail - what perception of what AI is and can do.
“I have found a much stronger way to check if what you have is an observation or an insight is to check for the ‘Why’. Without the ‘Why’ it is always an observation — never an insight.”
Which highlights an important idea:
“If an insight is not actionable, then likely it’s not as important to the end result or does not impact the core idea/ business/ stakeholder in question.”
This is where I see the need for design signals that use observable behavior from ux metrics to find patterns.
I’ve found that, especially in product design, actionable design signals provide significantly more timely value when making decisions. Most teams would be better off continuing to build a thesis off design signals rather than chasing an insight that may not be relevant to their problem. Having a hunch and using intuition is necessary.
