Scott Berkun: How Design Makes the World – Episode 91

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS

Scott Berkun can help you understand design.

His new book, How Design Makes the World, helps both practitioners of the discipline and consumers of the products that they create understand how design shapes our world.

We talked about:

• his journey from computer programming to UX design
• his early switch at Microsoft from UX research to project management
• the distinction between building things and designing things
• the hazards of building things that don’t solve a problem
• his take on the concept of “design maturity”
• how the rise of the consumer web and then the rise of mobile apps accelerated the growth of UX practice
• the lag in the adoption of UX practice in enterprise products
• how being right and having a good idea is not sufficient to actually change organizational decision-making
• the importance of being able to persuade others of the relevance and desirability of your design ideas
• his intent to give designers tools to democratize the design profession
• how truly hearing and empathizing with key stakeholders works better than evangelism to get them to appreciate your work
• the “aha!” moment when he discovered systems theory and thinking
• how allegiances to UX practice specializations can impede the progress of good design
• the superiority of non-binary thinking

Scott’s bio

Scott Berkun is a bestselling author and popular speaker on creativity, leading projects, culture, business and many other subjects. He’s a former interaction designer and project manager who worked for many years at Microsoft and WordPress.com. He’s the author of eight books, including The Myths of Innovation, Confessions of a Public Speaker, and The Year Without Pants. His work has appeared in The New York Times, The Washington Post, Forbes, The Wall Street Journal, The Economist, The Guardian, Wired magazine, USA Today, Fast Company, National Public Radio, CNN, NPR, MSNBC and other media. His popular blog is at scottberkun.com and he tweets at @berkun.

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 91. Scott Berkun is a prolific author. He’s written books on project management, public speaking, creativity, innovation, and remote work. His latest project is How Design Makes The World, a really accessible book that can help anyone better understand and appreciate design. If you’re a professional, it can help you explain your work to friends and colleagues. If you’re just curious about the field, it can help you understand how the things around you came to be.

Interview transcript

Larry:
Hi, everyone. Welcome to episode 91 of the Content Strategy Insights podcast. I’m really happy today to have with us, Scott Berkun. Scott is a well known author, he’s author of eight books now and the reason I asked him on the show is his eighth book, his latest book, How Design Makes the World really caught my eye. It’s kind of a companion now for me right alongside Don Norman’s books and then my other design shelf as sort of a really accessible book about how to explain design and how it shapes the world. Welcome, Scott. I’m curious about, I think a lot of people know you as a product guy and an old school Microsoft PM sort of person, but you have over the years, you left Microsoft, became a book author and now you’re writing this brilliant book about design. Tell me how that came to be.

Scott:
Sure. Thanks for coming on the show to begin with. Wanted to be on the show for a while and I couldn’t make it happen. I’m excited that I’m finally here. Yay! Go us.

Larry:
Likewise.

Scott:
Yeah, the story is a circle. I was in college. I studied computer science. I learned, I discovered I was not a very good programmer. I was a mediocre programmer. I was good at the first part. I was good to figuring out what the problem was. I was good at trying to figure out the basics of how it would work and then once I got something limping along as a prototype, I started to get bored and I didn’t really have the engineering mentality of making things perfect. Or if I did, it was not fun. I started looking around in the course catalog, this is halfway through my college degree. What else can I do? I need to get a job when I graduate and make a living.

Scott:
And I flipped through the course catalog and I discovered these classes. This is 1993, 1992, 1993. These classes that were about design. And I started reading about them. I’m like, this is exactly what I’ve always been interested in about things. I’ve always been curious about how things are built and made. I didn’t know there was a degree and a program around design. I took those classes and I loved them. And it was a sweet spot for me and how my brain liked to work at solving problems and coming up with ideas, but it wasn’t engineering. And so I hoped to graduate with this combination of tech knowledge, but design knowledge and get a job in what then was called interaction design, which is now pretty much called user experience design, but I couldn’t find a job doing that.

Scott:
1994, it really was not a viable career path. I managed to get into Microsoft by being a user researcher. I’d studied enough human factors, HCI stuff, while I was in college to get hired doing that. But then after a year I realized I got tired of giving other people advice and being a user researcher is basically being a consultant. That’s when I made the switch to be a PM. It was the one job that allowed me to have this diverse set of skills, some technical background, a lot of design knowledge, good communicator and become a team leader at a very young age. And that was my first career for 10 years basically, I was a PM on different teams, often teams that had a lot of user experience work, but sometimes not. And that’s what I did.

