danryan.us

I come to human centered design and design thinking via less well-trod paths. My degrees are in the physical sciences, mathematics, and sociology, not design, architecture, or business. When I first formally encountered the practice about six years ago, though, I had, for the third time in my life, the feeling of finding an established discipline of something I'd come to think of as a personal predilection.

The first time was when I began to study computer science many moons ago and found that I could "get in the head of a machine" and make it do things, almost anything. And then learned the same thing about digital hardware.

The second time was when I first encountered the work of the sociologists Erving Goffman and Alfred Schutz in my very first week of college. In their works I found written down explanations of how the social world works that I felt like I'd been struggling with for years.

And then a few years back I had a match dot com date with an architect MBA who worked at IDEO and then I saw the shopping cart episode on night line and again, I was hooked: my god there are people out there who think like I do.

But you asked for some remarks about how I use design thinking. Since I'm not a designer or an architect or an engineer, my tale of how I use DT will be a little more about how I use it to communicate some fundamental lessons about the organization of creativity.

Organize

Another was my doctoral dissertation which became the book The Ghosts of Organizations Past. The project was a multi-city examination of why it was so hard to form community coalitions against substance abuse.

The program we were evaluating was pretty much a disaster. In city after city scores of organizations sat down together, agreed on what the problem was, identified what they could do about it, implemented their plan, and went SPLAT. The police did not get along with the hospitals. The substance abuse treatment providers did not get along with the ministers. The neighborhood leaders did not get along with the ex-junkies. The health department did not get along with the fire department. How, I wondered, could so many like-minded, smart, and motivated people who clearly wanted the same outcome fail so spectacularly?

I never managed to answer that in so many words, but I did come to understand something fundamental that lay behind or underneath the challenges they encountered: collaboration is hard. It's not only hard, it's arguably UNNATURAL.

What does this have to do with design thinking? One element of DT that is frequently not talked about explicitly is that there is a method to the madness. A gigantic part of the bonus that we get from DT derives from the structure, the very explicit organizing of collaboration, the way we take turns, the way we cultivate creative listening, the way we "force" iteration forward feedback, the way we deliberately oscillate between divergent and convergent thinking.

Just one example. When we return from our research phase each of us is full of information about the world, about our potential users. If we have 5 team members then each one is in possession of 20% of what the team knows. How do we (efficiently) transfer this knowledge "to the team"? IDEO calls this step "downloading" our data. At a design thinking Meet up a few months ago I watched as this phase blew up as the leader said "who wants to start?" and initiated a chaotic 15 minutes in which some people talked too much, others not at all, bad ideas got amplified, good ideas got lost.

One method is for each of us to jot our observations down on post-its and then we share them with one another. But here's the important part. There is a tendency, especially if we either know each other really well or don't know each other well at all, to "go all informal" at this point and just ask someone to start and then we praise each other's contributions and note that we found similar things and maybe we stop now and then and ask the quiet person if he has anything to add. Wrong. Wrong. This is one of those points where we want to impose some structure so as to get the most out of one another.

We might add a caption: YOU IDIOT, A MEETING IS SOMETHING YOU HAVE TO ORGANIZE.

And not just meetings: creativity itself, at least collaborative creativity, is something you have to organize.

Seeing & Hearing

Empathy is not an emotion. One of the most challenging aspects of innovation education is to train really creative people to see and hear other people.

When I build a team or a committee to address some problem I select energetic and creative individuals. And when I bring them together, almost without fail, their initial inclination is to start offering clever and creative ideas right from the get go. And that's when I say "STOP."

This is a challenging moment for the creative person. But it's absolutely critical because at that moment I am reminding you that YOU are not the human in human centered design. Someone else is, and you first task is to go talk to that person. Or watch them. Or survey them. Or set up some unobtrusive data collection mechanism so that you can learn about them.

One could organize an entire lecture - or a whole course or write a long book - about WHY this is important. But the simple fact is EMPATHY is EMPIRICAL, not EMOTIONAL.

The single most important contribution of the social sciences to humanity is the mandate to be empirical when thinking about human behavior, the idea that you can learn about humans by watching them, talking to them, measuring them and that these processes are fundamentally superior to introspection and projection. This is critical in political and policy conversations - we work hard to get people to be able to recognize - almost as a reflex - that something is an empirical claim - it's not something you just choose to believe or not and it's not something that you can figure out logically whether it's true or not. Instead, you have to say, "we could find that out."

And for the would-be designer and problem solver it is paramount too. You are almost never going to be tasked with solving a problem you have and yet most of us have a very hard time stretching ourselves beyond that.

An Aside on Empathy-Driven Problem Identification

