Zack:               Hey everybody. Welcome to this week’s episode of the Aurelius Podcast. This time around we have Indi Young as our guest and what a wonderful conversation we had with her. Indi has been doing some very deep thinking with a ton of experience in the research and synthesis and empathy space, within our field of design and UX for a very long time. We had a conversation with her where we talked about what she’s doing now, what she calls problem space researcher. We actually talk about the difference between problem space research and solutions research and why that matters. We then get into what a lot of Indi’s recent thinking has been about which is thinking styles in research and then how we apply those things in design. We cover a number of topics ranging from how artificial intelligence can help create emergent experiences in the future, different types of empathy and even tactical examples of how we can make better sense of what we learn from user research to make better design and product decisions. This was an awesome episode from a very awesome, a very smart guest and someone I’ve had a ton of respect for, for a very long time and I think you’re really going to enjoy the show. Just one more shout out that I want to let you know. We are actually still in beta for Aurelius, our user research and insights tool for design and product teams. You can go and sign up for beta right now and the reason I mention that is because we’re actually getting ready for our public launch where we’re going to start charging for the product. If you’d like to get in and check it out for free, see what we’re up to, just head over to our website, sign up and we’ll send you an invite. With that, let’s get on to the show.

Welcome to Aurelius Podcast, episode 15, with Indi Young. She is a problem space researcher, author and consultant. Indi, welcome to the show.

Indi:                Thanks so much.

Zack:               We’re very glad to have you and I know I can speak for myself, and many others. I’ve been following your work for a very long time and I would say for me, probably close to 10 years after I read your book, Mental Models, and was implementing that at the company I was working for at the time. And very grateful for that. Again, honored to have you here.

Indi:                Thanks so much. It’s been a long 10 years, I guess. We were talking earlier about where you met up with me at one of the conferences.

Zack:               Yeah, UX Week – 2010 I believe it was.

Indi:                That is a good conference.

Zack:               It was a great conference. One of my favorites, all time. So, 10 years, what have you been doing recently? Tell our listeners a little bit more about the work you’re doing now.

Indi:                What’s top of mind right now is I’m kind of trying to get my next book started. You know how you get this sort of itch to do some more writing about something. The point that I want to try to do is combine this idea of supporting non-dominant thinking styles, which comes up in the diversity arena, with product development – with technology. And trying to sort of draw a line, make a case that these are two of the same things. And then on at least the technology product side, make a case for the idea that problem space research can really support those efforts. Can really actually sort of define the pathways that you can follow and there are many, many pathways, but it will help you delineate which ones there are and help you have a discussion about prioritizing those.

Zack:               That’s great. We’ve talked about this a couple of times now and you even described yourself as a problem space researcher. And I can imagine that even the people listening to the podcast might say, “What does that really mean? How would I know if I’m calling myself a problem space researcher?”

Indi:                Theoretically, if you’re listening to this podcast, you’ve heard of the phrase solution space and the phrase problem space. You’ve heard of design thinking. You’ve heard of the phrase fall in love with the problem. It all sort of has to do with really focusing on the people that you’re trying to support. Oftentimes those people are called the customer, or the user, and what I’ve been trying to do is separate that out a little bit farther. I think when we still refer to people as customers and users we’re looking at them through the lens of our offering – through the lens of our organization, what we do to support them and how we think about them. All the knowledge we already have about them, but it tends to force us back into the mindset of problem solving. It tends to encourage us to come up with new ideas; do idea generation, innovation work, that kind of think. It’s where I would like for us to insert a little bit more knowledge that has nothing to do with innovating, that has nothing to do with idea generation, that only has to do with understanding. This is what my second book was about, Practical Empathy. It’s the idea of taking that first step in design thinking, which is called empathize, and snapping it off and making it not a part of a cycle; not a part of something that you go around and around on to improve a product, or even to come up with new ideas or new directions for a product where you’re then prototyping and testing – where the very next step is the exciting step. I think everybody gets credit for good ideas and it’s exciting to talk about ideas and a lot of attention is paid to ways to generate ideas. I know Christina Wodtke, on your podcast earlier, was talking about not doing brainstorming where the loudest voices or the most extroverted people will have their ideas out there, where she does sort of quiet idea generation on sticky notes and then these ideas of having to create a number of ideas in a certain amount of time, etc. But all of this focus on ideas is I think very tempting for people to just skip over the understanding part. So, the reason I’m snapping it off and trying to make it into a completely separate cycle – I have diagrams about this on my website, and actually in the book practical empathy, is because if you think of the problem space just as understanding a person, not understanding a user, not understanding a customer, not a member, not any of those words that you use to reference the people who have a relationship to your organization – if you just try to understand a person, you let go of your need to solve problems. That phrase, fall in love with the problem, is like in a way it really starts to fade into, or edge into, fall in love with solutions for the problem. Fall in love with solving the problem. There’s that shadow word “solving” in there which puts it still in solution land, right.  So, actually instead of that phrase, fall in love with the problem, I like to say build an enduring relationship with the problem.

Zack:               Okay. This is a very interesting term.

Indi:                Everybody loves falling in love. Falling in love is fun.

Zack:               It can be. It cannot be too.

Indi:                It cannot be too, but it’s a thrill. We can say it’s a thrill, positive or negative.

Zack:               That’s true. It does release endorphins which we all enjoy. That’s absolutely true.

Indi:                But the building of the enduring relationship, the thing that lasts over time, the thing that enables you to understand the other person and live with the other person and work with the other person, that takes work. That takes effort. It’s hard.

Zack:               Definitely. So, this is really quite curious for me. It sounds to me like you’re advocating for almost more kind of point in time, much deeper, but longer shelf-life type research. And it sounds to me like this is tapping into the philosophy of a person, or a group of peoples which is perhaps more important. To kind of bring it back to a more tactical place, because I think that helps people understand things sometimes, even accessibility is a perfect example of this, right, where the things we build have to be accessible to all peoples and so because of that, starting with an accessible point of view in mind first, actually helps us realize how the way in which we’re building things should be. Perhaps fundamentally different than the point of view we have which, of course, if we take the next level deeper, we can say well that’s what research is all about, so we can move beyond the point of view or perspective we have. But again, please keep me honest. It sounds like you’re advocating, which to my excitement I hope I’m summarizing right, because it sounds like you’re advocating for almost trying to – as you would say – codify someone’s philosophy. The people you’re trying to serve. Not focused on the problem, but just focused on them as people and understanding themes and patterns across that as opposed to focused on how you can solve a problem.

Indi:                Exactly. That’s really well said. As you were talking what ran across my mind is Sara and Eric’s book, Design for Real Life, they talk about stress cases as opposed to edge cases. What they’re trying to do is come up with some accessibility and also, in a way, contextual situations where people might not be behaving the way that your “average (which never exists) user” wouldn’t behave. What I’m doing is codifying that. I am allowing people – and I’m calling them thinking-style segments – I’m allowing you to take some primary research and understand what different thinking styles might be out there. Now, you can’t understand all of them, but you can understand a set of them that you are most interested in right now and then later on let’s go find out some more. For example, I did some research for an airline. This was a unique case. They actually did 8 studies within the course of 14 months – very rare. Typically, people will do one study like a quarter or a year.

Zack:               Or longer.

Indi:                Yes. But during the course of these 8 studies we came up with four different thinking styles that kept replicating, kept getting confirmed over and over again. What it helped the designers understand was that they were designing for one thinking style. And maybe that’s okay. Maybe that’s fine because business-wise that thinking style … Wait, let me tell you a little bit about the thinking-style segments. I’ve written this article called “Describing Personas” which is all about trying to get away from demographics. I know that you wanted to talk about that.

Zack:               Definitely.

