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
group coaching
coffee with indi
research delivered to you, when your resources are short
custom research
heavy lifting
team mentoring
figure out if this is the right research at the right time
double-check
try-it-out day
workshops, coaching, 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

newsletter #30 | 21-Nov-2017

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

newsletter #29 | 17-Oct-2017

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

newsletter #28 | 19-Sep-2017

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

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

This webinar builds awareness of cognitive bias when it comes to being “data-driven,” and clarifies the differences between the problem space and the solution space. I introduce mental model diagrams, Read More

newsletter #27 | 15-Aug-2017

When I wrote my book Practical Empathy, I chose my vocabulary carefully. I was thinking of the many clients who got distracted by the words “feelings” and “emotion,” who got great laughs by turning a listening session into a Hollywood psychoanalysis session. “How does that make you feel?” (They were pretending to ask this of their customers, who were engineers trying to solve systems problems.) Read More

newsletter #26 | 18-Jul-2017

Ideas are sexy. You get attention and credit if you have good ideas; you and your organization gain success if your ideas really catch on. But there’s not a heck of a lot of focus on where great ideas come from. We just assume they will show up, leaping like a goddess from our foreheads. Consequently we focus all our resources and effort on perfecting these already-generated ideas. It’s time to mature your practice of creating ideas–the stuff that comes before an idea forms. Read More

newsletter #25  |  20-Jun-2017

Last week I apparently caused a short Denial of Service attack on my own website when I asked listeners at the Agile UX Virtual Conference to look at the problem/solution diagram on my website. Read More