Scott:
And to finish up the story, to answer your question. When I quit to try to write books, the first book I wrote about was my experience managing projects and making things happen. It’s this book about everything I learned about managing projects. I’ve written six other books and then I finally realized that my deepest love, the thing that ties me together with how this hope to make a better world is through making things. Design has always been central to how I think about things. It’s just, I finally got around to try and distill everything I knew about that over my career into a book. It actually goes back to the beginning. It’s not a departure. It’s just that it’s a return to my origins as a professional adult.

Larry:
And there’s something in there about living in the Northwest and salmon, but I’ll leave that aside. But no, but in there you talk about that distinction between design and engineering is really interesting because one of the things you talk about a couple of different places in the book is about designing versus building. And you use a really stark example of the Segway I think it’s got a great opening anecdote and a lot of other stuff about it. But can you talk a little bit about that? Because I think the Segway is the classic example of this dynamic you’re talking about.

Scott:
Well, the distinction I make in the book, there’s nothing wrong with being an engineer and building things. But if you’re an engineer, that word tends to mean that your job is to engineer the thing. Your job is to make the wheels turn at a certain speed. Your job is to build a router for the internet that can pass through data at a certain rate. That someone else is probably doing the requirements, someone else is probably thinking about what problem we’re trying to solve. You can engineer something really well and still not solve a problem because you’ve engineered the wrong thing. And that’s what I describe as building and most people who are good at building, just like to build. When I was a kid, I loved to make Lego and I loved the process of building. I used to think it was fun to come up with an idea in my head. I want to make a castle, it looks this way. Little by little, I realized it was just fun to build. Once the building was finished, I was bored. I wanted to build something else.

Scott:
Most people who are engineers or developers, people who have the ability to make things, they tend to have the bad habit of making things that are interesting to make even if it doesn’t solve a problem for anyone else. And we’ve all used those products, many of your listeners have probably been on product teams or in organizations where this thing is being made that’s kind of bad. It’s kind of lousy. And you’re trying to convince them to steer the ship in a different way, but they have a culture that’s more focused on the joy of building rather than the satisfaction of solving problems. And that’s why that distinction comes up early in the book. A lot of people get paid a lot of money to build things that are not very good. And design is the answer. Understanding how design is done satisfies the problem and now there’s this other skillset that needs to be paired with building and in combination that’s how great things get made.

Larry:
Right. In that product development eco-sphere, it’s sort of like the design is the thing that slows you down and makes you reflect on that problem.

Scott:
Yes. Yes. And the other obsession, not obsession but bad habit you’re calling out is the obsession with speed. That you have a project team or an executive and nothing’s happening. Developers are idle, let’s start building stuff. Why? Because we don’t want idle developers so let’s go. And anyone who has any wisdom or experience is shaking their head. They’re like, this is the wrong way to go. We can go really fast. We’ll probably go in the wrong or stupid direction unless we have someone who’s thinking about the design who’s able to do that ahead of the engineering team to some degree.

Larry:
How have you seen those roles evolve over the last, because you probably saw it starting when you were still at Microsoft, because you were there until about early 2000s I think, so up to about 17, 18 years ago. And that sort of evolution of here’s just a number that comes up all the time when I talked to people. Roughly in digital product teams, there’s a 100 engineers, maybe 10 designers, maybe one poor content person off to side, is a very typical ratio. What was it like when you were there? What was the relationship between when you were shifting in that PM role into your design hat versus the engineering just do, do, do versus think, think, think?

Scott:
Well, it varied a lot even back then and it varies a lot now. The best term I know about this is what in the book I call design maturity. Other people have used that term and by design maturity I mean, just it’s really organizational maturity, the ability to think through what problem you’re trying to solve, to plan it properly, to engineer it properly. That’s just organizational maturity. And the problem in many organizations that make lousy things is just they’re immature in how they manage the process of building stuff.

