newsletter #37 | 19-June-2018

Right off the bat, you can tell. In an opportunity map (a mental model diagram above the horizontal line with your support aligned beneath the towers) you will see big gaps below the towers, or places where there’s so much content that it piles up into funny shapes. You can also tell things based on the colors. Here’s an example opportunity map.

So, let’s take a quick look.

1. Gaps: There are two whole mental spaces (between the upright lights) that have no support for the towers above. The first thing to do is investigate what this signifies.
1a. Maybe it’s something that came up in the listening sessions that the organization just never sees itself getting into. In this example, the first empty gap is about how participants in the industry studied pay people and give bonuses. The second empty gap is about hiring, coaching, and monitoring employees. These might be areas for expansion, helping this organization go in a direction of support that the competition aren’t geared up for. Or these might be areas the organization wants to keep away from. This decision should be a consciously considered rather than left as an assumption. Participants in the listening sessions clearly think of it as part of the purpose they are pursuing.
1b. Maybe these gaps show reasoning that certain thinking-style segment considers part of accomplishing their purpose, and you realize that your organization has been focused on a different thinking-style segment by default. In the example diagram, you can tell from the colors of the boxes that the first gap represents one thinking-style exclusively (blue), while the second gap represents all the discovered thinking-styles (blue, pink, purple, orange, white). The organization may want to consider how well it supports the blue thinking-style in other parts of the diagram as they consider their decision in part 1a, above.

2. Weaknesses: There are many mental spaces with only a few boxes of support below the line. There are also mental spaces with only one type of support, that doesn’t match all of the thinking-styles above.
2a. Where there are only a few boxes for a whole mental space, it may be the same sort of situation as in 1a, above. The second mental space in the diagram is about finding work for the employees, and it only shows two boxes below the line. The organization could consider the opportunity to offer connections between the businesses it serves, in case one business has so much work they wish to offload it to another business, or something similar.
2b. There may be several boxes beneath a mental space, but they only offer peripheral support. The second-to-last mental space is about planning the items that will be worked upon, and the support there currently is threadbare, only offering the location of the employees that could possibly help with these items. The location doesn’t really help this business assign work, but it could if more information came along with it–and if the database containing this information about the items to be worked upon can be hooked up. It may not necessarily be difficult to provide better support here. Again, it’s something worth discussing rather than dismissing entirely.
2c. In the ninth mental space, it’s a combination of peripheral support and 1a, something this organization never saw itself getting into. But this mental space is about the businesses deciding how to grow their business, and this organization has an incredible amount of data that shows where the growth thresholds are. It’s tempting to skip over this mental space because of the two counts against it, but upon executive discussion, this could become the most interesting opportunity of all, to provide custom consulting based on growth data trends accrued across businesses.

3. Funny-shaped piles: There are several places in this example where there is so much support that it has to be shoe-horned in to the diagram. Usually this means that the organization has been too focused on certain activities and not considering the broader landscape, which is what we discussed in part 1, above. But it also can mean there’s a hiccup in the process or
3a. A hiccup is occurring in this diagram around the physical items being sold by this organization. The purchasing business has to pay for and inventory the items and return some of them for upgrades or repair. In the fifth, the eighth-from-last, and the sixth-from-last mental spaces, you can see they cascading amount of solutions-accreted-upon-solutions this organization has put into place to help the businesses pay for and manage the physical items. This is an opportunity to consider whether the organization can support the business better by doing the management on their behalf, thus allowing the business to focus on their real work.
3b. In the ninth-from-last mental space, there’s a huge tumble of content under one tiny tower. Upon investigation, this represents installing the items the businesses buy from this organization. Judging from the amount of content, it looks like it’s very difficult to install an item. Are there improvements this organization can make to the installation process? Can the organization simplify the item enough to make installation easier? Can the organization provide an installation service to these businesses? There’s a lot to discuss based on this mental space.

Even at a glance, it’s easy to pick out a few types of opportunities for an organization just based on the shapes and colors aligned in the diagram. The diagram is a catalyst to discussion about strategic direction, weaknesses to improve, and specific opportunities.


