Episode 178 - How Design Makes the World with Scott Berkun

Author Scott Berkun joins the Local Maximum to talk about his new book How Design Makes the World. We cover the relationship between design and engineering, design ethics, failure modes, and organizational behavior.

About Scott Berkun

Scott Berkun is a bestselling author and popular speaker on creativity, leading projects, public speaking, design and many other subjects. He’s the author of eight books, including How Design Makes The World, The Myths of Innovation, Confessions of a Public Speaker, and The Year Without Pants.

See Scott’s bio here.
Twitter

Scott’s Tweet on Organizational Behavior

Related Episodes

Episode 12 with Marissa Chacko on Digital Friends and Enemies

Transcript

Max Sklar: You're listening to The Local Maximum Episode 178. 

Time to expand your perspective. Welcome to The Local Maximum. Now here's your host, Max Sklar. 

Max Sklar: Welcome everyone, you've reached another Local Maximum. Today we are finally going to talk about design, and we're going to talk about the overlaps and comparisons between design and engineering. The book is called How Design Makes the World. My guest today is a best-selling author and speaker but he came from the world of product management, team leadership, and design at Microsoft. He's the author of How Design Makes the World, Scott Berkun.

Scott Berkun, you've reached The Local Maximum. Welcome to the show.

Scott Berkun: Hey, thanks for having me.

Max: Thanks for coming by on this really nice Friday afternoon, Friday morning for you. I hope– The weather's really great out here in New Hampshire. I don't know how it is for you out in the West Coast—

Scott: Spectacular here in Seattle!

Max: I know.

Scott: It's not too sunny. It is a glorious time for the Pacific Northwest. 

Max: Yeah, yeah. Well, I've been– I've got to tell you, I've been trying to do a– I talk about a lot of topics on this show. I talk about machine learning a lot, or AI, I talk about blockchain a lot. I talk about all sorts of things. The name of the show is called The Local Maximum because, well, that's usually a term in machine learning where it's you've reached a point where it can't be improved. You have to step back and make it worse before you make it better again. But when I think about– That is something that applies design, equally as much. I think even people talk about local maximums in design more often, almost than a local maximum. I've been interested in design my whole career, even though I don't do it for a living. It's just part of all of the apps we build as someone in the tech industry. I was, I've been wanting to do a show on it for a long time. I was happy to get your book. Thanks for writing about it, and thanks for agreeing to come on.

Scott: Hey, here we are. Let's go.

Max: Yeah. All right. I tell some people, so a lot of people ask me, “What are you reading, Max?” I tried to explain to them that it's a book about, what kind of design– They asked me, “Well, what kind of design?” I tried to tell them, “Well, I think it's like about the commonality and lessons from all types of design: whether it's like urban design, software design mechanical.” Is that right? 

Scott: Yeah, for sure. I think that's really the spirit of the book. But it's also a way to think more broadly about problem-solving. Design often has a reputation for being superficial. Do you say, “Oh, I'm reading a book on design,” and probably thinking, “Oh, graphic design? Is this like– You're designing? Or you redecorating your apartment? Like what?” “No, no, no, no. I mean, design of things.” “Like watches?” “No, no.” Design is often used as the noun, that it's a thing. That makes people think of it in a superficial way. 

I'm way more interested in design as a verb. If you're using it as a verb, then it means it applies to almost any domain. Someone designed the chair that you're sitting in. Someone designed the public transportation system you use to get to work. Someone designed the laws that determine how fast you can drive on the highway. That design as a verb, that's the interesting thing to me. Of course, that pulls on ideas from graphic design and architecture, and software design, of course. But the universal theme of the book is that everything is designed. We should all be thinking more clearly about what that means for what we want in the world, how we evaluate things we buy. Also, for anyone who makes things, we should learn these fundamental lessons that other designers have learned because we can all apply them if design is truly universal.

Max: Great. Do you see a boundary between design and engineering? What is the difference between those two modes of creation? Or are they more or less the same thing? Or is there overlap?