The "research your user" aspect of empathy is one sense in which it is an action, not an emotion. Another lies in how we orient ourselves toward finding human problems worth solving in the first place. To this end, it is sometimes useful to engage in very deliberate perspective shifting and perspective expanding exercises. Name 5 "realms" in which humans have problems worth solving. Now name 5 more. Within some of the realms that I named but you didn't, identify 10 problems worth solving. Etc. Exercises like this are built around the acceptance that empathy is hard and, like collaboration, not natural. But that's good news, because that means it can be cultivated, trained, and organized.

Refine stepwise

Perhaps the most important paper I ever read was Niklas Wirth's 1971 paper "[http://sunnyday.mit.edu/16.355/wirth-refinement.html Program Development by Stepwise Refinement."¹. Let's just read the abstract of this article:

The creative activity of programming - to be distinguished from coding - is usually taught by examples serving to exhibit certain techniques. It is here considered as a sequence of design decisions concerning the decomposition of tasks into subtasks and of data into data structures. The process of successive refinement of specifications is illustrated by a short but nontrivial example, from which a number of conclusions are drawn regarding the art and the instruction of programming.

In the article Wirth teaches us to break problems up not vertically or horizontally, but rather in terms of focus and zoom. We start by zooming out far enough that we can only see the general shape of the problem. We see that the thing we need to create has a beginning, middle, and end but we can't make out the details inside the beginning, the middle, or the end. We treat each as a "black box." Once we have worked out the relationship between the parts at this level of zoom, we adjust our lens a bit and look more closely at each of these black boxes. But still we defer as much detail as we can.

Our entire process is built around the idea of deferring attention to detail. For programmers this creates confidence in high level structures and it facilitates the specification of requirements for each module we have to code. We find ourselves saying "I don't need to worry for now about HOW the code will do this, but I need to make sure that this is what I need the code here to do."

This technique works in almost any problem solving context. It's important to realize that we are not saying "don't pay attention to detail." We are saying "don't pay attention to detail before you have to."

THAT MOUSETRAP

"If you build a better mousetrap, the world will beat a path to your door." Well, this is not exactly true - you probably have to spend a ton of money on marketing before the world will know about the mousetrap. But the sentiment is an important one. In particular, the idea that we should put all of our soul into the "better" part.

Last semester I challenged my students to re-design what our college calls "RegFest" - an afternoon when faculty sit at tables in the quad talking to students about the courses they will offer the next semester and the requirements and benefits of various majors. The school administration thinks RegFest is really important, but faculty hate it and students generally give it a skip. And so the teams set about the usual design thinking process: research, ideation, prototyping and then we did a preliminary review. Almost every single group focused on how to incentivize students to attend: require it, pay them, offer free food, give extra credit in classes. I was loathe to crush their enthusiasm, but had to point them in a different direction. "I want you do go back to the drawing board," I said, and imagine a RegFest you could charge admission to and get record breaking attendance.

They scoffed at me, but eventually most of them saw the point: you are designing FOR the people you are designing for. You need to meet their needs and desires in a manner that actually does motivate them to beat a path to your door. But to do that, you have to really know something about what their better mousetrap is.

Let the world speak: PROTOTYPING

One of the fun parts of the design thinking process is prototyping. Getting folks who are used to working only with words and ideas to take up scissors and glue and pipe cleaners and colored paper and to do this working with other folks brings a smile to the face of all involved.

But in my experience there is something much more important going on here in terms of practice in support of creative problem solving. Consider a point made by Bret Victor under the heading "inventing on principle"²: what's going on when I sit down to so some dynamic graphic programming or animation programming. If I am really good, I can imagine a scene I'd like to create and I can type the code that will make my graphics software produce the scene.

But what's going on when that happens? The engineer understands the programming language and the machine well enough that she can simulate it in her head, she can think "if I code like this, the machine will do that." But is this a good use of her head? That's a lot of cognitive bandwidth devoted to simulating the computer - which is sitting right there on the desk in front of her.

And we do this all the time - we simulate our users, our clients, our friends - we run thought experiments in our head: "how will she respond if I say this…?" In sociology we call this "taking the role of the other" - it's a basic building block of the social world. It's only by internalizing the reactions of others that we can successfully orient ourselves toward them in our execution of what Max Weber called "meaningful social action" - action that takes into account the reactions of others, the foundation of everyday life.

But it's not always the best way to proceed. When I want to throw myself at really hard problems, I need to harness as much of my cognitive horsepower for creativity as I can. I need to maximize the creative collaborative contribution I get from the world around me and my teammates and my users. And to do this I have to put something out into the world so that it can grapple with the thing and talk to me about it. What I don't want to do is to spend all my creative energy simulating the world. For one it's just too hard, it takes up too much cognitive bandwidth. And for two, it's energy I'm not using generating new ideas based on what the world is telling me.

Resources

• Slides from Talk (KEY) (PPTX)
• Slides from Six Hats Talk at IYA (KEY) (PPTX)
• "Six Hats in (about) Five Minutes" video
• Design Thinking in Higher Education course trailer
• https://youtu.be/ktwr_EQaeCo Legal Design Lab] course trailer