indi can help you
answers, advice, direction, de-tangling of complex situations
private coaching
training series
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
double-check
try-it-out day
workshops, presentations, book club chats
presentations
training

Internet Librarian is the internet conference and exhibition for librarians and information managers. The conference is held every October in Monterey, California. 2016 was the 20th anniversary of the conference, and the theme was “Act for Impact!” I was invited to give the opening keynote.

Keynote announcement and description

There was no recording of the talk, but here are my speaker notes and key slides, as well as some commentary (some of which appears to have been put behind logins): reportreportreportreport-with-slides  slides without commentary

transcript: the impact of deep understanding

Of course I have to start a talk to an audience of librarians with a picture of my bookshelf. Or rather, a special part of the bookshelf holding some of my grandmother’s books. Plus the first book I ever bought. (The dictionary.)

The blue book in the middle is a really special one. It’s a collection of letters a 13 year old niece of my grandmother’s wrote every day during her trip through Europe with her parents in 1937. That was the year of the coronation of King George VI and Queen Elizabeth … the year of the World’s Fair in Paris. Her father was a product-buyer for a U.S. department store, so this was a six-month sourcing trip.

The question is: Why did this 13-year-old do this? Why write a three-page letter every day describing the details of her day and her reactions? She’d promised her grandparents, as a way of carrying them along to see the coronation and to experience Europe. They used her letters to see through her eyes and feel through her heart. She used her writing to shine in their eyes, and to guarantee correspondence.

I use her letters to re-trace her steps when I’m in the places she described. This is the Chateau de Chillon in Switzerland. She describes these images in her letters. I like to dwell on the common human threads undisturbed by time. There is something quintessentially human about her train of thought. It is as valid today as it was in her timeSure, there are things that are different today: faster communication, more widespread access to knowledge, but human thinking is still human thinking.

Of course, Betty May did refer to the technology of the time. We have that phrase “Digital Natives” now—people who were born after the advent of the internet. She was a “Kodak Native.” Amateur motion picture filming was introduced when Betty May was born. When she was 13, in Paris, so it was natural that she would drive around the city taking movies.

Saturday, May 29, 1937 “We grabbed an open top cab and drove around the city taking movies!”

Amateur motion picture filming was introduced when Betty May was born. When she was 13, in Paris, so it was natural that she would drive around the city taking movies. She was also a photography enthusiast. She took her camera everywhere, just like we do with our mobile phones today. Even if it might put the device in peril … here she’s up in the mountains of Switzerland.

Thursday, June 3, 1937 “We saw some huskies for hire. Jan and I piled in camera and all. Out we sprawled on a turn. Snow down our backs and our hair … I’m afraid my camera was ruined.”

Whenever a film-printing service was available in a city she arrived in, she would drop off her work and return the next day in hopes the photographs were ready. Sometimes she was disappointed.

Friday, July 16, 1937 “…but my films were not ready at Kodak.”

But when her films were ready, she was ecstatic.

Tuesday, May 4, 1937: “Oh! Yes! I got my films today! I am sending them home. I hope May May or Ruby will get an album for me. I labeled all of them on the back.”

She was documenting her trip beyond just the daily letters to her grandparents. She anticipated also looking at her photographs in the future, and sharing the album with people who were interested. Perhaps she was also recording what happened so she could remember how it felt, later, when the emotions had faded. But, did she know this at 13? Or was she just doing what everyone did: making an album?

My own grandmother made albums. I’m a grandkid of a Kodak native. I don’t happen across the physical albums very often. I see them when I’m helping my parents move house, or for their 50th wedding anniversary, or when someone in the family has died. That’s when I spend time immersed in them. I try to learn my grandmother’s stories.

She had a lucky upbringing. She got to travel. She went to Hawaii by boat with her family.

Her brother.

She posed for the iconic surfboard photo. That’s Diamond Head in the background.

When I look at these photos, I’m amazed they were able to have such adventures in places we still think of as distant …

… that took days to get to …

… wild… inhospitable. (Like, how did they get to Truckee in the winter in 1910’s before interstate 80 was built? It would have probably been by train.)