Scott: I think, so I studied computer science in college. Eventually, yeah, hey, all right. Eventually, I studied design. I remember I studied design in terms of interface design and user interfaces. That was my first formal introduction to it. I remember when I started reading about the processes that designers use and architects use, I was like, “Wait a second.” Even in my basic data structures class in computer science, we were talking about design; we were talking about the design of data structures, and what the trade-offs were between different algorithms that you have all these properties. Anyone who makes anything is doing some kind of design. You are identifying a problem. Then you are trying to use your skills and what resources you have to solve it. That's an act of creation that I think is a kind of design. When an engineer sits down to say, “I'm going to make a new API,” they're thinking about the problem, they’re thinking about who's going to use it, and they're going to go and design it. Engineers use the word design all the time. 

In fact, some definitions of engineers jobs’ are defined by that word: that I'm a missile engineer, I design missiles that will go and take down enemies craft. That verb, again, shows up. I think the distinction, if you're an engineer, that usually means something about how the precision and the quality of the result that you engineered it. It has to work. The bridge can't fall down. It has to mee code. It has to be accessible. It has to be performant. Design usually means more about the, it's more loosely about the front. It's about the ideas more so. Designers, professional designers, are usually more involved earlier in projects. Engineers are always guaranteed for sure to be involved all the way through, and especially at the end when you're making sure the quality level of all these, that level of precision is there.

Max: Yeah. You mentioned in the book that we're involved with design every day no matter who you are. But let's say you're starting on a design project. I realize I want to get into some specific examples later. But I want to see if we can figure out some generalities. Let's say you want to focus on some design project you're starting, what are some good questions to ask when you're beginning that project?

Scott: The book is themed around four questions that are at the heart of why design goes wrong. 

Max: Yeah.

Scott: Any bad product you experience in the world, any frustrating service, they probably failed to answer one of these questions well, and the four questions are really simple. The first question is, what are you trying to improve? That seems obvious. What am I, stupid? I'm trying to make a better web, a better mobile phone, I'm trying to make it better– You improve delivery. But that question means more than that. The question means you have to think really carefully about what you're improving. As a builder, an engineer, it's easy to get lost in the fun of building. You start working on a project with the intent to make taxes easier, let's say tax accounting easier. You start building and you get lost in the algorithms. You get lost in your schedule. You get lost in your budget. You're excited about a certain problem. It's interesting to you as the builder. Little by little, you're forgetting that you're trying to improve something for somebody else. That's the first question. 

The second question is, who are you trying to improve it for? You may design a tool that's fantastic for you, and you love to use it. But everybody's different. They have different needs. They have different requirements. They have different desires and tastes. The fact that something works well for you has no bearing on whether it's actually going to work for your intended customer or not. Who is it for? 

The third question is, how do you ensure you're successful at improving a certain thing for a specific person? That's where all the stuff that user experience work and user research and prototyping, and usability tests, and all the stuff that often comes up in software projects. Those are all methods to help you ensure that you get the result. The problem is, as we know in the world, a lot of stuff that tries to use these methods, they fail and we still have bad stuff in the world. That question number three, a lot of the book talks about why we still fail. 

Then the last question is about the future, It's about asking if you're building something, what are the possible unintended consequences of it? Who might be hurt by your work now or in the future? In the history of invention and innovation, we love to talk about the moments these things were invented. But I can tell you for sure that Benz, and Ford, and all the inventors of cars did not think about gridlock traffic, they did not think about gas emissions, they did not think about all the terrible things we now know about cars. Now you can't have foresight and see into the future. But a responsibility everyone has as a maker is to ask that question and say, how might a criminal use what I make? How might a corrupt government use what I make? Can I design it differently to help reduce those things? Those are the four questions.

Max: Yeah, yeah. Or am I not looking out for the interest of the person using this, maybe? I don't know. A lot of people work in ad tech, for example, it's easy to find downsides for that. I'm not against ads. I'm not against cars. We need all these things, but pretty—

Scott: I'm against cars. That sounds okay. 

Max: Okay, well. We can get into that. That's really interesting. I feel like it's hard to find anything you design that at least doesn't have some downside or some double-edged sword or some other edges to the sword even if it's stuff that's worth building.