Scott:
When I was at Microsoft, I had mostly good experiences where the management team understood that the project. The PM role was this coordinator between the roles to make sure that engineering had enough good thinking done before they began doing their work, that the content creators, the people who wrote content were integrated in the process at the right time. I had mostly good experiences, but again, maturity is not uniform across an organization.

Scott:
Later in my career, I worked in other groups and it was much worse and the engineers didn’t like the PM, so they didn’t get along very well. And if the engineers and PMs don’t get along, then the designers are frustrated because there’s confusing decisions being made. And then it all tends to fall apart even though the ratios may be correct, that you have whatever you believe the right ratio is. 10 engineers to two designers to one PM to one, whatever. The ratio is one thing, but you can have the right ratio and still have an immature culture that doesn’t respect roles. And so I’ve seen a wide range of those things while I was at Microsoft. But even now all the places I visit and consult with immaturity, maturities, there’s such wide gaps even today about that.

Larry:
Yeah, that comes up and you’re right a lot of people talk about maturity, practice maturity of various kinds. And it’s always all over the map. And even within any one organization or even within a team, you can have that. But one thing that seems to be on a pretty good upward arc is the maturity of the UX as a discipline. Is there any rising tide lifting all boats coming along with that do you think?

Scott:
I think that what happened in the mid 2000s, the rise of the consumer web and then the rise of mobile apps and how the ones that did the most were the most successful often had, they were better design. The user experience of those apps were simply better. And that validated for the business world and for the venture capitalists, that design is actually a key part of business strategy. That definitely was the transformation that I saw. But you have pockets of the world where that hasn’t happened. The enterprise being the most glaring one where the reasons why products are sold in the enterprise, why the company you work for chooses one email application over another or whether they go with the Microsoft suite or the Google suite has to do a lot with decisions that are not about user experience design.

Scott:
There’s still plenty of products in the world and organizations that have user experience people there, but they’re largely ignored because they don’t have a good enough argument yet for how they affect the choice of purchasing. Again, I think it’s rising all boats is too optimistic. I think there are always pockets where the business model and the culture, even if those people are hired, they’re mostly ignored. And there’s work to be done on evangelizing and making the argument persuading decision makers why design matters, even in those cases too.

Larry:
You talk a lot in the book about those kinds of dynamics like Someone Has to Pay, is the title of one of the chapters and the dynamics behind that. And also, but maybe more germane to what you were just saying, I think one of the chapters is called The Powerful Decide and those dynamics and to what you were just saying, okay, I as a UX practitioner, a designer, whether you identify as UX practitioner, but I as a designer know that this is going to help the organization and the product, if we can do this better. Do you have any success stories for folks who have done that?

Scott:
Well, I think that’s one of the chapters. One of the goals of the book was to cover all the parts of design that are critical, that often get left out. That a book on design typically talks about user experience, talks about usability, user research, aesthetics and that’s all great. That’s important. But these other chapters in the book, The Powerful Decide, is meant to puncture the romantic mythology that many designers and content creators, content managers have that simply because they are right or have a good idea, that should win. That should be the decision. And the history of making things tells us that’s not true. It’s not the way it works. That you being right and having a good idea is not sufficient. It’s important, but it’s not sufficient.

Scott:
You could be selling as a great content strategy for your organization, that the website and internal documentation is so broken and you have this great idea, this great strategy. You write it up. You draft it. You make a mock up of it. And at the first meeting you present it, you are shot down and you feel like, how could this be? I’m a good content strategist. And the answer is that in that meeting and that discussion, the people who are decision makers don’t know what you know and they often have little reason to want to know what you know. They feel like they’re empowered to make decisions.

Scott:
Many of the bad designs we experience in the world come from them. People who are not informed about design or content or accessibility or usability, but they happen to be the decision maker. It could be because they founded the company. It could be because they’ve got promoted into a position that now calls out the ignorance that they have, but the power structure defines the design. The power structure defines the content strategy, which implies to anyone who’s listening to go, yeah, that’s true. And I hate it. Is that then persuasion, political ability, the ability to create allies, those are all just as important to the outcome that will go out the door as your content strategy or design ability. And so that’s why, I’m sorry, go ahead.