And yet, here were all these people, enjoying the locations, enjoying each other, striking frolicsome poses for the cameraI wonder what these people were like and what was their intent as they took these photos. There’s something about this wondering, this trying to connect with people from the past … bonding, understanding, reminiscing, wondering. I want to re-invoke their lives. What was involved in the decision to go fly in a biplane and take photos of San Francisco, when that was the high-tech of the decade? It appears that this biplane ride was the work of a gentleman trying to impress a date. WOW!

But then, who is this gentleman? What was on my grandmother’s mind as she posed for this photo for him? How did her personality form from this adventuresome girl with her little brother, unafraid of the cold Monterey Bay water … to the carefully poised, reserved woman that I knew? (That’s her on the right side.)

I have her albums. Every few years I come across them and wonder about her thinking and the moments that were captured in those photos.

Here’s another question. This is a “Digital Native.” (My nephew.) What will his grandkids do? They won’t lack this curiosity about their ancestors, surely. How can we support them?

Right now, something like Instagram or Facebook is kind of all we’ve got, digitally. It superficially ties memories to dates … and mostly only your own memories or memories you were tagged in. This feature supports none of the various thoughts I’ve wondered so far.

<photo of dead tomato plant re-shown to me on Facebook a year later>

Sometimes the feature actually makes me feel upset. So how do you figure out better ways to support people? To pave the way for the Digital Natives’ grandkidsDeep understanding! Developing empathy. We have to understand what their purposes are. What they’re thinking.

You do that through research. Research is in fact the tool that most of you reach for first when faced with a challenge like this. There are lots of kinds of research. We can understand how well the services we create work for people. Or whether one solution works better than another. We can use generative research to gain inspiration. Successful organizations try to do research in all of these boxes.

There is a whole layer that hasn’t been explored much. It’s called the problem space. That’s the layer that understands the intents and purposes that people have, whether or not these are explicit or layered deep in their minds. Forge a deep understanding of people … via cognitive empathy. Successful organizations are also branching out to include research in this new layer.

Quality is measured in two ways: how well does the solution do what you intended? How well does your organization support the person in their pursuit of their purpose? What I talk about is support, not manipulation.

When I did research for my book Practical Empathy, I found lots of articles about persuading people, especially politically, but very few about supporting people. Persuasion, manipulation, these are often referred to as dark patterns. Support is different than manipulation; it’s not what Daniel Goleman was thinking of.

Tasks and goals relate to the solution space. I want to be able to support the intents and purposes people have. Support how they think their way through to these larger things. Not the details of how they use tools, not the explanations of what they’re doing. What are they trying to do, and what workarounds are they thinking up to achieve these larger purposes?

A purpose is larger. My mom is getting older and has never seen the Grand Canyon, and I want her to have that amazing moment when she first lays eyes on it. But we live in different cities. And since she’s getting older, she doesn’t like to fly. Last time she flew anywhere, a few years ago, she had a connection. She got a bit lost and was late and it was a lot of stress on her. So I was wondering if I should fly to her city and drive to the Grand Canyon together. Or if there’s a direct flight for her.

But all I’m faced with is a representation of the airline’s system. They have planes that fly between airports on certain dates at certain times. That’s all they will help me with.

I happened to do a year’s worth of problem-space research with an airline. 100 participants. And a huge part of taking a trip was exploring what it takes to get there, making decisions around difficulty, complexity, timing, time of year, possible thunderstorm delays, extreme locations requiring days to get there, islands with no airports, etc. The airline thinks I’m only concerned about the price of their flights between airports. So I tried a bunch of options, taking an hour to see what might work. I had to pretend I was booking the flight. And when I figured out the route, I wanted to book two seats for me and my partner and a separate flight for my Mom. There was no way to do this.

The airlines tools did not support my intent.

Clients come to me wanting to do research and can’t get outside of their own frame of reference. I help them re-frame their thinking in the problem space, so they can broaden their perspective, and choose which audience merits a narrow focus.