Scott: Sure. But I think the goal of that question is to be a responsible creator. We, most creators: engineers, tech founders, we live in this optimistic world that, “I'm trying to do good. I have the skills. I want to solve this problem. It's going to be great.” But that denies the reality of the history of all people like us. All the unintended consequences of the past should tell us that when we're building, we should be aware that’s likely going to be the outcome of what we make as well. Part of our duty then to society is, as we're building it, to have that Doubting Thomas in our mind. How could this be used for evil? How can this be used for purposes that are not my intent? How can I design it to reduce those things? You're right. You can't completely protect yourself against that. But you can say, “My eyes are open. Maybe there's a way I can design this a little bit differently. Or think about these consequences and be smarter about it.”

Max: Yeah, yeah. I'm wondering, do you have a go-to example on that? There are tons of ones maybe with the cars or something else.

Scott: Well, a key one that ties to the design of our economy is planned obsolescence. It has a long history, but a key part of that history is GM. In the 1930s, they realized that their new cars weren't selling as well because people's old cars were still good. They basically invented a campaign to make a new model every year based on styling. They basically created a consumer consumption, that it was about showing status and not about the quality of the goods itself. But that you wanted to show off to your friends and have pride and that you have the latest thing. 

We look at that now and go, “Wow, no wonder our landfills are filled. No wonder that we have this society that throws away things that work perfectly well.” Now we're paying the price as a society for all of that planned obsolescence. We look at that now and say, “Wait, we should build things that last. We want to have things that have value for our children. We want our next generation to inherit things that are good.” It works against some of these notions that have been built into how we think about design and products and society.

Max: Gotcha. I want to ask a question about asking who something is for. There are a lot of times when you don't have a very good answer for that at the start of a project. Let's say it's some kind of software, API, right? Okay, I'm designing something I'm hoping that, I'm getting data to someone, let's say it's Foursquare, where I worked with location data. I'm hoping that other people are going to build something that's really cool off it. But one of the fun things is I don't know what they're gonna build yet. There are tons of projects like this. How do you answer that question? How do you make sure you're not building something that's worthless, but at the same time, how do you allow yourself to build something where I know someone is going to use it for purposes that I can't foresee?

Scott: Sure. This is about– To me, this is about invention. When you're inventing something, there are many different approaches you might take to that. Some people go about inventing things because they identify a problem. They're like, “This thing sucks. Why does this suck much? I'm going to make a better way for us to get around town like the Segway.” I think you might want to ask you about that. One of the classic examples of just bad design because they fail to ask the right questions. But if you're approaching it, that's one approach. You're talking–

Max: The Segway, would you say, Segway is an example of something that's engineered well, but designed poorly?

Scott: Correct. Absolutely. But to give you a better example about invention, one approach I'm suggesting is people have a problem. They've already identified the thing and they're working backwards from the problem. You're talking about induction, where someone has an idea, “I don't know what it's for, but it's cool. I want to try it out. I'm going to build this thing. I don't know who it's for yet. I'm not even sure what it's for.” The history of scientific research is largely about this. They are just discovering new stuff. They don't know what it's for yet. When they discovered the laser, they had no idea it would be used for CDs and DVDs, or barcodes. They had no idea. If you're doing invention, there are plenty of ways you can go, there are plenty of ways you can be more informed about the potential for it, but they all involve talking to people and go into people and say, “Hey, I got this thing, try it out. What do you think you can do?” You learn by actually not just talking to people, but by watching them try to use the thing. The classic example from literature is the Post-It note. The invention of the Post-It note, they accidentally made weak glue– 

Max: They think, yeah–

Scott: They made weak glue by accident. A lot of, I mention stories talking about accidents and say, “Oh, the accident happened. It was amazing.” No, the truth, both these stories are all about an accident and then someone decided to do, to be curious about what it's good for. How can I use this accident? The story that the Post-It note– They invented this weak glue by accident. Then it took them years. Arthur Fry was one of the inventors and he went around for years with this weak glue and tried it out with all different kinds of things. He had samples and prototypes he'd give to different people and say, “Hey, you work in an office. Here's some stuff, see what maybe it's used for.” He did a lot of this customer research with his invention that he didn't himself know what it was good for. 