Larry:
No, that comes up all the time in these conversations is that it’s, we’re really cultural change ambassadors, as much as designers or content people or product managers or whatever. And do you have, I know one of the things and I’ll link to the book and to the, I think you did a blog post about you have the four questions that you ask about design, but I’m wondering now if you have questions that you ask about that process of persuasion and influence and cultivating your effectiveness inside an organization?

Scott:
Absolutely. And some of it’s implied in the book. The book is not a how to manual on being persuasive, but the implication in the book comes to simple advice, which is again, if you are a good problem solver, if you’re a good designer, I think content strategy is a kind of design. We so fractionalized the working world into all these subdivisions of who does what, if you are making a decision that has something that changes something that would go on a screen that some user has to see, you’re doing the kind of user experiences I’m working. I’m very open minded about all these things fit together. The question then becomes, do you have the power to make this decision? And for many designers and for many information architects and for many content strategists, the answer is no. That you’re not really the decision maker.

Scott:
There’s a PM, there’s a lead engineer. Maybe you’re involved in the decision, maybe you’re in the room, but your job is not to be the end decision maker and break the tie. And if that is you that’s great, then you probably don’t need to worry about this. You’re like, ha ha I’m the decision maker, great. But for everybody else, okay if you’re not the decision maker, then you have to work backwards. Okay, who is the decision maker? What do I know about them? What kinds of arguments do they like to hear? Do they prefer data or stories? What kind of reputation do I have with them? Do they know who I am at all? If I have a good reputation, how do I grow that? Maybe that if I have no reputation, then who do I know that I have a good reputation with who is influential to the decision maker?

Scott:
Once you start breaking it down into a design problem, now it becomes approachable. You can break it into little pieces and recognize there’s a different kind of strategy that you need, which is how to gain influence. And that’s slow. It’s a human process. It’s cultural. You have to earn the reputation and it’s work. And it takes time. And a lot of people say at this point, they’re like, “I understand logically all those things, but why should I have to do it? I’m a content, I’m a designer. I’m trained. I’m an expert. Why?”

Scott:
And the answer is you don’t have to do it. You don’t. You can show up and make your pitch and then leave and feel all right. You don’t have to do it. But if you want something different to happen, if you want them to actually not just ignore you, that’s why. That’s how it works. And some organizations are healthier, more mature than others. More receptive to, you say cultural change agents. Some groups and managers are way more receptive to that. If that’s really what you want to do then where you work is important, but for roles like all the ones I’ve mentioned where you’re usually not the decision maker, this is half the job. A third of the job, a large percentage of the job.

Larry:
Now, I don’t know if you’ve decided on what your next book is, but I’m kind of hoping you do a leadership book now about expanding on all that stuff you just talked about. But one of the things in there that you just mentioned is about this idea of there’s a lot of ways that design information gets distributed and there’s sort of design thinking. This notion, Don Norman now is working on democratizing design, but there’s also I think to what you were just saying about, well and just the idea of evangelizing your discipline as a designer. Give me your thoughts about that. Kind of beyond the product or project level influence, how we as sort of a profession can be more evangelists and not that we all need to be evangelists.

Scott:
Yeah. Well, I think there’s a couple things in there. first I used the word evangelism and I shouldn’t have, I really hate that word. It’s the only word that we have in the tech world. We borrowed it from the religious communities. And I think it’s a weird word to use. One of the reasons why I wrote the book was to help people who feel like they understand design, but who work in groups that don’t or work for a manager that doesn’t or an engineer that doesn’t. And the goal of the book was to do a lot of the heavy lifting. It’s a fun book. It’s all stories. There’s not a lot of lecturing like I’ve been doing so far in this chat. It’s all stories that were an insight into how good design happens and why it doesn’t. The goal of the book was just to do that, to democratize design and give designers and people who care about design, a better tool to do that.

Scott:
Now, outside of that, the word evangelism is bad, but I struggle with it because that model is the model of you go with an agenda and literally a Bible in your hand to a stranger’s house and knock on their door and say, “Hi, I’m here to convert you to a new worldview,” which is a really arrogant and probably not very effective way to persuade anybody. I’ve never been persuaded, but I think it’s not a very design centric model. It’s not very empathetic. A better way to go about this is to start with the person you’re trying to convince. In our scenario, you’re a designer, you’re a content strategist, you have a project manager or boss who usually rejects your ideas. Doesn’t get design at all. Fine. You start with them, ask them, “Can I have five minutes to chat with you? I had an idea I want to run by you. Something I want to talk to you about, we’ll give you five minutes.”