And the research can be structured as a diagram which can be used to pinpoint gaps in your support and catalyze new ideas. All based on a deep understanding of different people.

Empathy is defined in a lot of ways. Walking in someone’s shoes is a valid interpretation of empathy, yet some people twist the meaning, saying “If I were in their shoes, I’d …”

… which of course is not what empathy is about. Empathy is being an actor, trying on their character, acting them out.

Affective means “emotional,” so you can also call it emotional empathy. In the Pixar film Inside OutSadness “fixes” Bing Bong with emotional empathy, where Joy failed with her tickling and positive energy to fix things. Emotional empathy is recognizing someone is experiencing an emotion and not trying to stop that emotion or fix any problem, but trying to support them through the emotion. Sadness says to Bing Bong, “They took something that you loved. It’s gone. Forever.” And Bing Bong talks about his memories, cries, then feels recovered enough to continue on their quest.

Emotional contagion, which is another form of empathy, is how actors and authors convey a character to you. If you don’t feel what the character is feeling, you lose half the story.

And there is cognitive empathy. It’s more than being sensitive to others’ emotions. It’s about supporting different people in different ways according to their purpose. Not their needs or goals. Their purpose.

Understanding people doesn’t have to do with the services or things a person uses, but the human things that people, even your great-grandparents, think about and planned for.

Remember the phrase walking in someone’s shoes? That’s how you apply empathy. But the majority of organizations skip the part about developing empathy. Instead, these organizations make up their understanding of others. The guess or use assumptions. Developing empathy requires listening to many different people’s stories to understand how their thinking goes. There is a practical way to do this, and to draw reliable patterns from the words which guide you. Not interviews, but listening. It’s like going on a tour of a city, following the guide around. (We had our own little rainy tour in Monterey yesterday, led by Jen Waterson of the Middlebury Institute of International Studies here in Monterey.) When you’re on a tour, you follow what the tour guide wants to show you. If you have an abiding interest in church architecture, but that’s not on the tour, you don’t interrupt the guide to ask about it.

When listening, you need to go deep. You can’t develop empathy from statements of fact, explanations, opinions, or preferences. Those are the shell (or bubble) that we build around ourselves to show to the rest of the world. Empathy goes into the deeper currents. To listen well, you need to channel your inner toddler. Toddlers are not embarrassed that they don’t know. Empathy does not judge; it does not have contempt for another person.

Just deep pursuit of topics.

But so many organizations would rather skip the “warm fuzzy” side of things and just look at the hard numbers. Those feel more “scientific.” In a report the team at an airline received about passenger behavior checking or carrying on bags, they got a list of number broken down by gender, among other things. Why report numbers by gender? Why not age? Destination? Vacation vs. business trip? So, why not report by number of alcoholic drinks consumed on board? It has about as much correlation as gender. This brings to mind the phrase you learned in university: correlation is not causation.

… as much as this sweet little picture is something we we’d like to be true.

Usually the two things we correlate at work are more related. It is insidiousOur minds like to simplify things. After getting this report, the airline team turned around and actually captured the way people think about carrying on bags or not. Age, gender, economic means—these do not matter here. Instead it’s about the items being brought–is it precious? Needing to be protected in an overhead bin? Or people were concerned with ease of getting through airports–not being able to get Belgian beer from an international trip through security, not dragging luggage through a connection.This is a more helpful way to report the information for the product managers and designers.

Vocabulary is important. Cultivate an awareness of your vocabulary.

Every time you say user, or any of the other words that also mean user (member, passenger, customer, student, etc.), you are speaking about the solution space, not the human in the problem space. If you mean to be speaking about the problem space, use “person” instead of user.

Marketing segments have had too much influence on the way we think about personas. Marketing segments use demographics to represent the way people think. This is false. Demographics, statements-of-fact & preferences can be distracting and cause assumptions. Descriptions represent what is important to your organization. Your ideas will derive from this frame of thinking, which will limit your creativity.

Here’s an example.

Healthwise did research about people losing weight, found three different thinking styles, and supported them with three different packages. Each package has different components and different tone of voice.

