time out

newsletter #31 | 19-Dec-2017

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

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

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

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

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

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

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

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

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

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

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

thought provoking

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

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

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

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


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

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

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

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

What’s our best fit?