“We saw your cautions about demographics in personas versus deeper motivations that transcend the easily visible segment — and how Jobs to be Done similarly helps us focus on underlying motivations.” Weston Thompson
How do mental model diagrams compare to Jobs to be Done, or to Outcomes? I think they’re similar in some ways, but different in extent. My opinion is that JTBD implies tasks that a “user” wants to do (make a hot beverage), and does not quite reach for the overarching “outcome” they are aiming for (fortify myself for the afternoon meeting–which can be done via different methods than hot beverages). I think inexperienced practitioners will circle right back to “how does the customer do their task using this tool.”[My definition of problem space is slightly different than that used by product managers. I define problem space as the larger intent or purpose, not the task nor the goal. The larger intent or purpose has only to do with the human mind and not with the services or tools. Tools of the age don’t matter to me, so I can get useful data for the same research project from people in 1879 or in 2016.] By my definition, JTBD falls squarely within the solution space. Examples I’ve seen tend to focus on purchasing products and services. This is fine for solution space research, but does not get at the larger things a person is aiming for, which usually go beyond purchasing.
Still Focused on Solution Space
Product managers and UX practitioners are, as a by-product of the business framework, still focused on the solution space. Curiosity about the larger problem space is rare. For example, when I ask a practitioner about the research they’re doing for an internal tool that supports around 300 salespeople, they say:
- We’re looking at similar generic, publicly-available tools.
- We’re asking stakeholders what their goals for the project are.
- We’re examining how some of the sales people do tasks like entering client data
But the larger arena outside the business framework holds more opportunity for breakthroughs and helps organizations focus their resources more successfully. In the above example, I’m wondering about problem space aspects like:
- What are the shared vocabulary, habits, and intentions among those 300 salespeople?
- How they talk to each other about their clients and their own successes or failures?
- What are trends they’re reading or talking about?
- What do the clients have in mind as they seek to achieve their purposes?
Based on this potential deeper understanding about how people are thinking (their cognition), the practitioner might realize that the tool they’re improving just doesn’t address certain aspects. Or they might be trying to address intents that are better left to another set of methods entirely, in which case the organization is mis-spending its resources. JTBD is fine for researching within the solution framework for these salespeople, but it misses the larger problem space, which is where you may discover new strategic opportunities for supporting these salespeople.
Transformations within the Mental Models Approach
“From what I gathered from my online research, it seems your method has changed slightly since the publishing of the Mental Models book. You’ve moved away from tasks, implied tasks etc. to reasoning, reactions and guiding principles. You’ve also renamed it to Problem-Space Exploration. How has your thinking evolved and how has the method changed as a result over the years?” Sonja Bobrowska
It’s true that a few months after Mental Models was published, I abandoned the vocabulary of “task.” It was just too loaded with prior meaning. Practitioners wanted to create mental model diagrams that depicted how a person interacted with a tool, rather than what it was meant for. For example, they would explore how a person bought a car and the reasons why they might have shifted from one make and model to another. They didn’t explore why the person decided that buying a car was on the agenda in the first place. Nor did they explore what the car was for. What went through people’s minds as they ran errands, commuted to work, or took longer trips–by car or transit or other locomotion? What’s the bigger picture in terms of intent, purpose and cognition? Can you support these intents with very different solutions? Can you support different thinking styles with different solutions (supporting diversity)? These latter questions are the ones I’m pursuing with this kind of problem-space exploration.
In the years following the publication of the book, I worked with some practitioners and clients who wanted the diagram to invoke more empathy in the reader. It felt kind of dry. So, we did the following:
- Instead of capitalizing all the words in the boxes of the towers using title case, we switched to sentence case.
- I was already incorporating a vocabulary word or two from the transcripts, but we added whole turns of phrase.
- We experimented with making the summaries longer, adding specific detail from the context of the participant. (At one point we made them too long, making the diagram harder to read and more time-consuming to understand. So I’ve pulled back a little since then.)
- I have been encouraging teams to do an initial study with just 10 participants so they can prove to themselves it’s useful and doable. As a result, the boxes in the towers represent only one voice each. This means each summary is a little jewel version of that person’s thinking in a particular context.
As a result, mental model diagrams today contain bigger boxes in the towers than ten years ago, painting a picture of individual thoughts and emotions. You can develop empathy just by reading these boxes, and this is how cognitive empathy can work at scale within an organization. (See my additional comments in the next section of this newsletter.) Simply reading the boxes in a few of the towers that someone passes around will help an employee develop cognitive empathy for the people the organization is trying to support.
Vocabulary transformations within the approach include:
- Task >>> Reasoning/Thinking/Inner Voice In Mental Models, I defined task as “a phrase stating an action or step to accomplish something.” I described it as “actions, thoughts, feelings, philosophies, and motivations as a person accomplishes something.” So it was super-set of all three types of concepts that I comb from transcripts now. The things that are not feelings or philosophies have now turned into a richer representation of a person’s cognition–their inner voice. What went through their mind as they sought to achieve a particular intent or purpose? I used to differentiate between a concept that was clear and one that was implied. I don’t do that anymore simply because it isn’t important to earmark them. Much of what a participant says is implied. Who cares? You are the detective who will pick out the underlying reasoning and write that as the summary of that particular concept. I also used to include “third-party” concepts, which really hasn’t changed. The frequency of occurrence is low. It’s rare that a participant describes the thinking of another person they know.
- Feeling >>> Reaction Some of my clients felt uncomfortable with the words “feeling” and “emotion.” I substituted the word “reaction” to mean the same thing. So instead of asking a participant, “How did that make you feel?” a listener would ask, “What was your reaction?” Having a reaction to something feels more comfortable in certain industries, so I adopted the vocabulary word overall.
- Philosophy >>> Guiding Principle There was no problem with the word “philosophy” itself, but often I’d describe it as a “belief.” Then all sorts of confusion would result–practitioners would see phrases in the transcript like, “I believe that our team’s productivity is faltering,” and they’d think it was a philosophy rather than the opinion it really is. A philosophy (or “guiding principle” as I re-named it) is something that you use to make decisions in all sorts of contexts. “Try to meet every obstacle head-on” can govern your decisions in relation to resolving a problem with your cable TV, handling an irate customer, or dealing with ongoing back pain. A guiding principle can be a big foundational philosophy like “accept suffering as inevitable,” or a smaller version like “avoid the hospital.”
In the past year or two I’ve focused on the message that this kind of research is one tool of many in your toolbox. To define when to use it, I’ve highlighted solution space versus problem space to help practitioners see its use. There are a lot of knowledge-gathering tools out there that can be applied in different circumstances, so it’s good to be aware of all the different circumstances in your own work.
“What we are effectively trying to do is operationalize empathy. By defining methods for human-centered decision-making, we are turning these monsters made of people [i.e. organizations] into something a little bit more like people.“Jesse James Garret, 08-May-16 talk at IA Summit
“Defining a desired outcome requires a deep understanding of users’ problems.” Hoa Loranger, Minimize Design Risk by Focusing on Outcomes not Features (IY: I would swap steps 1 and 2 so that it’s less about “proving” something and more about discovery.)
“Design and its value in problem-solving have become widely recognized aspects of business and innovation processes … Empathy is now considered a necessary precursor to responsible design process … immerse ourselves and our clients in the activity at issue (or an analogous one) and mindfully acknowledge our emotions as the experience unfolds. This direct engagement enables us better identify the cues that signal confusion, stress, or pressure, which we then discuss and reflect on together as a group. This immersion can never be a replacement for observational research, just as we can never be the user, but we find that it is a vital compliment to what we learn through more traditional methods.” John Payne, What’s So Funny ‘Bout Peace, Love and (Empathetic) Understanding?
There was a talk at UX Week 2016 by Katy Mogal, Can You Feel Me Now, which emphasized acting out a person’s life. One of the questions after the talk was, “How do you use this kind of immersion to do design empathy at scale?” Not everyone at an organization will take the time to be another person. There’s a focus in UX on empathy as feeling the emotional reactions of the person you’re designing for, and trying to loosely take those into account. I have a narrower the use of affective/emotional empathy in your work, and I pair it with it’s twin, cognitive empathy.
Another example of the focus on emotional empathy: “To build empathy with users, a design-centric organization empowers employees to observe behavior and draw conclusions about what people want and need. Those conclusions are tremendously hard to express in quantitative language. Instead, organizations that get design use emotional language.” Jon Kolko, HBR: Design Thinking Comes of Age
“[Complimentary behavior] means that if someone greets us with kindness, we’ll likely respond the same way. Conversely, if we’re faced with hostility, we’re more likely to flare up and fire back. But there’s a way to break the cycle: non-complementary behavior. It’s much harder, but it can make all the difference.”Katherine Ellen Foley & Akshat Rathi, Researchers say one of the most powerful tools to diffuse hate is the hardest to master: genuine empathy
“When people do not get the empathy to which they feel they are entitled, they get enraged. Empathy break downs are experienced as dignity violations. … response to empathy violations is narcissistic rage – an irrational, destructive anger designed to get one’s own back, often even at the cost of self-defeating behavior. … the lack of empathy as a boundary issue or even a boundary violation, including a dignity violation, then the response is narcissistic rage in an attempt to get back one’s own and re-establish the boundary. … it is a common response. … When empathy breaks down, people go off, get angry, get weird – and do not even know why or what is going on.” Lou Agosta, Empathy on Bastille Day
What’s our best fit?
“We’re trying to explore the problem space, but we’ve run into problems. Can you double check what we’re doing?”
“We want to make sure we do the research right. And we want the skills in-house so we can keep exploring.”
mentor the team
“We want to explore something, but we don’t have the cycles to get involved. We want answers that are credible.”