Indi:                The thinking styles represent – like in this airline example, one of them represented the person who trusted that the airline is going to get them from point A to point B, reasonably time-wise. So, they’re kind of Zen about it. They’re laid back. “Okay, I’ve sort of set this whole day aside.” And that’s the one that they were all designing for. There were two others. One is called the Frustrated and one called the Just Get Me There who had different approaches. The Just Get Me There treated the airlines as a bus, like a bus in the air. So, they’re like getting to the airport at the last minute, trying to get their meetings done, crushing in this extra meeting before they actually leave for the airport. That’s all within the realm of a business passenger, who is the airline’s big focus.

Zack:               That was the first thing I thought of, totally.

Indi:                You would look at these contexts also within the realm of vacationers and your context changes. So, you might be the Just Get Me There for business, but you might be one of these laid back Zen people when you’re taking your toddler on vacation.

Zack:               We had this brief conversational-like pause moment (for those of you who can’t see) and the reason for that was because I finally clicked with what Indi has been talking about with this idea of thinking styles. This is like a bombshell of brilliance on my head right now because what we do – I won’t speak for everybody, but the way I’ve done research in the past is I want to find the commonality between what people are trying to achieve and what they’re trying to understand and what outcomes they want. Whereas what you’re saying is there is this thinking style which is perhaps an entirely other dimension which either we have neglected at worst, or at best touched on tangentially, which is to say actually those commonalities can be split, or fractured if you will, in different ways depending on context and if you were to focus on the way somebody is thinking about their life and their outcomes, those things have different combinations.

Indi:                Yes.

Zack:               And I realize I’m talking in very broad terms right now. So, I guess what I’m saying is if you’re writing a research report about this stuff, you want to report on here’s the themes we found – I think that’s a very logical and sensible step, but what I’m taking from this is if you focused on thinking styles you can say, “Here’s how to know how to combine these insights or these themes based on the context.

Indi:                Exactly. And based on the phase (a.k.a. mental space) of what people are going through.

Zack:               In time?

Indi:                Phase of approach. So, as a passenger you might go through a phase that’s like “what does it take to get there?” Right now, we don’t have any tools that allow you to figure that out, except to pretend that you’re making a reservation. Or you might be in the phase where you’re like “okay, I have to get to the gate on time.” Or, “I have to figure out how to get a seat that I like,” or something. And you could be going through that phase in a number of different time points, but your thinking style, your context and your phase is going to intersect. And those combinations are the combinations that then your organization can say, “okay, I want to focus on this one, this one, this one and this one and not those for right now. So, I’m going to keep us from falling into that rut.” And the other thing I want to do – so, here’s where I’m sort of going forward with this is machine learning. Machine learning is this whole idea where the developers are like, “Oh we have all this data, and the data is going to tell us how to treat each person differently.”

Zack:               Well – okay.

Indi:                Theoretically, it could lead to emergent experiences.

Zack:               Provocative.

Indi:                It could lead to the machine having a listening session with the person interacting with it and adjusting the way it works for that person. But, to do that, that machine, that algorithm, needs to understand its own boundaries, where it cannot adjust or understand. Where there’s going to be a limit. Right now, we only have one algorithm and it tries to serve everybody. What happens is that it assumes it can do everything. It doesn’t assume that it has a boundary. When you run into problems and you’re getting frustrated with it, it is like, “La-la-la, I’m serving you perfectly.” Because it doesn’t realize…

Zack:               Yeah, totally. It keeps pumping in the things that you say that you like. I am not trying to get us in a rabbit hole or anything like that, but we have a beautiful socio-economic case study here in the United States about that exact thing happening, even with our own political elections this past year. That exact thing very much happened where there is even an investigation going on right now as to whether or not there has been influence over that, knowingly, that that could possibly occur. This is interesting to me because you’re staying on the bleeding edge of our responsibility as people who are serving these people. Hopefully, for the better, but knowing that these things can take a different turn. I kind of want to take a step back and share with you what I had in my mind as you were describing some of what you were talking about, as like a very tactically applied piece to what you were describing. So, you were saying modes of thinking, right?

Indi:                Thinking styles.

Zack:               And at certain points, so sequences. What I had in my mind was almost something similar to a service design blueprint or a customer journey, but rather those touchpoints could have a 360 view based on thinking style which is a curious application of that because as you said, then a business could come in and say, “Actually, yes, this one covering the 360 point of view of that touchpoint, or that moment in time, or that moment in sequence, is extremely important to what we’re trying to do in the experience we’re delivering.” And hopefully balanced by saying, “This is also very important for that person, and we can tackle that.”

Indi:                Yeah. That makes me think of a conversation I had a little bit earlier today with someone who was talking about how he used a mental model diagram. Actually, it was an opportunity map. So, it had the capabilities of his organization mapped underneath the towers. It was a piece of enterprise software and they were trying to support internal people who were doing configurations for external clients or customers. So, that was what the opportunity map represented, and he said he loved that it was so simple, that it was not as complex as trying to do touchpoints and three dimensions. It just showed the one dimension – well, I guess it’s two-dimensional really because there’s a line – one dimension would be a point. [laughs] But anyway, it showed this line and it allowed him and his developers to recognize that they were talking past each other. It allowed them – without any words being said you can look and you can go like, “Oh, oh, right. Okay, wait. So, because this thing happens three or four times throughout the whole process, and it is sort of the same thing, doesn’t mean that we want to put it all in the same place in the interface.” So, it was the idea that they were looking at it very simply, I guess, that allowed them to see that. For that case, that was a communication win. That was the ability to get people on the same page, which it worked really well for. I think the idea of doing maybe a journey map with touchpoints and stuff, and having this data layered in, would also help with kind of the innovation side of things. I personally don’t have that much experience with journey maps because for the past 10 years I haven’t been designing anything. I’ve just been helping people get knowledge, get really deep knowledge and learn how to add to it and learn how to use that knowledge. Learn how to apply it. Somebody was saying, “What we do is we cup our hands around this section of what we’re looking at, and now we’re going to have a deep discussion about this particular thing. We’ve got the way that these three thinking styles are approaching this same phase and we can talk about different contexts that they’re in.”

Zack:               Yes, okay. It’s at this point where I realize there’s a couple of things I think we should clarify for people listening that would be useful for them to not only distill, but apply what it is you’re talking about. Even very briefly, we have mentioned mental models a couple of times. I can imagine there’s probably some people listening who maybe don’t know what that is. So, the 60 second version of what a mental model is?

Indi:                A mental model is defined a lot of different ways. The definition I’m using is that it’s a model that your team holds together of the way the people you’re supporting think their way through to a purpose. It looks like a city skyline with a bunch of buildings in it. Some buildings are tall. Some buildings are short. The buildings all have boxes in them. The boxes actually represent what’s going through people’s minds. This is where the empathy part comes in. My second book is called Practical Empathy. There are also many definitions of empathy. I use two of those definitions. I do not use emotional contagions, but I use emotional empathy which in a listening session, when you’re trying to draw a person out, trying to get that person to tell me their inner reasoning, their reactions and decisions they’ve made based on those reactions and their guiding principles. And to get deeper than explanation. Get deeper than statements of fact and explanations and opinions and preferences, which is what a lot of interviews are about. This is how I do it, this is why I’m doing it, but not my inner voice as I’m doing it and the little things that go through my mind.

Zack:               The gold flakes that surround all of the answers somebody gives you.

Indi:                Exactly. To get at those you have to use emotional empathy which means to recognize and be with that person in their emotion which is like, “Who the hell are you and should I trust you and do I want to tell you my inner thinking and what the hell do you mean by this? And are you going to laugh at what I say? Or are you going to judge me?” And the more you support the person, the freer they feel, the more trusting they feel. I have gotten so many people telling me, after they do these listening sessions, that the participant thanks them because they’ve never had a chance to unburden themselves of all the inner chattering that’s going on in their head.