It took years of collecting data and learning more about its possible uses. Eventually, he found one. It was a musician who wanted to annotate his musical scores. He needed something simple that you could apply to it. That became their first real use case. You have to experiment. But you have to do that with other people. Get out of your lab or out of your software development environment, and go out and give it to people and observe and learn from what they do. It's always an available option, is to learn and experiment.

Max: Gotcha, gotcha. If you have an API, maybe hold a hackathon or something, sort of an idea, I don't know.

Scott: Sure. More specific is, go to a few engineers that you know are creative, and that they'll give you some time to say, “Hey, play around with this. Take 20 minutes and see what you can get this thing to do.”

Max: Yeah.

Scott: Now, you're inviting them in to participate in helping you design and make it better. They'll have ideas you would have never thought of. 

Max: Cool. Cool. What do you think, in terms of the– Let's talk about the Segway for a second because that's a fun one. What do you think they did right? Do you think they could have built something and haven't been successful for what it was? Or do you think, where do you think they went wrong?

Scott: I think the fundamental mistake they made was skipping parts of those questions. The first thing that they did was before, they were not working with an open mind like you're suggesting. They came in and they began a project with a technology that was already a product and the goal of how can we use this for something else. This has limited their sensibilities to be very narrow. They weren't thinking about what problems should be solved, what people were trying to solve a problem for, they were thinking, “We built this thing. We have to reuse it”. That just hamstrings your creative ability. They set about with the technology first. That was their first mistake. 

The second mistake was they made a lot of assumptions about people. They decided that their ambition was to revolutionize personal transportation, a device that everyone would have that could get them almost anywhere quickly and easily and safely. Great ambition like a founde speech from a startup founder, great. The problem was they didn't go talk to anybody currently alive in the world and say, “Hey, what are your personal transportation needs right now? How do you solve them? What frustrates you about getting to the shop, or getting to work?” They didn't do it. They skipped it. 

That means if they had done it, they would have learned something very simple and obvious to us now, which is people use bicycles for this. Bicycles are cheap; they're affordable. Everyone knows how to use them. They're easy to get around. You don't have to plug them in. You don't need expensive batteries for them. They did not avail themselves of what the alternatives were to the thing that we're designing and try to learn from that. That would have probably forced them to realize the technology they were using might not be the best one for revolutionizing personal transportation. But they were already so preconditioned to assume that their technology had to be the right answer that it set them on the path that they ended up on.

Max: Right, right. I wonder– Segways are still used in some places. I wonder if they had a different, if they just found a different problem to solve, then maybe it would have been better. I don't—

Scott: Yeah. This also gets back to hubris in invention and design. That what you're seeing is a far more reasonable approach to invention, just like I suggested before. Had they gone and made 10 of them and found 10 people they thought was representative of the potential audience, and gave them a Segway for a month, and studied them, and observe what they do with it, what don't they do. Then they built that one, “Oh, we've learned now. Let's refine it. Let's understand the reality.” No, instead, they had this grand proclamation, which we're fond of doing as inventors, “I'm going to revolutionize everything,” and they presumed—

Max: Like in 10 years, everyone's gonna be flying around on my plane.

Scott: Right? 

Max: It's important work, right?

Scott: Or Quibi was a good one last year, “We're gonna revolutionize how people consume media because why? Well, because we want to.” It's not– 

Max: I don't know that one, Quibi?

Scott: Yeah, it was a major media. They were trying to do short-form videos and stuff. You had a billion dollars of investment money to make a new social media platform that never really had a clearly identified audience or problem to solve. 

Max: Okay. 

Scott: It's a similar story to Segway, in that you had a bunch of high-powered people who were all impressed with the ambition, who gave it a lot of hype, but they never really satisfied anyone along the way in developing the idea. They were set up to fail by that lack of following those questions, and being sincere about asking, “What what are we not seeing? What's a better way? Who is it really we’re designing for? Let's study them. Is this really the right approach?” They skipped all those things.