Scott:
The first thing you ask is tell me something that you love to use. Something you love to use. Start on their turf, no terminology, no methodologies, none of the things we try to hit people with. Hey, what do you love to use? And they’ll tell you something. They may be either their car, maybe a video game you like to play. It could be a walk, a hike they like, whatever it is. And then you ask them, “Okay, tell me about why you love it.” And if it’s a thing they’re talking about, they’ll break it down often using terms that are in the UX design wheelhouse. They’ll say, “I love to drive my car. It’s satisfying. I never think about the steering wheel while I’m driving. It responds to my wishes without interrupting.” They’ll have language that’s not that far from design language.

Scott:
Then for the second half of the five minutes, ask them to tell about something they hate. What do you hate to use? Maybe it’s filling out a tax form. Maybe it’s a corporate SaaS app they have to use to fill out their expense reports. It’s just terrible and frustrating. Get them to tell you about that. Why do you hate it? Well, it’s confusing, it’s inconsistent. They’ll use design language probably in some way. Then when you’re done with those five minutes say, “Okay, look what you just talked about, what you love and what you hate the gap between those, that’s my skillset. Closing that gap. All my training, my expertise is how a thing that exists that’s not so good, make it so that it’s better and people will love it.”

Scott:
Now, if you come at it that way, you’re on their turf in their world. You’re telling them, you know how to make things in their life less bad, but they will hate less, they’re going to have questions. They’re going to say, “Really? That’s what you do?” Because all the methodologies and stuff we usually throw people, it’s so complicated and abstract they may not have ever thought of your job that way, but once they do, they’ll ask you questions. And then there’s an opportunity for you to say whatever is the thing that you’re not getting support for. Now they understand what I do. Can I try and have something small, that’s actionable, that you want to change that hasn’t been changed before. And if you approach it that way, you’re using storytelling narrative, it’s on their turf. You’re solving a problem for them. Your odds of them saying yes are much higher. And then you’re on your way.

Larry:
And there’s way more listening in that scenario that you just described than in an evangelism practice. Yeah. And there’s a move in the, I see a lot more now in the startup world, the title and just the tech world in general, the title of DevRel, the developer relations, as opposed to evangelism, which I think is more in that it’s a different role. Anyhow. Yeah, that’s an interesting thing. That kind of gets just that notion of that. . . I wanted to ask you about systems thinking as well, kind of a follow up because that sort of gets it, these are all systems, people systems, design systems, technology systems that have to come together. And that accounting for the way you were just talking about that you’re accounting for a lot of different things in there, which is sort of like a system. Did you explicitly or specifically take a systems approach in how you look at design?

Scott:
Yeah, I think it’s one of these things. I mentioned before, when I learned there was this thing called design, this is a profession and these classes, we can study how to make things that are easy to use, it blew my mind in part, because I had in a small way, intuitively been curious about that. I just didn’t know how to label. I didn’t know what that it had this whole history of studies and books . . . and so systems thinking is a similar thing. I think anyone who has played on a sports team where there are all these parts and roles that have to fit together and when it’s done well, it’s a system that’s working really well. The first time I came across systems theory, which is probably in college, there was a similar experience, I’m like, ah, there’s a name for this that’s universal.

Scott:
It applies to my basketball team. It applies to how the highway system works or doesn’t work. It applies to everything. This notion that there are feedback loops and complicated interactions between parts and that the reason why one part fails might not be the failing of the part, but that the system is not working well so that part ends up failing. That has always pervaded my view of many things and once I knew there was a language for it, it became a deep interest of study. And so systems thinking comes up in the book in a few places, but I didn’t want to spend that much time on it because it’s so quickly derails into being its own subject and the goal of a book like this is to be very practical and direct and allow people to engage without having too much theory in it.

Scott:
I wanted people to ask the question, “Why is that window in my house designed in a way that’s hard to open? How did that happen? Why is the software I’m using, I use a 100 times a day and I make the same mistake 90 times out of a 100, why did they design it that way? How could that have happened? And how on the products that I make can I look for those kinds of problems that I might not have noticed before? And then how do I know what to do about them?” that was the goal of the book, but just some systems theory comes up in a few places in the book, I think.