Zack:               So, even right there, Indi, I have to stop and pause and just say for anything listening to this podcast, if you took nothing away from how you can do your work better today, is that when you talk to customers, truly, truly, listen and show that you’re there to support and understand them and nothing else and I promise you your work will get better. Because it’s such a profound thing.

Indi:                It is. Nobody gets to be listened to very often.

Zack:               Yes. And particularly in our culture. We are US based and in America there’s often a saying where in a conversation most people are just waiting for their turn to speak, rather than listening to the person speaking. And I think that that’s very true and why empathy has such a powerful like impact when we actually see it happen. Okay, I’m going to go back…

Indi:                So, wait. I want to hop on that for a second. That is emotional empathy and I use that in the listening sessions when I’m trying to collect this information so I can then develop empathy. There’s a difference between applying empathy and developing empathy. Everybody wants to jump on the apply empathy – I want to walk in their shoes, right? But, how do you get in their shoes? You have to develop the empathy first. You use emotional empathy to support them, to collect the data, but then you use cognitive empathy to go through the transcripts that you get and piece together what they really meant to tell you. They will say a thing one way in the beginning of the conversation and mention it again in a slightly different way and again and again and by the end of it you’ve got a clear understanding of it–while you’re in the conversation. But you walk away half an hour later and you can’t quite remember exactly the brilliant clarity of it. So, I go back to those transcripts and I pull those concepts together and I get that brilliant clarity and I stick it there in my spreadsheet. Then I get to compare that to somebody else’s approach and I look for affinities. And I build those together. Those then become the towers for the buildings in the city skyline and the boxes represent their words. The boxes are actually how you stand in their shoes.

Zack:               Yes. My follow-on question–you went there without me even asking–which is to say okay, so we get this, we use this as Indi would say, emotional empathy to gather the data. We use cognitive empathy to apply it. That was going to be my next question is to say that’s great – we go out and we talk to people. Let’s say we’ve sold our stakeholders on the fact that research is important and we’re trying to do that really, really well and we use the emotional empathy to gather than really rich data, the gold flecked data as we were talking about – cognitive empathy to apply that, right?

Indi:                Right.

Zack:               And this becomes what? I don’t think that there’s really anybody listening to this that would say, “Yeah, no, that doesn’t make sense to me.” That’s exactly what we should do. That’s brilliant. But we have to share this, empathize, even with the people we work with to help them understand why this is important for them. Even on a personal level, why it’s important for their job or their company, but also it’s important for our customers. So, how do we do that?

Indi:                That’s why I’m trying to write this next book.

Zack:               Well great. Let’s dive into that.

Indi:                Not enough of it is being done. We’ve–at least in the US–had our noses sort of smeared in the fact that our digital world is not rosy, and we’re responsible for it. To one degree or another, maybe even just bystander-responsible for it, but that’s still responsibility. And we’ve got to fix it. How do we fix it? How do we communicate the value of it? One of the ways is to understand what’s on the minds of the people that make the decisions about the budget? A lot of people say you have to learn the language of business. I personally do not know the language of business and I should learn it. It’s one of those areas that completely falls off of me.

Zack:               May I add something to that? It’s really interesting. Only because you brought it up. It’s something that’s been on my mind, and has pervaded talks I’ve given recently as well, is this idea that design is a business. So, the reality of it is design is a business that serves this overall umbrella of business as well as anything else. And as soon as we started treating it that way–and some are better than others, as you might mention–the sooner we start treating it that way, the more effective we can be. So, I guess, simply what I’m saying is I actually think that you’re probably better at the business thing than you give yourself credit for because people are people and you understand people really well, right? People have needs. We talked about at the beginning of this, people want to be loved. Everybody likes to fall in love. So, if we can just understand sort of what motivates people and we can help them see why serving other people is good for them.

Indi:                I think the problem with business, the problem with tech, at least, is that in a way it’s all ROI based. Sara’s book, that she just put out, Technically Wrong, talks about this. I was just talking about this subject with a developer friend of mine. Thinking beyond the ROI, thinking beyond the metric, thinking beyond the profit is not something that is pursued. It seems as if it’s tightly tied to this idea of being able to support people, and especially being able to support people who are of the non-dominant thinking styles.

Zack:               Yes.

Indi:                Let’s say – take it outside of technology. Let’s say we’re an insurance company and we’re just going to look at having auto accidents. There are different thinking styles around auto accidents that happen in different contexts. There’s this “let this be a lesson, to the other guy, or to me.” Or there’s the “downplay it” – this will never happen again. That was a really perfect storm sort of accident thing. There were a couple of others as well. But, to tell an insurance company who is focused on profit, who is focused on being able to pay off all of the hurricane or wildfire claims, to tell them, “Oh, hey you could support the people who want to ‘downplay it’ differently than the people who ‘want this to be a lesson.'” They’re going to say, “For what reason?” So, what I have to do is tie it to market potential somehow. The argument goes (the developer friend of mine was telling me) we can solve the problem for most of the people and maybe 20 people it’s not going to help them – whatever. And I’m like those 20 people could represent 2,000 actual human beings. Or maybe even 200,000 or 2 million or 20 million actual human beings and you’re going “whatever” about them. So, what I really wish is that the rest of us … because we are developing so many more coders and so many more talented young people, let’s have those young people have the freedom to go out and design apps for the 2 million people who aren’t being served, right? Why is that not happening? There is a vacuum, they call it, right now. Those 2 million people are not being served by any of the apps that are out there right now, or any of the services, but there is no choice for them. There is no alternative for them. If there were, if that alternative appeared in the market, those people would – like iron filings to a magnet. So, why is nobody pursing that? I think the young people probably see it and could pursue it, but maybe just don’t have the money. I think the startups are run by venture capitalists who really have their minds in a different place – most of them.

Zack:               That’s a very democratic way of saying that, by the way.

Indi:                They’re all still running by the metric of profit ROI. Right?

Zack:               Um-hmm.

Indi:                Do you remember the argument about the long tail? It used to be with bricks and mortar, you could only have so many products within a certain amount of square footage and so you had to make decisions about that. And now, since it’s online, it means that we can go and have so many more products and serve like so many more people. I think this argument applies here. It’s a slightly different argument because we’re not talking about square footage. We’re talking about thinking styles. And we’re talking about front end software. We’re talking about experiences, that if we have this machine learning future, where we do have emergent experiences, then we want those emergent experiences to support that other 20 or 20 million people.

Zack:               And it’s almost like – I don’t know if this does it justice, but to summarize a bit of what you were saying, this self-imposed restraint which is so important, I think, in the field we work in. And I assume of course that people who are listening to our discussion are in the technology or software field. I think the majority are – this self-imposed restraint, this self-imposed focus. I think we could have a whole other podcast that talks about the reasons why that’s very hard for us, particularly in the United States, because that gets into politics, economics, sociology, all of these things. But yes, if you are able to do that – and I like to go back to, just kind of throwing a shout out to some folks we admire over at Basecamp, formerly 37 Signals – David Heinemeier Hansson and Jason Fried. They talk about this kind of thing where it’s like you don’t have to build a company to take over the world. That doesn’t have to be your aim. You can build a company, or an organization, or a product, or a service and all those things it just simply serves a need really well, better than anything else that currently does that.

Indi:                Right, right.

Zack:               And allows somebody else to tackle that other problem, as you’ve said, that clearly still will exist and is actually a very scalable way of doing it.