Max: Yeah. I want to ask, again, well, I want to circle back. Let's wait till the end to circle back on examples of great design because I would, that'd be a good thing to end on. But poor design is also fun. Let's follow up on something. Because there's a lot of people who accuse a product of being poorly designed. There are certain failure modes, one that we just mentioned, are answering those four questions, sometimes, those are not answered. 

Another one that I think I get into the book is, sometimes, the economics and the politics. The politics, I don't mean like the political elections, the internal politics of the company, or whatever organization is designing this thing. Or whether it's a city or whatever, I think the city is a good example. What are some things that happen there? What are some signs where you could tell like, “This was designed by a committee that did not have a singular focus?”

Scott: Sure. A lot of my career in the tech world, I was a project manager. I led project teams.

Max: Yeah. That's like pulling together all the I mean, herding cats is the–

Scott: Right, right. I have a lot of personal experience with understanding why projects go wrong. It's usually not the reasons that people who have creative talents or engineering talents think. We tend to, we want to label it, whenever we see something that's bad, or have a bad experience, or even software that's just low quality that crashes all the time, or hard to work with, we want to blame it on incompetence. “This engineer must have been an idiot. How could he have designed this API this way?” Or we tend to label it on skill. That's really not the way that people work together, teams or organizations. 

Teams and organizations depend on each other to make decisions, to have shared goals, to communicate well so that they're all working on the right thing at the right time. All those things are really hard to do. That's the main reason why projects fail. It's not because people aren't talented. That can be your problem but that's usually not the problem. It's the way that they're organized and directed, and led, how much trust in their culture they have. Those are the real problems. Those are the real problems for the design of everything. 

In the book, I talk about how a common example of this is, like a website for an organization, it could be your university, it could be your corporation, that you know when you go to that website, “This is bad.” It represents not the things most people need when they go there. We wonder why is it divided up this way? Why are these five main pages on this thing? They must have been stupid? No, it's because the leaders of each of those departments in the company wanted their thing to be visible on the homepage. They felt like, “Well, my department’s just as important as Sally's department. Shouldn't I have as big an icon on the main–?” That's really what it comes down to. Can these people get along? 

If the leaders of each group in an organization don't get along, then they're not going to get along and deciding what a good design is. One of the examples in the book is the city of Missoula, Montana, which has the core of the city rotated. The city grid is rotated 45 degrees, the core downtown area from the rest of the city, which means there's five-way intersections and six-way intersections, and people look at that and go, “What kind of stupid urban planner was this that did it?” The truth is there were two different landowners and they didn't agree. The city got designed in a messed up way. That's usually when you face a bad product or bad service, that's part of what's going on is the organization is just not healthy. It's not capable of doing quality work.

Max: Yeah, that example also reminded me of Manhattan in the West Village where the streets go in the opposite direction. That's very confusing to new people who move in, but I don't know if it's that, it doesn't– The neighborhood's very nice. It doesn't really make it that bad, but very tough to drive in.

Scott: The transition, though, south of Houston, right?

Max: Oh, that too. Yeah. 

Scott: It's weird for people who don't live there. That's kind of bad design. That's why. It's not the person who did it was stupid, it's that the people in power didn't get along. We have those ripples.

Max: Yeah. I found a Tweet by you that I really liked. It says– Actually, it looks like this is a tweetstorm so I'm not gonna get into the full length of tweets. But, I've never been good doing tweets. I tweet every once in a while, but I wish I could be better at being like you. “Here's a full list of–” Anyway, “the fallacy of the seat–” I'm going to start here. “The fallacy of the seat at the table is often decisions are made before the table meets. I know this because much of my career was controlling tables. The more people at a table, the more real action goes elsewhere.” That comes out in design you're talking about, something more broad than just design, more organizational, but what– How does that happen? Tell me like what– How do you see? What are some good questions to ask for someone who finds themselves in an organization observing this stuff going on?

