SATURN 2015: Design Thinking Is for You (Session Notes)

Font Llitjós began this conversation-style panel with a brief review of Design Thinking 101: “Design is not a product designers produce”; “design is a process designers facilitate.” Then she introduced IBM’s method, which includes four modes of design thinking: Understand, Explore, Make/build/prototype, and Validate/iterate.

In the old days, design was a black box, and a shiny thing came out and was given to the team to implement. The designer was disconnected from the rest of the process. Now, design has become a team sport and is not much different from development; it is a problem-solving approach that everyone can learn and get better at it. A designer facilitates collaboration of a diverse, balanced team who could go in many different directions. The team begins by trying to determine the real problem, considering a range of solutions, and then converging on a solution.

Changes are not limited to design and production, though. In traditional product development, users wait a long time before they get any value. In user-centric product development, users get a little value sooner, then a little more, and meanwhile the design team is learning more about the users’ needs, which informs the final product. Design thinking is for you: product managers, architects, developers, users, ballet dancers, everybody.

Font Llitjós: What brought you to design thinking?

Jeff Patton, the father of bringing agile and UX together and author of User Story Mapping, is actually an art school dropout. He switched to computer science, but being “the art school dropout” at his first employer’s organization automatically made him the UI guy because his UI sucked less than everybody else’s. Patton asked, “Have you ever watched a user use something your company has built? Was it shocking and painful?” Nobody ever says, “it was great; I expected everything that happened.”

Patton got involved in an agile project in 2000 that was using Extreme Programming. He didn’t like getting a customer product owner in the room and asking him or her what to build. The only way to get it right was to spend a lot of time with users and understand them deeply. But he needed a language to talk with them about what was important, and this drove him deeper into design practice. After agile, he realized the power of collaboration, and the traditional design process wasn’t so collaborative: experts went into rooms and came out with designs. Patton says that Step 1 is Empathize, not Collect Data. Jane Goodall goes into the field to understand chimpanzees; she doesn’t bring one into the office as chimpanzee-on-site to increase efficiency in gaining understanding of their needs. You have to go where the users are to see what kind of pain you are inflicting on them. Once you look customers in the eye, you will not prioritize the backlog in the same way that you used to.

Jonathan Berger was an interaction designer, suffering from the usual challenges: When will that be done? What will “done” look like? He learned a different approach from a team of developers working on a more agile process, so he began looking for ways to join an agile team and discover what it looked like to bring those techniques to design. Design thinking can get lost and separated from development: “they’ll design it and we’ll figure out how it works.” But design thinking is not just about how it looks – design thinking is also about how it works.

Font Llitjós: How are agile and design thinking similar or different?

Berger thinks they are both implementation methods that optimize for low cost of change, quicker production, and human-centered rather than requirements-driven processes. A key difference is the time to plan comparted to the time to build. Traditionally, designers would get the plan right, then hand it over to the build team. Now the cost of plan and build are closer; you don’t have to be right the first time, you have to be just right enough, and you continue to make it more right after the world tells you what “right” means.

Patton thinks that agile isn’t about learning as much as design thinking is. Scrum’s burn-down chart sums up all the stories that have to be built. It starts with the assumption that we can create a backlog for what to build and then burn it down in three-week or two-week sprints. But if he focuses on learning, it’s a build > measure > learn cycle, and he can get around that loop in hours, not weeks. You can’t backlog learning, and with each iteration, learning changes what you do next. He doesn’t care if learning results in working software. You can have a paper prototype. But you can’t burn down discovery work easily.

Audience: Is design thinking universally applicable? And if not, what criteria determines when it can be used?

Berger cautions that there are no absolutes; it’s always a spectrum. On one end there are rapidly proto-typable web-based apps, and on the other is designing for a space shuttle. But even on the critical side of the spectrum, there could be more checks on determining if we’re doing it the right way, and agile brings in the concept of continuous improvement. Even if your design was set on Day 1, you might still be able to use design elements for process.

Patton emphasizes that one thing he does is get people out talking to their customers. But what if you design fuel pumps? The empathy stage might be replaced by another kind of deeper understanding. You could still think up multiple solutions and prototype several solutions. Still, design thinking works best when “things” matter less and when you can ship with minimal testing.

Audience: When do you impose constraints in an iterative process?

Patton remembers a workshop that included traditional software architects and UI folk, arranged by Microsoft before they came out with a lot of .net stuff. Microsoft wanted to shed an image of building applications that suck, and they did it pretty well. These two roles go together and need to collaborate. The Find stage, before you Ideate, is when to consider constraints. They come not just from user studies but also from architects. A project needs people who are focused on constraints; you want to include the voice who’s thinking up what could go wrong.

Berger reminds us that this is an opportunity to turn empathy inward. Get away from “I’m the architect, and I get to make these decisions. You’re the designer, so you decide that.” The better we get about dissolving these barriers, the better we can do.

Audience: What about those who say “agile is great for ‘them’ but it won’t work for ‘our’ architecture”?

Berger thinks it comes back to the team sport mindset, or job security, or ego. But some people are just scared and need a little help, and you can usher them there. Patton wrote the book StoryMapping as a way to look at a backlog other than one thing at a time, to see the big picture. Every time you ship something, you learn something, and, sadly, sometimes what you learn is that the architecture was no good. Moses didn’t come down from the mountain and say, “there must be QA.” DevOps incorporates separate groups into day-to-day collaboration. Architecture can be left to naturally emerge for some projects, but not others.