Indi:                Maybe this is a William Gibson or a Kim Stanley Robinson sort of a future. One of the things I was bemoaning the other day is that we’ve got so much dystopian entertainment and we don’t know how to think optimistically about the future. But those guys sort of can show us some interesting things about the future and maybe collaborative groups, being able to create things. The idea that you have to have big capital to create something – we know it isn’t true and yet it still pervades. We still have this myth about starting in a garage. Adaptive Path, we started having weekly meetings in each other’s living rooms. You don’t have to have capital, but yet there’s this myth in Silicon Valley that you have to go – I don’t know, raise funds? Maybe not. Maybe not. That’s why I have so much faith in the new generation. Maybe they’re unsullied by this. I don’t know.

Zack:               I’m going to go on record and say it’s horseshit. I completely agree with you. I’m not going to get too political or socioeconomic on this, but I think it has a lot to do with American culture that has create a Westernized culture, as to why we feel like this massive, big bang, bottle rocket on steroids kind of launch and like coming to terms of a business needing to exist. That’s not true. You can build an honest, stable, problem solving thing that is more reliable than anything else that you’ve seen.

Indi:                It doesn’t get the huge media coverage. (Why do you need the media coverage?)

Zack:               But you know what, it solves your problem better than anything else has. The thing that’s really interesting about that is: that’s exactly who we are at Aurelius. And part of what we’re doing is not only just building software or something like that. Like that’s fine – I don’t mean to trivialize our product. I think what we do is great, but the other higher level – and since we’re talking about philosophy on this discussion, it’s important to us that we do this and we do it well, as an example that you can without the funding, without the big PR releases, without X Y and Z, to simply say we’ve understood people – knowledge drop on my head: people’s thinking styles – and serve them really well in a certain space. And not “everybody prospers” as a result.

Indi:                “Serve some of them pretty well.” You know there are a bunch of organizations that are going in this direction. Like Code for America, UX for Good. There are a lot of organizations. This one with the folks in the UK government digital office. They’re doing it down in Australia as well. There are people working on this that aren’t sucked into the glory of the giant IPO and blah, blah, blah. One of the examples – this is what made me start thinking about this. In Sara’s book, which is called Technically Wrong, one of the examples was about an application for tracking your period, and it was called Glow. It was originally about people who were trying to get pregnant. But for some reason the organizers of that decided that they wanted to serve people who also were not trying to get pregnant, but they didn’t change their interface that much. And then a student of Christina’s did a rant about that particular chapter and said there are some trans men who have periods. For example, if you go in the men’s room you’re not going to have like the little bin for your pads and your tampons. You will in the women’s room, but not in the men’s room. So, she’s all like, “Why are you making this application pink?” I think the application owners could have just focused on people trying to get pregnant and then okay, let’s do thinking styles within people who are trying to get pregnant because there are probably a lot of different thinking styles – significant. And why is like this student not encouraged – not as if I know anything about this student, or their resources, or the amount of time any of us have – but why couldn’t that student have access to resources go and make the period tracker for people that could include trans men? For people who are not trying to get pregnant and not into pink and all of that sort of thing, who have other reasons?

Zack:               Very, very separate, very distinct thinking styles, that almost, through this conversation, may be averse to another mode set of thinking styles. Is that fair to say?

Indi:                I don’t know enough and I have not done the research. The theory was that they were trying to correlate mood with period, or see if there was a correlation and I don’t know what the purpose was. There was probably a purpose, like, “I feel like I’m depressed all the time and why am I depressed?” I don’t know, but there’s got to be a purpose and that was like one thing that they were doing towards that purpose. I don’t know what the whole scenario is there, but it’s a good example of like, hey, there’s someone who recognizes this and could go out and do a little bit of their own research and like cobble something together and get some friends together and put something out there. That’s probably what the app stores are full of, like little apps that work for that very particular thinking style, but what’s wrong with that?

Zack:               I have my answer to that, but I’m not going to actually share it. That’s an awesome set of ideas. For the purpose of our show, I’m going to use it as a segue of bringing us back to a certain line of talks.

Indi:                We promised each other we would try to keep it short.

Zack:               That’s true, but I’m enjoying this conversation. So, we talked about thinking styles and we talked about problem space research, right?

Indi:                Um-hmm.

Zack:               We talked a little bit about what that means and focusing on the deeper, longer term effects of that understanding of a person, rather than focus on the solution. So, this is great and I can imagine at this point in our podcast people are going I want to know, “How I can do that tomorrow? I need to convince the people I work with that we should do that–what they’re going to get and how it benefits them.”

Indi:                So, starting with the “what they can get and how that benefits them,” one of the ways that I go about figuring that out is to do listening sessions with my stakeholders. What’s been on your mind? What are you trying to solve? I will look across stakeholders and see the affinities. I’ll also see they’re saying the opposite thing and we’ll have to have a discussion about that. But that’s one place to begin. You’re not necessarily going to – it’s a beginning. You may then start to see themes that then you can pull together and say, “Hey listen, we can solve this by understanding a little bit more.” For example, with the insurance, there was actually a client that I had, and they were in an innovation center. (Most of my clients are in innovation centers because they’re the ones who get the budget!) But they were interested in trying to support a particular segment better. That segment was small business owners. “Within small business owners we didn’t know enough …” Basically, what the problem was was “we didn’t know enough to come up with – we had like all sorts of ideas for supporting small business owners, but which one would have traction?” Right? Which one would give you the most success going out the gate so that you could build on it later? To answer that we needed to know the thinking styles and we needed to understand the approaches that people were taking. All of the reasoning and stuff that went through their heads as they were trying to achieve a purpose. So, what we did was we set up a study where we scoped it down to where a purpose was: growing your business. We could have had different purposes, like just starting a business in the very first place. But it was growing your business. And within growing your business, what are the thinking styles? Within growing your business, what goes through people’s minds? There was a whole section on financing. There was a whole section on competitive analysis. There was a whole section on griping about the person who did you wrong – the vendor or whoever you’re working with, that kind of a thing, and trying to deal with the people who are going to mess you up. And those are not necessarily things that insurance is going to cover, but it’s going to help them understand, in addition to those things, the other very concrete areas that people are worrying about.

Zack:               Yeah.

Indi:                And be able to then come in with some product that will not only help a part of it, but there are several insurance companies who are associated with banks and could coordinate – there’s a really great example from USAA where they were looking at – I think it was auto claims. One of the things was that they thought at the end, when the claim was closed, that was a good thing. “We’re done. We got good marks for closing the claim.” But they found through this kind of research, that it’s not over for somebody who was in an auto accident when the claim is closed because they still have to recover physically. They have to recover emotionally. They may be feeling guilty about damage they did or an injury they caused. So, there’s psychological stuff going on too. They may also have to buy a new car because theirs got totaled and they may not be in a financial situation to buy a new car, or to finance a new car. And USAA is associated with a bank. They were thinking, “Could we not put a package together?”

Zack:               Definitely. That right there is like the answer to the question, right? It’s to say, “How do you apply this to your work?” It’s because we’re going to understand those places where we don’t know where we can offer things. That it’s good for our business to offer that. We won’t know those unless we do this kind of explorative research.

Indi:                They also changed metrics because they were measuring their success in ways that had nothing to do with the success of the person.

Zack:               That goes back to – you mentioned Christina Wodtke. She talks about OKRs. We talk about it as goals. That’s the way I’ve done it in my work. It’s all the same thing under the same name, but if you understand exactly what it is you’re trying to do and you can point to your design or your product or your research recommendations from that thing, all of a sudden, the clouds part, the sun shines down and it’s that moment of clarity as you’ve described.

Indi:                Right. Exactly. It’s eye opening. It’s also clarity for what you don’t want to get involved in. Or not yet.

Zack:               You know, it’s really interesting that you bring that up too because I think that’s often not talked enough about in the work that we do with research and strategy. I can’t remember who the famous quote is – maybe it’s Peter Drucker or Jack Welch – which is to say, “Good strategy is simply understanding the things you should say no to.”