Here is a second example. Rebecca wanted to understand the thinking styles of all the people who have a non-student, non-faculty, non-administration relationship to the university.

She found these four patterns of thinking. She then re-architected the web presence to support each of these differently.

In another example, Kendra works at a library system, with no budget. [laughter] She used her lunch hours to conduct listening sessions over the course of several months, then pulled together the data. In the end, she discovered several surprising things the libraries had not considered before.

Fourth example: for the office of Employment and Disability communications, as opposed to thinking of their audience as the “resistors” and the “change-makers,” they saw more nuance: Empathetic problem-solvers, Organizational implementer

Okay, now let’s face reality. It’s kind of like an Easter Egg hunt. We can get research done for a tiny percentage of these larger budgets. It’s typical for people to want to insert this research into a cycle—a solution cycle. Spread the word that this does not work. People short cut the phase when it’s done as a part of a recurring cycle, plus it does not always need to be done with each cycle.

You don’t explore the problem space all the time—only when needed. Build up your understanding of people over time. The data will never go stale. You can keep adding to it over time. Practitioners tend to do this every year or so, more or less.

The research data can be structured as a diagram which can be used to pinpoint gaps in your support and catalyze new ideas. It allows you to find affinities between these summaries and those from another participant more easily. It allows you to step into their shoes more easily. It also helps you save time that you’d otherwise take to re-understand each concept over and over as you create and use the artifact.

And you can add more voices from the people you support, the patterns stabilize.

For every hour of listening session, expect to take around 8, 9, or 10 hours to pull all the data together.

And it can be structured as a diagram which can be used to pinpoint gaps in your support and catalyze new ideas. It can be “decorated” with various information, thinking-styles, locations, demographic data, even survey results. The lower half of the diagram can be used in many ways, such as aligning the support and capabilities you already have in place, planning where to go next, forming arguments as to strategy, etc.

So if you’re trying to support the grandkids of Digital Natives in understanding their grandparents … you will think up better features using this kind of data.

These are Digital Natives. (My nieces, posing for the iconic surfboard photo.)

What will their grandkids do? They won’t lack this curiosity about their ancestors, surely. We can support it by … developing deep understanding instead of tracking what is happening currently with respect to the solution. Measure your new knowledge

newsletter #36 | 15-May-2018

Here’s a question related to some other conversations I’ve seen online: what do you do when you’re conducting research and the participant speaks in a biased or dismissive manner? This especially hits hard when the researcher is a member of the “dismissed” group, and doubly hard if the participant aims vitriol directly at the researcher. In the wash of emotional reaction, it’s difficult to remain “professional.” In this essay, I’ll explore some ways to get through your reaction, say the “professional” thing (which may surprise you), and still respect yourself as a human. There are so many ways to react and act. It depends upon you and your context and your goals.  In this conversation below, we narrow the focus to the development or application of empathy, and there are some reassuringly clear answers.

Q: (J.Loh) Is it possible to forgive people without having empathy for them?

Note: (Indi) I am initially assuming “cognitive empathy” as the working definition of “empathy,” where you take the other person’s perspective by first trying to understand what’s going through their mind.

A: (Indi) I think I’d need more context for your question. For example, in the context of being a driver, I can forgive someone for cutting in front of me on the freeway without needing to understand their state of mind. There’s also the context of my thinking style. I can forgive if I’m a type of driver who thinks “this is all a big dance with complicated choreography.” But if I’m a different type of driver, like “I need to get ahead of you, cuz this is a game I want to win,” then forgiveness for the driver cutting in won’t come, and much fist-shaking, bird-flying, and expletive-yelling ensues within the car. Note that the thinking-style of the two drivers doesn’t necessarily indicate their ability to develop empathy. It’s just a way of approaching the task of driving on that particular day.

I think in general, without context, my answer would be that the ability to forgive depends on the thinking-style of the person in their particular context. (I sound like such a consultant.)

