I’m hoping to open a thread / topic to discuss / elaborate on my proposal that ‘situations’ are the fundamental unit of analysis.
I would argue that changing the focus to ‘situations’ would not only give us better data and insights, it would lead to better strategies and better measures.
Situations would also remove silos between teams in the organization, create a shared language fertilizing better collaboration and co-creation.
It would also invite more ethical data policies.
—–
Let me just introduce the setup and then see how the discussion flows from there (to avoid this post becoming too long):
People act because they are motivated.
What creates motivation is a desire for progress (towards a need).
To achieve progress people must do or think something (behavior)
And the reason people choose products is because they support a behavior people want in order to progress towards the outcomes they need
People will see this thinking aligns very much with Jobs-to-be-done theory .. but I find that this theory too narrowly focuses on the need itself, not the situation surrounding it.
e.g. a need or progress will always be the product of the situation surrounding it.
Focusing on the need is like unravelling only one out of many threads making up a thick rope. Situations take more of a systems approach trying to unravel more threads giving a better overview of the influences and relationships that leads to the need and behavior people want.
I’ll stop there. I appreciate peoples questions or push back to continue this conversation
I like it @Helge! I think this goes a layer deeper than most conversations around J2bD or User Needs, and it’s a helpful framing that differentiates the need from the motivations and behaviors that drive progress. Maybe the behavior of adding Jira tickets helps with progress, but it may not be the ideal behavior behind the motivation.
I’m curious if you could draw up a distinction between a ‘Situation’ another model in a specific use case?
I had an interesting realization recently about how we identify the right people to serve.
Initially, we focused on a certain type of person who seemed closely aligned with business goals and user needs. But as we reflected, I noticed something - the characteristics we cared about weren’t limited to that role.
For example, as a software engineer, I often find myself thinking deeply about user outcomes and organizational impact - not just implementation. It made me realize that the real signal isn’t someone’s title, but their situation and context.
The people who benefit most are those facing organizational struggles like connecting strategy with execution, or aligning user and business value - regardless of whether they’re a designer, PM, or engineer.
So now, instead of defining by who they are, we think about what they’re experiencing. That shift has been far more insightful.
And- not commenting on your post directly, but figured I’d drop that little revelation about situations.
Regarding your post, I can see how there needs to be an intertwining of situations to discovering needs, and how it really expands on understanding the user.
Changing language is always difficult, but I get what you are saying. We started using the word Situation in our Progressive Design 10 years ago (we were using a triple diamond long before the double diamond became a thing in 2005).
You could say that a User Need is the “hunch” that encompasses what we believe to be true, and the situation is the manifestation of those needs in scenarios that can be explained by direct observation or data.
Here’s an example: The differences often occurred when we did secret shopping and observed salespeople interacting with the customers. Needs changed.
That’s a subtle difference that most people won’t care about. So we’ve just stuck with User needs. But in concept testing, we’re changing scenarios that change the needs.
I’m open to incorporating Situations into Glare, though I wonder whether it adds more complexity that most will not understand.
Let me try to share from one of my own experiences.
We were looking for opportunities related to physicians in one market.
The company had been using the same traditional market research for years. Offering up the same questions, insights and framework (demographics based segments, archetypes and generic personalisation characteristics .. as in: doctor x likes her patients, she cares about them and want to offer the best possible treatment improving their quality of life). But it wasn’t wielding any results and at one point even head of market research suggested that “if we’ve been asking the same questions for the last seven years, maybe we’re doing something wrong?”.
Our team got hold of the research and started to deconstruct it. We weren’t looking for the narrative, but the data. We started mapping out “forces of influence” and their relationship from the data. And eventually came up with a map of the physician (not a story), with three different areas representing different situations.
When looking at them through these situations we could see that:
Everything we do happens in situations. e.g. If I want to be a great dad I can’t just be a great dad. I need to choose the situations (e.g. homework, gaming, when they are sad, sports etc.) where I can show up with some dad-superpower and deliver. This is the same with physicians. They can’t just be great physicians. They show up in different situations where they can do something that enables them to be / achieve what they want.
We were spending too much on a situation where the physicians weren’t even interested in us (we had no access). Currently we were spending a third of our commercial budget trying to accommodate physicians with behaviors attributed to this situation.
When you look at the world through the lens of situations you can easily find the underlying motivation and good experience design insights. E.g. when physicians want to learn they get energy from learning and they want to learn as a network. When they teach patients about their disease the building of that relationship is more important than the transfer og knowledge .. etc.
@EricZ I hope it added some answers to your question?
In systems thinking we talk about “forces of influence”, where anything can be a “force”. It can be a technology, process, people, culture, regulation, routines, habits etc.
Part of the work of a designer is to enthusiastically identify which forces have a significant influence and work to resolve those constraints (this is from Charles Eames: design is the sum of all constraints).
When we have worked to identify significant forces of influence we very often end up looking through the lens of situations, as situations are the strongest indicator of the relevance / significance of a force of influence.
I’ve found very little relevance / use when trying to look through e.g. demographics or linkedin-titles
@Helge yes this helps a lot. Identify the situations, map how motivations and behaviors influence them, and then ensure you’re meeting those motivations.
Totally relate to the ‘great dad’ situations, that’s a helpful unlock.
I’m playing the long game … I think ‘situations’ are the better unit of analysis (it’s also a better cross-functional aligner and secure better data ethic standards), but I agree that it would be a new term that people would need to learn.
Maybe what we need is to develop a guide for how to understand, find and map situations? Maybe that’s a good next step? Or what would all the brilliant people here suggest?
If we would want to explore, stress-test, develop, design and potentially launch and scale a situations understanding and methodology. What would it take or where should we start?
Maybe it’s a guide, but at the same time you have to make each step as important as possible through a continuum (aka start with the first step, drive value out of each so that people will follow the steps).
Shortest path to most amount value creates the highest adoption (I would assume).
This comes down to understanding what people are actually doing, what triggers action, what progress they seek, and how their context shapes behavior. This is core User Needs work, and situations are one level more concrete than typical needs statements.
This is not Collecting because the emphasis is not on methodology.
This is not Audience because the focus isn’t who, but what they are trying to accomplish.
This is not Hunches because it is not about instincts.
This is not Methods because the debate is not about technique.
This is purely about reframing what a “need” really is.
When you think about a concept, it’s a direct challenge to address a need… it could fall down in many ways… most of which is it doesn’t actually solve a problem.
Concepts, in some ways, create new situations.
Also, trying to figure out how this method plays into a situation. We call it an opportunity index:
Good stuff @Bryan I would say the Action Map is not too far off regarding breaking stuff into contexts /situations. But there are layers of insights about why people are doing what they are doing and what influences them that I would suggest are missing.
e.g. in the attached image I presented to Merck the difference between the ‘what’ data (on the right) and ‘why’ data on the left.
Since we had based our marketing strategy on customer needs we had to understand what created needs (because it’s needs not e.g. convenience that motivates action. Convenience only helps the solution get out of the way when the person is already motivated). The information on the left (from anthropology) is a crude simplification of some data points we would benefit from having access to in order to better understand what creates and drives / motivates people to action.
We later simplified the ‘why’ data to insights we could capture by designing our experiences to capture them (e.g. if people are learning when participating in our learning session)
Love this graphic showing the difference between thick & thin data @Helge. Thick data reveals the deeper insights about why people act/react the way they do, and the thin data covers the observation of those behaviors driven by their motivations.
We would use our available quantitative research to identify what the customer valued. Then we would use the super power of our data and design creativity to figure out how to design experiences where we would naturally capture these measures from the customer.
So in our case that would mean if the physician was ‘learning’. So we would need to design learning experiences where the physician got some questions at the end to test their knowledge and then from their answers we could gage if they had learned. We could then also measure the time it took for them to learn and then the two measures of value would be: a.given that learning has happened b. how fast can we make learning happen.
This “customer value measure” were put into a chain of measures where we would start with measuring the quant. and qual. values of engagement, then if quality engagement led to customer value, and then if the customer value led to a behavior change that led to business value (which I think @Bryan has shared earlier).
We built this into the strategy framework as well (if not I can’t see how it will work), which made it into the enterprise wide framework where 5000 marketers across 100 markets would be using it .. (so that is pretty cool).
For me this journey started back in 2017, when I put this together .. and have been trying to find like minded people crazy enough to share the same dream ever since .. (or to kill it as Astro Teller would suggest): https://www.agilecustomerthinking.io
Circling back to your chain of measurement, seems like what we are trying to do with Design Signals in a fluid way across project work in high volume. Lot’s of overlap.
In Glare, we’re pushing the bigger, more systemic alignment to lead so as not to get in the way of the continuous, iterative learning.
Tagging a couple folks who I think might find this interesting:
(or to kill it as Astro Teller would suggest): 