Indi:                Right, exactly. Or say, “Okay we’ll do that later. Or, that’s for a spinoff. Or, that’s for this little set of people we’re going to incubate.”

Zack:               Yes! And so, you say you work with innovation groups. What innovation group ideas should we fund–we know that actually will have legs, but we know nothing about right now.

Indi:                What, can’t a corporation fund incubation? Why can’t a corporation do those kinds of things? Like bring groups of young people in who have this idea, as opposed to those young people feeling like they have to rely on venture capital?

Zack:               I had the very distinct honor to be part of an innovation group that was from a local service design company here and they brought together a bunch of people. I won’t actually name names because I don’t know if I’m allowed to, but their clients came in and one of them was actually from a large US based bank. This woman talked about exactly that and that’s how they actually funded their innovations, where they literally invited groups in of people who could traditionally be seen as potential competitors to them and say, “Build us a way that you would actually slice[?] our needs,” so to speak.

Indi:                Interesting. Also, you know how in sports they go out and scout, we could go out and scout, and scout in places that are not like the Carnegie Melons and Stanford’s, MIT or whatever. Let’s go out in some very small schools or very specialized schools. Let’s go scout in places where people have different thinking styles, different approaches, and see what’s cooking. And maybe something that’s cooking would be something you want to pick up.

Zack:               That’s definitely the crux of what we were talking about, that kind of thing and that bank that was doing that. It was actually very interesting to hear such a regulated industry was working in that way. Indi, I realize we’re coming up towards the end of time. To wrap this up, one of the things I want to ask you is if people are sitting here listening to our show and saying, “Indi, I agree with everything you’re saying, what are the top three things I should focus on tomorrow, next week, next month to do? To help our organization do the research in this way and apply it towards these.”

Indi:                The answer depends.

Zack:               Always in the UX space. [laughter]

Indi:                Where are you? How much power do you have? I don’t know that I can answer that that quickly. Doing stakeholder listening sessions. Picking up my book and learning how to do a listening session. Maybe you have all the power in the world and you want to just do this. Maybe you’ve got the power, but no team or no time. Hire me and my team to do it. There’s all sorts of different things you can do tomorrow. I think another thing though is to build your own understanding and vocabulary about this idea of non-dominant thinking styles and diversity. So, read books about diversity. Listen to podcasts, like Code Switch and stuff. Find out about becoming woke and see if you can learn something from that to apply in your own area. There is a group called Code2040 who’s focused on the computer science side of this, and bringing young people–they have Fellows and a Fellows program. You could get involved in that. There’s Black Girls Code as well. A little bit younger group – they focus on younger people. There’s all sorts of ways you can get involved on that side, too, with the younger folks coming on. But maybe just learn. Learn more. Open your eyes to it. That’s what I’m kind of going through right now because I want to have some framework and framing that actually exists out there to use in my new book.

Zack:               Okay. As my usual style, I’ll try to wrap that up in some kind of summary of what you said and again, please keep me honest. Start with understanding the people – practice empathy with people you’re working with and for. And then educate yourself on how these diverse and differing perspectives can actually help benefit stakeholders. And do your damnedest to sell them on that and then start doing that work.

Indi:                I like that.

Zack:               Good. You know what, I’ve got a decent track record so far. Fifteen episodes in and I’m summarizing these awesome, varying complex thoughts as best I can.

Indi:                I was going to compliment you on that. You’re good at summarizing. That is a skill.

Zack:               That’s a massive compliment coming from you, and I mean that very genuinely.

Indi:                I wanted to mention one other thing which is I just released a piece of software, a little app, that takes this kind of data and spits it out as a diagram. It spits it out as the top half of an opportunity map, the mental model diagram part. The part that looks like a city skyline. It’s up to you to actually start filling in that diagram with stuff below those towers. You can read more about that on my website. That is available to use and to talk about freely.

Zack:               Awesome. That was going to be my next question. Is there anything, for the folks listening to this episode, that you would like to share? That is definitely one of them. You have an upcoming book as well, I understand?

Indi:                Hopefully. Also, I’m trying to get a second edition out of Mental Models. It’s overdue for that. I’ve been trying for a year though and have nothing to show for it, so I really need to be serious about it. I’ve been doing a lot of podcasts and a lot of talks which have been recorded. Those are all on my website. You can spread those around. Try to get people talking about it. Also, if you have a UX book club, or even an internal book club at your organization, I will do free chats with your club after you’ve read the book–kind of do Q&A, or whatever. There you have it.

Zack:               Very good. And we are going to make sure that we include links to all of those things in our show notes. You just go ahead and head over to our website,, and the link to this episode with Indi Young. And we’ll make sure we have links to all of that stuff. I can personally vouch for Mental Models, version one, and I will look forward to version two whenever she gets around to it. It’s been very instrumental to my work and definitely contributed to where I am today. I’m honored to have had this conversation with you, Indi.

Indi:                Thank you so much Zack.

Zack:               We will see you next time. If you enjoyed this episode, consider leaving us a rating on iTunes or wherever it is that you listen to our podcasts and also you can fill out our podcast survey where you can let us know of someone awesome that we should have on the show and even tell us about the things you would want to hear about, topics that are interesting for you. You can check that out in the show notes, or on our website.

newsletter #34 | 20-Mar-2018

Every few weeks I create an estimate for a potential client’s problem space research study. Sometimes they want a ballpark*; other times they want a detailed line-item estimate, with a timeline. We discuss the options for balancing what they need with the overall cost. And 4 out of 5 times, after a few weeks they send me a crestfallen email saying they couldn’t get budget for the project, and that they will try again with the next fiscal year.

It’s a struggle. Given what I hear, it’s not just lack of budget for hiring an outside team to help with research. It’s also a struggle for teams doing research internal to a company.

A couple of years ago Mark Hurst wrote this widely-read post about budgeting for customer experience vs. advertising, where his key statements is summed up this way:

$25,000,000……Driving people to the website
$20,000…………..Customer experience (what happens when they get there)

On 10-March 2018, John Maeda released a report about Design in Tech, in which he references an NEA study by Albert Lee and Dayna Grayson saying that only 46% of late-stage (design mature) companies conduct qualitative research. Sam Ladner responded via twitter that, in her book Practical Ethnography, she cites that the majority of this is money spent on focus groups.

Focus groups.

So, how do we increase the proportion of money spent on design research? We can do this together, as a tribe, then share it with each other. Here are a few ideas:

1. Dogfood it: Do some qualitative research internally to benchmark stakeholders’ awareness of design research. Go do five listening sessions with stakeholders. Have they been thinking about it over the past six months? What was their inner reasoning is about the topic if they’ve been thinking about it? Then let’s share our findings about stakeholder inner reasoning, or lack thereof.

2. While we’re benchmarking, do some human-network-node-following to find the various persons who know how much is spent on any kind of research, throughout the various divisions of the organization. To Mark Hurst’s point, find out the advertising budget, too. And marketing. Dig below the surface of the labels to see what the research comprised, exactly.

3. For the design research projects that have occurred (if any) over the past few years, track down how those research results were used. See if you can list the outcomes. The stakeholders will want to see values assigned to these outcomes, so track that down if you can. Did it affect hitting OKRs or other business goals?

If we do these things and tell each other what we found (in terms that won’t betray our org’s IP), then we’ll have some convincing tools to use to in our arguments for more budget. It will hinge on us sharing the information, because we all get caught in the “that’s the way we do it here” trap. If we talk to stakeholders about the recent history of other orgs’ research efforts in conjunction with our own, then it will provide a bit more of a jolt. Hopefully.

(Where should we share? How about via Medium posts?)