J.Loh: Okay so the question then is more philosophical. How do you forgive if you discover in conversation that a user research participant has said or done something that is utterly reprehensible to your own belief system? It’s crucial that participants remain focused on the task and have the security and freedom to articulate their thoughts as they go through the product. However, I have noticed that some people use this product I’m testing as a platform to share views that can be interpreted as offensive and/or hostile. I interpret them that way. You’ve said that empathy is not required to forgive, but what if the situation in question is shockingly disturbing? In my situation, I’ve been advised to “suck it up” regardless of my personal ideology and complete the task at hand. Thoughts?

Note: (Indi) This context is user research, not problem space research, so you may not be conducting an empathetic listening session. User research is more about probing and observation, but there is definitely a requirement for listening skills and also building of cognitive empathy as the session proceeds.

Indi: Ah, there’s the context–a user research session! I think maybe you mean “accept” or “respect” when you say “forgive?” There are definitely situations where you cannot forgive someone. Maybe by those other words, “accept” or “respect,” you are wondering whether you should be expected to employ cognitive empathy to achieve acceptance or respect for the person. The answer here is no.

The mechanics of cognitive empathy require that, before employing it, you must develop a deep understanding of the person’s underlying reasoning and the sources of their beliefs. Without doing this first, you cannot wield cognitive empathy. It’s like trying to use a toaster without electricity. It won’t work. In your user research situation, it’s possible you cannot get at the person’s underlying reasoning and sources of their beliefs (via a listening session) because there’s no time, no structure to do it, or they don’t trust you enough to talk about these deeper things. So no, don’t reach for cognitive empathy; it’s a tool with no power if you cannot do a listening session.

(Quite likely I have assumed “cognitive empathy” by mistake. Let me try another angle.)

There is emotional empathy, but I don’t think you can wield that in this situation, either. Emotional empathy is being with the person in their emotional process—meaning you need to recognize when an emotional process is going on for that person, then show them you are listening and want to hear all that they have to tell you until they feel satisfied and can move past their emotion. Researchers and therapists (and friends!) use emotional empathy to build rapport, so the other person feels trust and security to explore deeper reasoning & reactions.

In the case of a typical user research participant, the emotional reactions they may have during a session include confusion and frustration at the product or the researcher’s questions. You know how to do emotional support for confusion or frustration at the product or the question. However, if the participant has an emotional reaction at the researcher(s), other participants, or other people on the product platform, whether it’s rage or inappropriate sexual advances or spewing of bias, then let your alarm blare! You aren’t equipped or required to perform emotional empathy to support them through emotion (especially hateful emotion) about the people involved in the session or the platform. The only thing you can try is to re-direct their attention back to the product being tested and the task at hand. Go ahead and use your facial expression to let them know you’re feeling disturbed at their outburst, because it’s outside the job you’re paying them to do. For a usability test, this is a transgression. You are the professional who hired them, so you can hold your body upright and call them on this with your eyes. If they refuse to be redirected and continue their emotional process, then I would say, “Well, we have enough now; this session is over. Thank you. Here is your stipend.”

If your client or manager insists you should have continued, tell them that the participant went way off script and refused to return to the test at hand. No valid data was forthcoming. Outside of scope. Show them the recording where you try to get the participant back on task. Show your client or manager this essay. They are paying you as a professional user researcher to gather data about the product, not data about the participant’s belief system.

To continue exploring this context, could you try out ways to stop the participant from continuing a rant? Threaten no stipend? Nope, you can’t threaten. Tell them they’re being rude? Nope, that will fire them up more. Maybe the only thing to add is that a researcher should only be expected to put up with it from one participant once or twice, no more. Three strikes you’re out. Session over.

Note: (Indi) If you were conducting a listening session for a problem space research study, then you would be exploring a participant’s belief system as a part of it. This is a different context.

Indi (still): What I want to ask you is this: Why do you feel like you are expected to “forgive?” (And did I get the redefined words right: “accept” or “respect?”)

J.Loh: Yes. The words should be accept or respect … not forgive. When I realize my own triggers are activated, it makes is more difficult to attend to my user research participants in an unbiased fashion, without feeling dismissive or angry or disgusted. In particular, racist or sexist views, whether aimed at me or particular groups, are hard to ignore. I admit that I almost feel like sharing a few “choice words” of my own sometimes. It’s still a pretty rare occurrence, but I notice especially in these times that I’m encountering it more and more.