Scott: The basic idea is that we, especially if you're trained as an engineer, or designer, or technical, you’re trained in something technical, you have a–we have a very– You're trained to– You probably haven't already, a very rational view of behavior. That's why people become programmers; they like the rationality of the machine. If you can figure out the right thing to say, it will do exactly what you want. That's amazing, but that's not the way people work. People are emotional. We're irrational. There's good things about that and bad things. But we are not– We don't work that way. People look at the way decisions are made in organizations, and we want to be rational, want to be logical, but it's just not the way it is. 

The seat at the table thing is simple. When you get into a room to meet people, when you get we have a meeting, you're trying to decide something. There's a lot of subtext of what's going on: who's getting along with who, who had an idea that they've already run by a few people so when they bring it up, people are nodding their heads already because they have already heard it. Having a seat at the table means you're privy to what's going on. There's a whole social network of interactions that's really driving what's happening. If you're not paying attention to that, you're going to be confused and baffled by the results. In simple terms–and this is logical in a way–if me and you are having a meeting to decide where we're going to get dinner, there's just two of us here. I don't have to worry about anyone else's opinion other than back and forth. 

Max: Exactly.

Scott: Yeah, right. But if there’s a third person, now anything I say to you, I'm saying in front of them. I'm going to, maybe, say things a little bit differently. I might argue with you or debate with you in a different way. Now as there’s a fourth person, now there’s a fifth person, now there's a person who reports to me, now there’s a person who's my boss; all these add layers to what people will say and won't say, or how they'll say that has these compounding effects on what goes on. That means the bigger the meeting you're in, the more the intimate real debates probably go to places you don't see. To private chats, to hallway informal conversations. 

That's really where a lot of the influencing and decision-making is happening. That’s what that thread was about. This to me is germane to design as a verb. It’s not just about user experience design. If you're working on the machine learning team, and you're gonna decide which samples to use, that’s an important discussion, right? If you’re on a meeting and there’s 12 people there, I'm telling you, there have already been discussions about this. They've already been talking about it because it's so important to them; they want an inside track on understanding how it's going to go, and an inside track of getting what they think is the best answer to be the right one.

Max: Yeah, yeah. I think that's true. Also, it's like there's the process of gathering feedback and gathering information and when you're designing something, I think, it's, as you say, good to talk to as many people as possible. But when you're internally, like, “I often want to be as open as possible and get as many people, as many inputs as possible.” But at some point, it gets overwhelming. You have to whittle it down to a smaller group to say, “Okay, this is what we're going to do.” Sometimes people feel like they are– It's inevitable that people, sometimes, feel like they haven't been consulted. It's the whole thing of not being able to please everyone.

Scott: Yeah, yep. That's true. That is a mathematical reality about the nature of decisions and relationships. That's part of what makes managing a leading team so complicated, is balancing those things.

Max: Yeah. We talked about some failure modes for design. But I want to ask you and I want to end strong, what are some things that you found where you're like, “Wow, this is really well designed, or this really replaced something that was really bad with something that works really well.” How can you tell when things are going right?

Scott: Yeah. Well, the ironic thing about good design is that when it's done well, you don't think about it. That's part of the challenge of this book and why I wrote it, and the challenge that people who are good designers face. Good engineers face this to a degree, too, that when you make something work really, really well, it just becomes invisible. 

Max: Yeah. 

Scott: People only notice what you do when it fails. You're a site reliability engineer, right? You have to keep the website up. You're doing your job, and people don't even think you have a job until it crashes like, “What– Why is it down?” You're like, you have no idea. I think this is a universal truth. It is true for design, too. When something's really intuitive and works really well, you're not thinking that someone had to think about it. It just seems so natural. 

I have two examples from my life for this question. One is a funny one, which is I live in the Northwest. I have a bunch of wood in my yard. Splitting wood is a very therapeutic, stress-relieving thing to do. I have an ax I bought during the pandemic, it's a Fiskars ax. I love it for this example because it fits so well in my hands. It's so it's heavy, but it's balanced in a way that just feels really natural. It makes you feel really powerful when you use it because when you swing it, it's built to amplify your strengths you feel kind of superhuman. It never crashes, has infinite battery life. It’ll probably last me for like a decade. It's a great product. It solves my problem. It doesn't create any new ones at all. 