* Here’s a snapshot of ten different variables that I use to help potential clients decide how to balance needs against budget.

ten variables in estimating hours for a problem space research budget


Q: At a talk one evening, when referring to research I’d done for an airline, I despaired over the current un-supportive state of all airline reservation tools. A person in the audience objected, saying, “But now we have access to all the possible flights. We have so much more knowledge and choice! We can go find exactly what we want!”

A: My response centered on two of their words “go find.” Finding something requires time, cognition, and patience sifting through and comparing options. The options are only presented in terms of the airline schedules, not in terms of the passenger’s calendar of appointments. Prior to the web, there was a service where a human being (a travel agent) got to know a traveler over time, noting their preferences for time of day or seat or connecting airport or price. The travel agent even got to know a passenger’s personal life enough to know that when a particular person had a baby, they changed their flying preferences. They wanted to arrive home earlier in the day than they did before having a child. They stopped tacking on a few extra days to a business trip to see some sights. Passengers only filled out a form once, when they first met this travel agent, and then every subsequent trip, the travel agent took into account all they knew about the passenger, accumulating knowledge as they chatted (note: Conversational Design) about the purpose and needs of each trip. The web-based tools are much less intelligent, and do not accumulate knowledge about individual passengers over time–nor do they even accumulate knowledge in the aggregate unless reprogrammed. Yet.

The point I want to make is that there has been a solution for hundreds of years to the purpose of arranging a trip. We tend to think from a tech-point-of-view, because tech is, admittedly, pretty amazing. But the software we have provides one fixed-in-code, average way to support people. I’m hoping soon we’ll start to see individual-data-customized experiences, similar in a way to what human travel agents can do.

newsletter #33 | 20-Feb-2018

In the tech world, as well as in other industries (like science), there is an overriding push to speed up discovery. In business, the root cause is often “get ahead of the competition.” In academia, it’s “be the first to publish this.” Speed governs most of us. Exceptions exist, like in the safety community, which is filled with careful processes like pre-flight checklists or routine maintenance. But the rest of us pretty much bow to speed. And so digital products aren’t always thought all the way through. Science experiments get published that no one can replicate. Yet, over the years, these very things accumulate polish, from repeated, randomly-driven attention. Experience accumulates as the result of a community of people. Tweaks get made. The outcome gets better and better. But this takes a random amount of years.

Real change always takes time. Some of those follow-on years of polishing could be compressed into a few months of getting more depth and breadth up front.

How do you help stakeholders become more aware of this ubiquitous fear of time? First, you can try to identify what they are struggling with.

Struggle 1: Startups (or innovation teams) don’t have the money.

Struggle 2: Big companies can’t get past convention. (This is the way things are done here. Or, following processes because they are the processes.)

Struggle 3: A person in the power structure does not see the value. (Research does not make progress on the things we need now. We can’t put resources toward something that doesn’t immediately translate to a prototype. Or, we are afraid to find out that we’ll need to make drastic changes, or pivot, based on what we learn.)

Struggle 1
If you see your stakeholders in Struggle 1, then it’s time to get them better connected to the people providing the money. Those investors do not want to waste their money, and having a conversation with them about the risk of making guesses generally leads to agreement. The kind of problem space research I describe to them has a time/money trade-off. If the study is being done by an internal team, it won’t cost more than the price of transcription and participant stipends, but since that internal team is always under-staffed and over-tasked, it will take many months. If the study is being done by an external team, it will be finished in 8-12 weeks, but cost may be $50-$75k. Price out the cost of failure because of guessing at the wrong direction, and compare. (Also compare this cost to the marketing budget.) Do this in collaboration with investors and stakeholders. They will take strong interest.

Struggle 2
Struggle 2 is more insidious. It’s hard to identify if your team is just producing what should be produced, and it’s embarrassing to realize it, so no one wants to discuss it. I have heard of teams producing so much research that it piles up in layers, and when it comes time to make prototypes, they are not drawn from the accumulation but from standard UX approaches and generalizations about users. These are the symptoms. If you notice these symptoms, consider running a rescue operation, but doing it in such a way that it saves face for both the stakeholders and the other practitioners involved.

For example, what is the viability of a pop-up ad within a few seconds (or a click) of someone reaching your page? You might get 4x the conversion with a popup than with an ad at the bottom of the page, but how sustainable is that — how many of those 4 people will have a relationship with your organization four years from now? Is there a connection? Can you find out? Furthermore, can you ask actual people what goes through their minds when the popup appears? Most likely it’s not about you and your conversion. But if you take the time to find out, you’ll have pieces of the puzzle that can help pull together the layers of prior research in a concise way. When the research is consolidated (people use a mental model diagram/opportunity map for this), then it can effectively influence design and also guide development phases, use cases, inventory lists, etc.)

Struggle 3
In the third scenario, Struggle 3, you’ll want to employ evidence that taking time now helps your organization save time later. Problem space exploration is only hard because it requires a different mindset. It’s disconnected from the solution, so it seems like a bad investment. It doesn’t seem necessary. It takes a mindset that, to support people with more breadth and depth, you need to understand people completely divorced from any thought of the solution.

Here’s an example. You have listening sessions with people, and then you take time to digest what you heard. What you thought you understood the person was saying takes on different meaning when you hold the entirety of what they said together. One concept they mentioned early in discussion gets illustrated with an example later, takes on an extra nuance, branches off into an explanation of where that nuance came from in their history, and then gets restated further on in a more succinct way. If you go over each transcript of each listening session carefully, and it’s magic how much better you understand that person’s thinking afterward. There is clarity that forms, and then patterns across different people coalesce from that clarity. This requires more effort, more time, but results in great depth of understanding. You can create better support for them.

The value comes from that depth of understanding, but also from breadth. With breadth, there are more aspects of what a person is doing that you can support, plus there are more philosophies you can support. Not everyone comes from the same background; people have different approaches. It’s a case like the long-tail–there is plenty more opportunity for your organization. This evidence is the sort of thing you can bring to the Struggle 3 scenario.


Teams and stakeholders all ask the right questions and wonder about risks, but unless there is strong user-centered leadership, very little is done to answer those questions accurately enough to mitigate risk. I think all this hurry has been introduced. It’s not the natural pace of the software craftspeople that I know, who are truly trying to create a beautiful set of code, an algorithm as close to complete as possible. It takes time to consider all the angles and potentials. Most long-lived software has its roots in craft. (Google founders, Apple founders, Microsoft founders) Alan Cooper said, in a UXWeek presentation, “In those days programmers wanted to make good software, and if money came as a result, that was a plus, whereas these days it’s the opposite.” He’s got a point, but I don’t think this is true of every software engineer today — programming still takes craft. It requires a mind that is interested in taking time to consider many different possibilities.

Possibly by identifying which struggle your organization is engaged in, and by encouraging the fine craft of creating digital products, you can slowly change the attitude toward taking time to understand the people you aim to support.


Q: What are some examples of questions to ask in a listening session? You list some standard questions in Practical Empathy, like, “What were you thinking when you made that decision?” What else?

A: In a listening session, you are following what the participant is saying really closely. You ask questions based on what they said, but only when you think you might be assuming what they mean. You want 90% of the words in the recording to be from the participant. (But you also want to be supportive, especially early on, to form trust and rapport via emotional empathy. Don’t be cold and terse.) So, here are a few examples. When you are wondering one thing, here’s and example of how to ask it:

Why did he respect this potential mentor in the business he was in? ==> “What passed through your mind when she said gym?‘”

What made him go look for the contractor? ==> “Contractor …?

Why did she say the business such a risk? ==> “What did your inner voice say when the banker said that?

Q: I don’t really get what you mean when you say that the scope of a study needs to be problem focused, and you’re not supposed to reference the product.