Indi: Yeah, it is hard to continue listening. I think the key is to understand that the participant has gone off script, and as a professional researcher, your only job is to get them back on script to get good data, or to end the session.

Because this seems to be happening more and more, there are a couple of things I might ask here: Can someone else share the burden with you? It might help to have someone you can roll your eyes with and then take control to redirect the person back to the script. Having two of you might give you more authority from the participant’s perspective. If you can’t have a partner, then it’s possible to survive repeated outbursts by operating on the assumption (!) that these participants have been brainwashed, and would have beautiful souls if they hadn’t been exposed to all the racism and sexism they were brought up with and soak in daily. Get them back on script. You’d need to be imaginative, strong, sad, repulsed, and hurt all at the same time that you are trying to be an alert researcher.

J.Loh: I appreciate the humour and will be on the lookout for “beautiful souls.”

Indi: Right?! They exist. People repeat something they hear without thinking too much about it. Especially when the thing they hear is about a demographic group, they fall prey to cognitive bias, having had one experience that matches what was said. (Cognitive bias: I see a pattern! It must be true!) I’m confident when they have person-to-person experience with various members of the demographic group and seen the individuality, they’d throw out the thing they’d heard about the demographic group. A big piece that’s missing is the red flag that pops up in that person’s mind about demographic assumptions, leading them to avoid repeating such a statement.


indi can help you
answers, advice, direction, de-tangling of complex situations
private coaching
training series
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
double-check
try-it-out day
workshops, presentations, book club chats
presentations
training

newsletter #35 | 17-Apr-2018

The empathetic mindset is about being curious, open to learning what’s going through other people’s minds. It’s about focusing on understanding another person’s perspective and experience of the world. It’s specifically about letting go of the urge to have answers or solve problems for that person. Yet, most of us have spent our lives proving to our teachers, parents, peers, bosses (and selves) that we’re good at solving problems. The culture at most technology work places is usually about these solutions, leaving little time for developing empathy. Yet even within these cultures there is plenty of opportunity to stop thinking about the solution for a while–to use an empathetic mindset.

Right now in the technology world, broad representation of cultures, histories, and values among teams is rare. We’re working on improving this, actively seeking the people who have been excluded from chances others have access to. Change is slow.

So, in tandem with diversifying our teams, we can intentionally exercise the empathetic mindset. We can recognize five areas where disparity and unfairness result from decisions our teams make, and step in to help everyone choose again.

five biases to be aware of, as listed in the accompanying essay

A point I make in Practical Empathy is, “The empathetic mindset does not mean you have to feel warmth for another person. The words ‘understand’ and ‘comprehend’ do not mean ‘adopt’ or ‘agree with.’” Yes, it would be nice to feel warmth or “brotherhood.” But I also want to make sure professionals have the skills to wield the empathetic mindset when they are feeling confronted by someone who has different values. I want professionals to have the experience of recognizing a fellow human in someone whom they think is “less than” they are. If a professional has the awareness to recognize that they are reacting, judging, or being triggered, they can hit the mental pause button and decide what to do next. In some contexts, they can move into a mode of being curious where this other person’s stances come from. (Find out the source; ask and listen.) In other contexts, they may need to step away and take time to assess what could come out of the context for each participant. In contexts so far beyond their own boundary that they just can’t face the other person, the professional will step away completely and ask others for input.

But in the day-to-day of our work, often the context is so subtle professionals don’t notice it.

Sometimes the opportunity for empathy is made invisible because of the conventions of operating a business, or the habits of a business or technology work culture. Here are five areas to become more aware of in your work environment, data, and assignments:

1. Cognitive bias – the tendency for the human brain to find patterns in stuff … even if the patterns are meaningless. So if your boss is interested in why the data shows females behaving in a certain way with your services (like checking more luggage on flights), recognize that it’s only convention dividing the data that way. Being female does not cause most of the behaviors you see in data. Ask your boss if you can find out the real reasons why people check luggage. (Recite the mantra: “correlation is not causation.”)