A lot of products we buy initially solve a problem, but they start to create new ones. Battery life and those kinds of things are these consequences we’ve come to accept about technology. But it really is, we create problems by the things, some of these technological things. My other example is more practical, is there's a tool called Calendly, which is this online calendar tool. I switched to using it over during the pandemic. It's so good because think of any time you have an– You wanted someone on your podcast and you email him, “Can you do this then? Email back, what about this day?”

Max: Yeah, I've used it. I've used it for people getting on someone else's calendar. 

Scott: Yeah, yeah. Which is this thing? It seems so trivial, but yet you do it all the time, especially with strangers because they don't have access to your calendar. For someone like me, who's an author and a speaker, I meet a lot of people online I have to meet with, really. The tool just has anticipated all the cases for this, all the corner cases. I can set it up so my schedule is available for certain people and this way, for other people in that way. Every time I've learned the tool, I'm like, “Oh, I really need to do this option. It's already in there.” I've been so satisfied with the functionality and, also the simplicity of it, that it is by far the best, modern, recent example of a technological piece of software that has been that high for me.

Max: Yeah, yeah, yeah, I definitely– I use it myself, sometimes, but I have– It's way better to get on other people's calendars versus trying to email back and forth with authors like yourself, or CEOs or whatever. Yeah, I'm going to take up like five emails with them try to come up with a time.

Scott: Yeah. It just seems so dumb, now. Here's the link. Here's what I'm available. You click a button, it'll do it automatically and send you a link to it. It's like, “Wow.”

Max: Yeah, yeah. Alright, so the book is called How Design Makes The World with Scott Berkun. I would encourage anyone who is really compelled by the examples we're talking about today. Once more, definitely get a copy of this book. Scott, before we go, do you have any last thoughts about our discussion today? Where else can people find more about you and–

Scott: I’m easy to find. My website’s my name, www.scottberkun.com. You can get free chapters from the book there. There's a short fun video we made about bad design examples about the book. Y’all know I'm on Twitter at my last name, @berkun, B-e-r-k-u-n.

Max: Yeah, I love how the book is itself designed. I think we talked about this. Sometimes, I read through books, mostly for the podcast now. Sometimes, it's like, “Oh my god, I have a 30-page chapter.” I just really love this one because the chapters all have a main point. They're all five pages. I can sit down and read it, sometimes, between tasks. Each one gives me something to think about, so I really appreciate that. 

Scott: Thanks. 

Max: So, all right, Scott Berkun, thanks for coming on the show. 

Scott: Hey, thanks. Bye.

Max: Alright, I particularly encourage you to pay attention in your projects, to those questions about: who might be harmed by what you're building? What are some of the potential unintended consequences? What if what you're building is being used by a malicious actor? I just highly encourage people to ask that question. I know I gave Scott some pushback, but it's really important, just because we need to figure out what the boundary of that question is. Not everyone is going to agree, but I think if everyone asked that question, we would live in a better world. If people at a company or on a team are asking that question, it's a good sign. If not, I just think it means that their designers and engineers are jaded and overworked. It's not a good sign in the long run. 

If you're in the mood to go through my archive, Local Maximum archive, I'd point you to Episode 12, in which I talked to former Foursquare Product Manager Marissa Chacko about the difference between building products that look out for users and building products that don't. But beyond that, the book, which I have here has a lot of really great examples. For example, in the USB-C cables that you have, you can plug it in. Actually, this is a USB-C cable right here. You can plug it in in both directions, I could have plugged it in this way, this way. But for the old ones, you couldn't do that. Why didn't they just design that way to begin with? Why is that? Learn about it in here. There's also one chapter from a guy who designed the master plan for an airport so some great stuff in this book, How Design Makes The World. The show notes page are at www.localmaxradio.com/episode/178. Have a great week everyone. 

That's the show. To support The Local Maximum, sign up for exclusive content and our online community at www.maximum.locals.com. The Local Maximum is available wherever podcasts are found. If you want to keep up, remember to subscribe on your podcast app. Also, check out the website with show notes and additional materials at localmaxradio.com. If you want to contact me, the host, send an email to localmaxradio@gmail.com. Have a great week.