A: Developing an awareness of when you want to explore the solution space and when you want to explore the problem space is important. Most of the time you’ll want to be doing user research, which is in the solution space. At intervals, maybe once a year, you’ll want to add to your understanding of the problem, from different perspectives. If you don’t clarify the contexts in which you’d do the latter, the two will slump together, and out of habit you might end up exploring the solution space exclusively.

For example, say you work for an insurance company. A marketing need might be getting more people to become aware of different levels of insurance for their home. But that mentions the product, so what is the larger problem people are trying to address?

Solution exploration: How do we get people to pay attention to home insurance levels?
Problem exploration: How people understand what risks are possible (and discover risks they never thought about)? Then how do they establish whether these are areas they don’t mind feeling vulnerable about?

See the difference?

indi can help you
answers, advice, direction, de-tangling of complex situations
private coaching
group coaching
coffee with indi
research delivered to you, when your resources are short
custom research
heavy lifting
team mentoring
figure out if this is the right research at the right time
try-it-out day
workshops, coaching, presentations, book club chats

newsletter #32 | 16-Jan-2018

Saturday morning, 13-Jan-2017, an emergency alert went out to Hawaii’s alert-enabled mobile phones that a missile was inbound. Discussion ensued about how this mistake was made and what we could do about it. Cyd Harrell, who has experience with government software and processes, tweeted a thread about the complexity of both how and what can be done.

The news story made me think about our human tendency to want to explain things simply, state a theory, and set off in a certain direction based on that theory–as quickly as possible. I was listening the the Radiolab podcast episode about stereotype threats, and the replication crisis (in psychology). In particular, an experiment was formerly replicated to show that college women’s math test scores increased to equal men’s when they were told that the particular test they were given had never shown any unequal gender results. There were other variations on the experiment, but they were having trouble replicating it. They were wondering if it was because stereotypes change over time, this generation is more aware and able to block the power of stereotypes, or if the level of the preparation for difficult math tests was different, etc. I kept wondering: why not ask the participants what went through their minds during the test? Why is this component, hearing from the actual participants, not included in their research?

Probably because of academic methods. Possibly because the answers different participants would give would each be different. Those differences would be difficult to summarize into a simple explanation.

This reluctance to embrace complexity exists in the business world. In the tech space. We’re trying to support simple versions of people and scenarios that just don’t exist in any clean way. We want to reduce cognition to heuristics and pattern processing. People in tech see little difference between training a pilot to fly a plane and writing software to control a car on a road full of other cars driven by other people. I believe there is more complexity involved, specifically involving time, lived experience, continuous consideration of inputs, and emotion.

People change over time. It’s not simple rationality. They change their minds. They get influenced by others and shift perspectives. Within the industry of making algorithms, this is not viewed as a good thing. You can’t be pinned down. It’s harder to chase you and get your attention and appease you. Simplicity and minimalism, these are the watchwords. But humans are complex. The algorithms we interact with are no match for the speed of our thinking, the cultural references, jokes, and digs we make, the leaps of intuition we have, the motivations and guiding principles we follow, the empathy we feel, or the compassion and kindness we display. Continuing in the vein of “simple” has brought us to a wall.

Mathew Desmond, a sociologist, author, and professor, writes about the complexity of poverty and race systematized in American society. He summarizes the human tendency to simplify others this way: “There are two ways we de-humanize others: cleanse them of all virtue, or remove all sin from their lives. Neither is true.”

The best way I can think of to address our fear of complexity is to accept it and start investigating pieces of it, little by little. Pick a particular thing a person is trying to do, a set of contexts, and a couple of different thinking styles. Gather from people what goes through their minds as they seek to accomplish this purpose, translate, and look for patterns. The “translate” part is where you put into words the crazy-human-ness of our inner voices. When a person tells you of an event that happened when she was a teenage lifeguard at a pool, you listen. A group of boys had jumped in the deep end, and one of them was struggling to stay afloat. She had to decide whether he needed rescuing or if he was “fake drowning” to catch her attention. She wondered if he actually couldn’t swim and jumped into the deep end just to keep up appearances with his friends. “Of course I’d jump in the deep end if I didn’t know how to swim!” You have to recognize sarcasm and take into account context and mood. How do you do this unless you have a human brain equipped with life and social experience and capable of cognitive empathy?

So our job is to help those around us embrace the complexity and feel confident in exploring it, rather than racing past it with a hasty theory. We don’t want our own crisis, do we?

other news

Indi has office hours! If you have a question, you can book time with me in one of three ways. Use the time however you need. I set up availability for connecting from all the time zones.

A new “commercial” website is on its way, aimed at managers and those whom you wish to persuade of the value of problem space knowledge. It will contain case studies from the interviews I’m conducting with people who have made use of mental model diagrams, thinking-style segments, and opportunity maps.

In the meantime, now harbors a lot of free content. It includes:

  • podcast episodes – transcripts and recordings, along with free webinar recordings, and videos of my talks
  • newsletter archives with Q&A – forward one to your boss to give a little force your point
  • articles – whitepaper versions of my Medium articles, to print and slap down on a certain person’s desk, articles from Interactions magazine
  • diagram generator – the new app that converts your formatted data into a mental model diagram

Take advantage of the wealth of available content, and feel free to pass along links to those you are mentoring.


In my book Practical Empathy, I write about conducting listening sessions by phone. In Describing Personas, I also write, “All this is better to do by phone than in person. (In most cases.) You don’t need to see their artifacts or observe their behavior,because the knowledge you are after only exists in their minds.”

Q: (from Bobby Gonzalez 21-Dec-2016) Thank you Indi. Interesting article. Googled a bit and found some research indicates people with prosopagnosia have diminished capacity for empathy for others. Also, psychophysiological responses to empathy recruit a region between the inferior temporal (important for perspective taking), and fusiform gyrus (imperative for facial recognition). Maybe “seeing a face” does activate parts of the nervous system that vitalize or enhance ones ability to empathize?

Q: Lauren Faggella 19-Apr-2017 Would you agree that some people respond differently in person than over the phone? For example, I don’t always like talking over the phone, particularly to people I don’t know very well. But if I sit down with someone and get to know them for the first time, I’m likely to open up and speak on things that I wouldn’t ordinarily touch upon.

A: It depends. (The classic answer!) First, your own preferences are not evidence of anything, so the thought of your preference acts as a red flag to re-ask yourself about what might work best for a particular participant.

Second, during a listening session you use emotional empathy to establish rapport and generate a comfortable atmosphere for the participant to tell you their inner reasoning. You aren’t doing any perspective-taking during the listening session–that’s for later, when you’re using artifacts from the data to work on your ideas and solutions. During the listening session, you’re in the problem space, not thinking about solutions nor ideas, and not thinking about synthesizing or analyzing what you hear. You do want to help participants trust you during the listening session, and you can do that in any way that feels right to the participant. If you are making the participant feel supported and comfortable, you shouldn’t get different results whether you’re on the phone or person, unless the comfort depends on visual cues as well as spoken word.

Third, I emphasize phone to motivate teams who don’t have the resources to get out to see participants. I want them to still gather this knowledge. I want everyone to be able to conduct listening sessions. Taking travel out of the equation helps in many cases.

Fourth, if you are doing solution space research, watching and interviewing a participant making use of a particular solution, then perspective-taking, cognitive empathy, does come into play. This is a different sphere than listening sessions, which are (usually) part of the problem space.

It always depends. Make your decisions based on your participants.

indi can help you
answers, advice, direction, de-tangling of complex situations
private coaching
group coaching
coffee with indi
research delivered to you, when your resources are short
custom research
heavy lifting
team mentoring
figure out if this is the right research at the right time
try-it-out day
workshops, coaching, presentations, book club chats