2. Systemic bias – the way convention, algorithms, and models still exclude and marginalize people. One example that raised a red flag for me: “I would certainly get a credit score on any potential renter, and choose the person with the best credit.” The week before I’d just heard a story from someone who had gone through a divorce, and her ex had purposely gone out and run up a huge credit card bill with the goal of ruining her credit for five or ten years. That landlord in the first statement thinks his decision is just personal, but as a whole in society it adds up to a brick wall against so many situations that the credit model forgot.

3. ROI bias – more specifically, the bias in the corporate world toward earning a profit and bringing investors monetary reward. There are longer games that can be played which support other goals such as equality and fairness. Support for local communities, environmental sustainability, volunteerism in local schools already exist in some places. We can push for more, such as support for markets deemed unprofitable or support for groups who, in a generation or two, will be the foundation for new markets. Corporations are long-lived, I could argue that aiming for only short-term-profit is actually detrimental to their future.

4. Demographic assumptions – the generalized behaviors we imagine when hearing phrases like “people over 65” or “rural inhabitants.” I have been teaching people to describe audience segments by inner thinking rather than with shorthand demographic references. I also help professionals recognize red flags when encountering “tokenism” (or “caricatures”)–where a segment is painted with different ethnicity or gender (or where a segment is described using exaggerations), to symbolize the idea of “the other.” Examples are “Spanish speakers” or “low GPA students.” If you are aware of it, you can help people make changes.

5. Cultural blindness – the tendency for members of the privileged in any group to think of themselves as “average.” An example of this concept is “the social bubble” we’ve been learning about in the past few years. Even in your own neighborhood, there are people living a much different life with much different access to things you assume are distributed more widely. To end this list on a positive human note, here is an empathetic-mindset research project showing photos of families and homes by income all around the world.

The point of this “woke” list it to develop your awareness–to notice and recognize instances. Then give yourself and your team the power to choose again.


q&a

Q: (from Eduardo Hernandez) I saw your talk recently at Qualcomm for UX Speakeasy (Nov-2017) where you talked about the problem space. There is a lingering thought that I’ve had that I was hoping to get your feedback on. I often hear the term “create good mental models.” This statement specifies that mental models need creation rather than discovery. I am wondering isn’t it better to design an interface, for example, by discovering an existing mental model first, then building on that? Creating a design then attaching a mental model to it creates complexities, a level of abstraction, and allows you to rationalize the mental model to fit your design. Starting from a discovered or existing mental model and creating a design from there could potentially lead to better understanding. Where in the process should you concern yourself with mental models and are mental models created or discovered?

A: My initial response via email was hurried and probably didn’t address the question. Sorry Eduardo! Yes, I agree that, when it’s a team trying to create a product, mental models should be discovered. Mental models are only created by an individual, in their mind, representing a concept of the thing they are dealing with. Teams creating products are better off discovering the various mental models of different thinking-style segments they serve. Where in the process? Ideally up front, before product discovery cycles begin. However, in reality, this rarely happens. Luckily teams can discover these mental models at any point, and then guide the product in a direction more supportive of one or many of the discovered models. (I usually merge several thinking-style segments’ mental models together into one diagram, if they have a lot in common.)

Also, there are many definitions of “mental model.” The definition I use is “the model your team makes of the people they are supporting.” Another common definition of mental model is “the model a user has of the tool they are trying to apply to their purpose.”


indi can help you
answers, advice, direction, de-tangling of complex situations
private coaching
training series
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
double-check
try-it-out day
workshops, presentations, book club chats
presentations
training

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, aureliuslab.com, 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:

Amount……………For………..
$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&A

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&a

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
training series
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
double-check
try-it-out day
workshops, presentations, book club chats
presentations
training

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, indiyoung.com 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.


q&a

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
training series
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
double-check
try-it-out day
workshops, presentations, book club chats
presentations
training

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&A

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
training series
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
double-check
try-it-out day
workshops, presentations, book club chats
presentations
training

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