Episode description

The O’Reilly Design Podcast: Design sprints, Lean UX, Agile, and design leadership skills.

In this week’s Design Podcast, I sit down with C Todd Lombardo, chief design strategist at Fresh Tilled Soil and adjunct professor at IE Business. Lombardo is co-author of the recently released book Design Sprint. We talk about the relationship between design sprints, Lean UX, and Agile, and the skills needed to move from designing to managing designers.

Here are a few highlights from our conversation:

Design sprints are really a mix of scientific method, design process and agile philosophy—and agile is really a philosophy. There's 12 principles of working collaboratively together to solve problems, to ship software to customers that satisfies and delights them. That's really the agile approach; it's a philosophy. In Lean UX, sometimes ‘Lean’ is overused, but Lean in a sense means reduction of waste. You want to be as lean as you possibly can so you're reducing any waste and making your manufacturing process really, really efficient.

That same thing applies to the UX process: can we take out as much waste from the UX process as we possibly can, calling it Lean UX. It does have a similar approach because user experience is essentially a design approach, a design process, so they're incredibly similar. Oftentimes, Lean UX, especially in the book that Jeff wrote, has a framework or a process that he outlines, a process I see happening after a design sprint. After you've done a design sprint, do the heavy thinking and problem solving part of it, and then you've got to do a little bit more execution;  I would call them ‘jump starts’ at Constant Contact or we call them ‘intervals’ with our clients at Fresh Tilled Soil, but they're essentially a Lean UX cycle—the build, measure, learn wash cycle, I call it, of a lean startup type of mentality that you can use to continually iterate what comes out of a design sprint.

In a design sprint, you do build something, but you typically don't build a production-level product. Typically from agile, after a sprint, you would have something shipping to a customer. You put it into production after a sprint. With a design sprint, it doesn't necessarily get shipped to a customer; you might build what we call a ‘minimum viable concept,’ so it isn't necessarily something you're going to put in front of a customer as a production-level thing—you're putting it in front of a customer to test it with them and learn something. They both have that element of learning involved, so hopefully that clarifies the difference, a lot of overlap but still a difference between the three.

Be careful about boiling the ocean would be one mistake I see. It's really hard to tackle something too big in such a short period of time—not that it's not possible to think about, but you may end up with a lot more questions or a lot of stones that are unturned, and you may not have really had a prototype to get you in the right direction.  

The other one is almost the opposite: sometimes I've seen this happen in organizations where it's like they’ve got to do a design sprint because they have to check a box. ‘Oh, yes, we're going to go do this for a few days, and then we're going to make whatever we think anyway.’ I've seen that sometimes where teams do this and they feel like they're doing it because management wants them to do it and not necessarily embodying the actual outcome. That's another mistake I've seen where the team goes through the motions but they may not pay enough attention to what's actually happening, or management is for forcing the mechanism on a team when it may not be 100% right, or management's thinking ‘I'm going to have a working prototype at the end that's going to mean these features are ready to go.’

Sometimes they're done to confirm bias, which can be a problem: we're just confirming what we already know and that's a bias; you've got to watch out for that. Sometimes people are only paying attention to things that will confirm what they already believe, rather than listening to something that may go against it.

The other one probably would be the mistake of not spending enough time in the understand phase to really understand the problems. Sometimes teams assume they have a good understanding of the problem, and they don't really peel the onion back a number of layers to get into what the problem really is. There might be a symptom, and some people stop at the symptom level and don't realize that below it could be an even deeper problem.

Sometimes people think that being a good designer means they’re good at being a manager or a leader, and that isn't always the case. That was something that management has only started to really integrate into management and HR culture—somebody who gets really, really good at design, they're a good designer; if you turn around and now force five designers to report to that person and this person goes from designing everyday to now managing everyday, it's a significant switch.

Designers oftentimes may or may not have developed communication skills, so depending on what level of communication skills they've developed, they're going to have to really put an effort on that if they want to be a good leader because to be a leader means being a good communicator. Mike Monteiro talks about, if you can't sell the work, you haven't done the work. Part of making that jump from being designer to leader is your ability to communicate and essentially sell ... I need you to understand why I've made these design choices, I need to teach you. The ability to teach somebody will help you be a good design leader.

The ability to communicate and have that level of client [relationship], whether they be an internal client or not, even a coworker; ... if you're a designer in a product team, your product team is your client and you still have to be able to sell them on your ideas and your designs and your design choices and how they fit to the objectives that the business wants to achieve.