newsletter #31 | 19-Dec-2017

Welcome to the end of the year (for some cultures), when everyone seems to think about time. You might think about time left until a deadline … how you spent your time over the past year … time for changes for the new year … time to renew yourself. One of the things I’d like to hit the reset button on is how much time teams take to deeply understand the problem space. With the [mistaken] emphasis on speed in the agile process, speed through design thinking, and speed to iterate in lean development, time seems to be the stern dictator ruling our thinking … banning words like “deep understanding” and “explore” in favor of words like “hypothesis” and “automatic” and “quick survey.”

It isn’t just ideological; it’s cultural. Speeding through the process of pushing stuff out into the world is an accepted, lauded mindset in technology and design. I have nothing against speed in moving from idea to prototype or launch, but moving TO the idea with haste is risky.

So much of our technology and design culture is focused on ideas; reward systems are based on the merit of ideas. Methodologies focus on evaluating ideas and bringing those ideas to fruition. Ideas are the basis of stories you tell to prove your worth. Yet, generating the ideas takes very little portion of the whole process. And generating ideas is mostly an act of imagination. Imagination is necessary, but it’s not the only component. There are other components such as the business perspective of ROI and risk and market. And there are important components such as supporting non-dominant thinking styles.

“We’re still working in a profit-at-all-cost model. Open it up to impact. Lower profit for some other type of gain. Point out opportunity cost to influence investment.” – Peter Falt, Director at BMW DesignworksUSA, DMI Symposium 2017

It all has to do with really focusing on the people you’re trying to support. Often those people are called the “customer” or the “users.” What I’ve been trying to do is separate that out a little farther. When we refer to people as “customers” or “users,” we are looking at the problem through the lens of an offering, an organization. We are looking at what we do to support them and how we think about them … all the knowledge we already have about them. But it tends to force you back into the mindset of problem solving. It encourages you to come up with new ideas, or dive into innovation work. I would like to insert a little bit more knowledge that has nothing to do with innovating, nothing to do with idea generation; this knowledge only has to do with understanding a problem. It’s what Practical Empathy is about. It’s the idea of taking that first step of Design Thinking and snapping it off, so that it’s not a part of a cycle. It’s not a part of improving a product or coming up with new ideas for a product.

design thinking: empathize, define, ideate, prototype, test ... but make empathize separate cycle

Ideas are the exciting part. All this focus on ideas makes it tempting for people to skip over the understanding part. Instead, if you think of the problem space as understanding a person (not a “user” or a “customer,”) … you can let go of your need to solve problems for a bit. This opens up your awareness that there are other approaches, thinking styles, and guiding principles out there. You can find themes and patterns, codify them, and match your priorities and strategy to them. This not only expands your market but also lets a much broader set of people to not only access your services, but be supported by them.

This is where you run into the pervasive problem of Cultural Fit … most of our technology has been created as “one algorithm to serve them all.” And that algorithm, written by a team of people, represents that team’s understanding of the world. It represents their culture and history. It misses the history and experience and purposes of other people. Often the team does not preoccupy themselves about the missing perspectives, because these other people are seen as low ROI. And the team believes they are low ROI because it believes that the dominant culture brings more value. Is more valuable. If they use data to back up their assessment, it is most likely data that embodies historic bias in favor of the dominant culture.

Sara Wachter-Boettcher writes about this toward the end of her book Technically Wrong. She also explains the problem the tech world has with lack of diversity among team members. The defense has been that the pipeline is nearly empty. Sara points out evidence that the pipeline is actually full of diverse candidates, but when hiring managers evaluate people, they look at “cultural fit.” If this is true to any degree, it’s a terribly self-perpetuating cycle.

So, here at the end of the year, if you have time to renew yourself, pick up Sara’s book and spend a couple of hours seeing things from the point of view of her stories. Or at least peek at the reviews.

And please reach out to me if you have stories of how your own experiences have shown the value of taking time to form knowledge about the problem before jumping to idea generation.

thought provoking

Quick plug for the new app I released that converts your formatted data into a mental model diagram: Diagram Generator

Here’s a great explanation covering why I’m not such a fan of “data driven.” (by Jeremy Keith of Adactio)

In case you need to point someone to a concise explanation of Dark Patterns. (by UIE)

Aurelius Podcast: Episode 15 with Indi Young discussing Empathy, User Research, Synthesis and Thinking Styles (posted on December 19th 2017 by Zack Naylor)


Q: An experience map shows the problem space, doesn’t it?

A: The word “experience” often leads people to think “how customers experience our service,” so in that context it’s in the solution space. If you’re doing solution-focused work, it is about the experience people have with an org’s product. So it’s fine to say “experience map” there. But if you’re doing problem-focused work, it’s not about the org nor the product/service. In this case I call it a mental model diagram.

Q: Your advice is to stop describing age using numbers in persona descriptions. Here’s a question then: I’m on a project where >50% of the service users are over 80. And fewer than 10% are under 60. Their age defines elements of how the service is delivered. How would I legitimately exclude age in this case? In fact, every project I’ve done with this client has had important elements of service defined by age groups. (Federal government … Veterans … Pensions and compensation to veterans and their children.) Age defines certain kinds of eligibility, engagement, or delivery approach. It’s been fascinating work. (from Stephen Collins)

A: Your population is qualified by age, sure, but within and across all the brackets, the way they approach the support provided to vets varies by thinking style. There might be a thinking style “never gonna get what I need” or “reluctant to spend the time with the red tape,” etc., that could be supported with different conduits in, different language or tone, and also representations of what the system already knows about their preferences. Defining the different thinking styles (from listening sessions) will help you provide more supportive, accessible experiences.

indi can help you
answers, advice, direction, de-tangling of complex situations
private coaching
group coaching
coffee with indi
research delivered to you, when your resources are short
custom research
heavy lifting
team mentoring
figure out if this is the right research at the right time
try-it-out day
workshops, coaching, presentations, book club chats

I’ve released the software to generate a mental model diagram. You can feed your spreadsheet to it and a mental model diagram (the top half of an opportunity map) will appear on the page. You can export it as an SVG file to load into a drawing tool. Read More

newsletter #30 | 21-Nov-2017

I often speak about using vocabulary that clarifies meaning. For example, I encourage people to say the word “user” when they mean someone who has a relationship to the organization or the product/service, and say the word “person” when engaged in understanding the problem space. I try to clarify the difference between the solution space, where the focus is on the thing you’re creating and the ideas you have for it, and the problem space, where the focus is on the person. In the problem space, I am interested in understanding all the things running through a person’s mind as they seek to achieve an intent or purpose. And I wonder if I should settle on one word or the other: “intent” or “purpose.” Read More

newsletter #29 | 17-Oct-2017

This newsletter will be short, because I live near the Santa Rosa, Sonoma & Napa fires. It has been an intense week. I tracked friends and family, volunteered at a local evacuation center, and made donations. I saw so many other members of my community doing the same. We had more physical donations (food, clothes, bedding, pet food) than families to take them! So, it becomes a problem of getting the items to the right places, and thence to the hands of those that lost their homes. Read More

newsletter #28 | 19-Sep-2017

“Doesn’t the problem space come first? Shouldn’t it appear on the left in your diagram?” Lots of people ask me this. Research in the problem space isn’t a part of any solution cycle, so no, it does not come first. In an industry filled with process cycles (there are even figure-eight cycles), it’s hard to reconcile this idea with conventional step-wise approaches. Read More

Dave Rael has been podcasting about software development since June 2015. In our chat, the key turning point was when he said, “algorithms are neutral.” I explained how they’re not, starting around eleven minutes in. Developer on Fire Podcast Episode 265 … just two transposed digits away from episode 256! (transcript coming soon) Transcript below Read More