Larry:
Scott, I can’t believe these conversations always go so quickly. We’re coming up close to time. I want to make sure, is there anything last, anything that’s come up in the conversation that you want to elaborate on or just generally on your mind about design?

Scott:
Well, I think I’m going to start you reading something that I said is that I understand why we have so much specialization in the profession. Why we have as user experience designers, those graphic designers, information architects, there’s now UX writers, content designers, content strategists, and I understand the need for that because we have specialized teams and those kinds of expertise are needed and to be called out and developed. But mostly in practice, I feel like those allegiances, so those narrow specializations, work against the greater goal they all have of making better things for people. That I think a lot about being an entrepreneur. As an author, I’m effectively an entrepreneur.

Scott:
When I sit down to write a book or if I was starting a food truck on my own, was doing it on my own, I’d have to do things that cover 20 different specializations, just to make the food truck. I’d have to engineer and design the kitchen space. I’d have to think about the marketing. I’d have to think about the information architecture for my menu. I’d have to think about the content design for my web. I would have to think about 30 different specializations, but when you reduce it all down, it’s all the same thing that’s experienced by the customers.

Scott:
I guess the thing on my mind a lot is whenever I hear so much of the stuff that goes by, people write about this aimed at such a narrow specialization. I feel like sometimes we are hurting ourselves and the greater ambition that we have. That calling out content strategy and acting as if it’s somehow divorced from the engineering that has to be done and the user experience work that has to be done, which happens a fair amount is we’re kind of our worst enemy and the greater goal of having a better world with better things in it that solve more problems and are more accessible. That’s my only thing I think about in these conversations of we should have specialized expertise, but practice thinking of the system and how it all has to fit together.

Larry:
I want to run something by you real quick then, because you reminded me about God, I was in Seattle about six or eight years ago, I remember there were back to back presentations about a month apart. First one was Jared Spool talking about his talk that everybody’s seen about it’s a great time to be a UX designer. And he had this kind of popcorn slide of all of the different interaction design and research and content design and all those aspects of it. And then the very next month. And I can’t remember if it was, it was like SIGCHI or IXDA or somebody. There was a follow-on presentation where this guy talked about the T-shaped UX designer. That they have broad knowledge across the discipline and focus in information architecture, interaction design, or visual interface design. Is that a solution, taking a T-shaped approach?

Scott:
Well, I think that I like the notion of T-shaped things. I think that better reflects how people actually are, that they usually have one depth. And maybe it’s not even T-shaped, it’s like a T but with serifs that are deep. It’s one thing that’s really deep, but two that are medium deep and then a few that are small. I think there’s a variety of people’s depths of talent. That’s why I think arguments to come up a lot, should UX designers know how to code? Most of those dumb arguments are binary arguments. They don’t make a lot of sense. They’re a false dichotomy. If you’re a UX designer who works in an organization that is extremely engineering centric and the only way you’re going to persuade anybody is if you can prototype it, then you probably should be someone who knows how to do some coding.

Scott:
If you’re in an environment that’s very different and very design mature and so many people willing to help you prototype and get, then maybe you don’t. These universal, you can always find because they’re binary. Binary arguments are just dumb, but they’re the most attracted to arguing so draws people in for stupid reasons. But to answer your question, I don’t think that there’s one answer. It depends on your organization. It depends on your team. And it depends on what you’re building. I have very different answers for what you need based on the context, which is the best design answer of all. It has to be about the context. You don’t tell me the context, I really have no basis for claiming it’s always X or always Y.

Larry:
And you reminded me of a whole other conversation about context, but anyhow, we need to wrap up, but hey, one last thing, Scott, how can folks stay in touch? What’s the best place to follow you online?

Scott:
I’m active on Twitter. My handle is Berkun, my last name B-E-R-K-U-N. If you’re interested in the book, there’s a whole website for the book it’s called designmtw.com, Design Makes the World.com and I’m scottberkun.com for everything else I do.

Larry:
Sweet. Well, thanks so much, Scott. I really had fun with the conversation.

Scott:
It was great to finally have this chat, Larry. Thanks for inviting me. Glad we got it done.

Larry:
You bet.