Transcript

Paul Ford I mean if you—if you check out my Github account, you’re gonna find out that I have a pretty serious integrity problem. 

Gina Tripani [Laughing] I mean: same [laughs]. 

PF Oh man, I have 20 years of integrity problems [Gina laughing] as an engineer that . . . we’re gonna have to work through [music plays alone for 18 seconds, ramps down]. Gina, you and I are pretty nerdy, yes? 

GT Absolutely. 

PF Do you know what? I love a good, well made app. I love a well, good-made [sic] anything, frankly. 

GT Yeah, anything that someone has thought about. 

PF What’s the best designed thing that you own? 

GT Agh! That’s a—[music fades out] that’s a tough question. 

PF It’s a brute, isn’t it? 

GT Wooo. I’m lookin’ at my desk. 

PF I mean I’ll give you an easy out. Your, you know, your Macbook is pretty well designed. 

GT My Macbook is pretty well designed but I also appreciate just a really good fork, or chair, honestly. 

PF Yeah. I’ve got these heavy Ikea forks, you pick you and you’re like, “Alright, thanks, Sweden. You did good.” [Gina laughs] Yeah. 

GT I’m excited because—

PF Anyway! That’s our podcast for today! [Gina laughs] No, look: but you and I aren’t the experts here. That’s why we have a guest, dammit. 

GT We do. This is someone I’ve been friends with for a very long time and I’ve been reading his books for, like, ten years. I’ve learned so much from him and I’m so excited to get to talk to him today on the show: Scott Berkun. Hey, Scott.

PF Scoooottt!

Scott Berkun Hellooo! It’s so good to be here. 

[1:29]

PF Welcome. We’re glad you’re here. 

SB Thank you. 

PF So, Scott, design! 

SB Design!! That’s it. That’s all it says in the book [Paul chuckling] It’s one character per page, it’s a short book. It’s all you need to know. 

GT Scott has a new book coming out this month—And actually Scott has written, I mean, one of the things I admire about you is that you’re so prolific and you’ve written books on so many subjects—

PF Yeah, I mean, let’s—let’s—Before we even get to the book, like, give us a little context: you are a writer about design and technology. What is your bio? Your potted bio that you would usually throw out there? 

SB The bi—Most of the books are vaguely business culture related. Design is, for me, I don’t know that my readers notice it but I think of design as central to do everything. That a book is a design thing; a presentation is a design thing; obviously any piece of software or a phone or a spoon or a fork is a design thing, and that’s always just been the central theme at how I look at anything that’s done well or not well. And I’ve written eight books, including this one. The first seven have nothing in the title about design, the only thing about design is really implied, and I always wanted to write a book that could teach anybody how to think and look at the world more like our best designers do. So that’s the goal of the book: that anyone could pick it up and start to appreciate things in their life more, or understand why the things that frustrate them: what is about the design and how they were made that bothers them. So they could be more informed users of things and hopefully also better makers of things. 

GT So the audience is kind of non-designers. People who don’t have design thinking currently, is that true? 

SB Yeah, well it’s both, so . . . there’s a little trickery goin’ on here—

PF Well, and let’s make sure we get that title out there, right? What is this book? 

SB How Design Makes the World.  

PF That’s right. We’ll say that five to seven more times throughout this podcast cuz that’s how we support our—

GT A link in the show notes.

PF You’re givin’ us our time! [Gina laughs] That’s right. If you don’t buy How Design Makes the World, you are a—an animal. That’s what I’m saying. Alright, so who is this for? Who is this book for? 

[3:34]

SB Well, there’s two kinds of people I was thinking about for this book. So, one, is everyone. Which is a terrible thing to say if you’re making a product cuz you can’t just design for everyone, but part of what I wanted to do was solve the problem of the best designed things that we use . . . we don’t think about. Cuz they work really well. So most people don’t think about their light switch. They don’t think about their faucet in their kitchen. They don’t think about how much engineering and design went on to make that little thing work. 

PF Mm hmm. 

SB Now, you mentioned when we were joking around, you mentioned a nice fork from Ikea. We use silverware every day. Someone had to design that. You pick up a coffee mug and it feels good in your hand, and you don’t even notice the grip cuz it feels so good. Someone designed that. So really good design usually goes unnoticed. And that’s a problem for thinking about good design. We don’t notice it, we just take it for granted. So I wanted to write a book that helps people understand and look at things in a more curious way. How could someone craft a cup or a spoon or a fork or a piece of software—how do they do that? And then when we use things that are frustrating, what did they get wrong? What mistake did they make? What does a consumer usually look for when I buy a thing? Usually when you buy it, you don’t really know its design qualities. So, one audience is really just everyone. Consistent designs affect us all the time. 

PF But you know, I mean, let’s talk about some things that are beautifully designed. Like, an example that just popped into my head cuz I had a blood draw the other day, is that thing that they stick you and then they’re able to like fill five test tubes with your blood . . . without having to stick you again, that continuous little firehose that comes out of your blood. And I’m like, “That is amazing, actually, cuz that beats the hell out of having a needle go in your body five times, right?” And so what are some other things that when you say ‘good design’—when it’s like, Scott! You’re the design expert. What are some things that really stick out in your head? 

SB Well, one related to yours: there’s all this mechanical operational things that are in our everyday life that we don’t think about and one that I think about often is how when you go to your sink, you go to your faucet, there’s just one knob that controls both the temperature and the volume. If ever you stay at like an old—back when we could travel—if ever you stayed at like an old bed and breakfast [mmm] or you ever lived in an apartment that had an old style: you have a hot knob and a cold knob and if it comes like—you’re doing construction work now with a bulldozer and it’s all these—with that one device, the combination of those things seems so obvious and simple but it’s really not. There’s a bunch of work that went on to think it through that you could operate something with just one way. I think of things like paper clips. Or I think of—we were talking before about how you like your Macbook. I don’t think about my keyboard very much. A lot of writers complain about their keyboards all the time. I use a generic, Mac Smart keyboard and I never think about it, it works just right for me. 

[6:23]

PF Yeah, I mean, you know, it’s—it’s everybody gets real finicky when they’re procrastinating and then somehow it turns out when the deadline’s there that your keyboard wasn’t your problem all along. 

SB Never the problem. It’s always between the ears but no one wants to complain about that. 

PF No, no—

SB It’s much easier to blame somebody else. 

PF I would—I’ll say it: I wish, very frankly, that I was better designed [Gina laughs]. I would love that. Like, there’s about 70 improvements that—I would completely submit my body to Apple right now [Gina laughs]. Especially as I’m in my mid-forties. “Absolutely, go to town, take me to—” 

SB If Apple designed you, you’d need to be completely re-bought and refurbished every four or five years [chuckles]—

GT It’s true. We’d need to buy so many adapters for you, Paul. We’d be like, “Oh, Paul’s chair doesn’t work anymore. We need that—the new adapter.” [Laughs]

PF Oh that is true. Every day, you’d—I’d be like, “God, I miss MagSafe.” [Gina laughs] Just like—

GT “Firewire, that’s so good.” 

PF Firewire, no. No, USB th—well, except for all the ports being the same. Look [Gina laughs], alright, look: actually, if we can spend some time—Let’s talk a little more about the book but then let’s talk about USB ports for [chuckles] a couple—like at least for a couple of hours, right? Cuz I have a lot of thoughts and feelings. 

SB The USB port is actually—There’s a good story behind that. That’s a common example people use of really bad design. That you get 50/50 odds when you wanna connect something. It’s 50/50. I mean, there’s little tricks you can try but for most people it’s 50/50 and somehow it always seems like even though it’s 50/50, it takes four or five tries. No one’s ever quite figured out why that is. 

PF Right. 

[7:52]

SB But the story behind that was this is in the PC era, when there were like 12 different kinds of adapters: serial, parallel—all that crap. And they were trying to get a coalition of companies to agree on one standard. They had a design that was more like the USB-C, that was reversible, but it cost a lot more to make. They didn’t think they could get IBM and Xerox and Compaq and all those companies to agree on this expensive alternative. 

PF I mean back then you couldn’t, too. You couldn’t get those orgs to agree. They wouldn’t work together. 

SB Oh, they did agree on the USB standard, that was the achievement but the trade off was you got a cheaper choice but it did get rid of 12 things. We don’t remember that anymore but back at the time, even though it was this solution we complain about now, it was an improvement. And that story’s in the book to talk about trade offs, that when we complain about a design, “Oh this is terrible.” “Well, would you pay ten bucks more for a better version? Cuz you didn’t. You bought something that doesn’t work as well.” So there’s a trade off that you make as a purchaser of what you’re gonna prioritize or not. And trade offs are inherent in design. They’re also inherent in engineering. I think engineering and design overlap so much in many ways. But understanding that trade offs are inherent to design . . . gives you a different lens to think about things that you use but also when you’re making stuff, the clearer you are about the trade offs you’re making, probably sets you on a better path to design something that’s higher quality. 

PF You talked about design, you talked about engineering. Like, where do they begin and end, in your head? 

SB I think that any time you have an idea for something and you try to make it real in the world, you’re doing some amount of designing and engineering. Designing is probably more focused on the [sic] figuring out how it should be and the engineering is figuring out how to actually build that thing in a way that has reliability and quality in it but there’s a huge part where you’re doing some of both. And so I was a computer science student, and we learned to write code and do algorithms, they never mentioned the word ‘design’ and I think that was terrible. I think that had we applied any basic amount of design practice, of thinking about alternatives, thinking about goals, thinking about prototyping—that would’ve been helpful as an engineer cuz when you write an API, you’re doing both design and engineering. You’re creating a thing someone else is gonna have to use and you’re trying to guess at what’s gonna be easy for them to do. So to me, an API is this weird combination of design, engineering, and interface design, even though it’s purely code which shouldn’t really have an interface, right? The easy answer is my first one though: they overlap in the middle. Design’s usually about figuring out what it should be, and engineering is how do you build this so no one dies when they use it? 

[10:32]

GT I was gonna say there’s this validation and feasibility conversation that ideally is happening, right? Like, design is, “Well, this is what this should be.” Engineering’s like, “This is what this can be.” And hopefully those things kinda meet in the middle. I mean, it’s interesting when you said like, “You didn’t pay the extra ten bucks for higher quality.” It’s tough to convince CEOs and consumers to pay for the thing that disappears when it’s not a problem [chuckles], right? 

PF I mean that’s the thing: like, Scott, you’re whistling the Postlight tune right now. 

GT Yeah, yeah—[laughs].

PF Like, “Oh, design and engin—” Like, it is true. You’re like, “The importance of design and the person buying on the other side is like: you’re talking about teapots, man. I’m gonna need the—” 

GT I—I [stammers] Actually, when we talk about API—when Scott was talking about APIs, I wanna go down the rabbithole of like, “Well, there are users for code, they’re developers.” But now you’re getting into like, developer experience, and, you know, the front end developer is using the API at the back end developer. So there is an interface, right? And there should be documentation and it should be obvious and easy and this is something I’m deep in right now, one of our—one of our projects, so—But there’s a user—you’re solving—You’re solving a problem for someone, right? When you’re designing something. Or ideally you are. 

SB Yeah! I think that people who make APIs should do usability studies on them. There’s no reason that they can’t. They don’t [that’s true] think of it with the same toolkit that interface designers do but it is an interface! I mean Application Pr—What is it? The last ‘I’ is for Interface? Right? 

GT Correct [laughs]. 

SB So [chuckling] Interface design: you should learn from what interface designers do and it’s fascinating to me how much the tech community is involved in interface design and design work . . . that don’t think of design as something that they do. And that’s part of what I’m trying to solve with the book is that anyone who makes stuff, you’re designing it. There’s design involved. And what you wanna draw the line between engineer and design: I don’t care. You’re doing—you’re trying to do quality work that solves a problem. And the more informed you are about how other people in the past have solved problems well, the better job you’re gonna do. And design is one way to frame—one lens on how you make things well. 

[12:26]

GT Yeah, I mean, this is what I really like about the book is that you can use it as a tool to convince your boss or the marketing team or the engineering team for investing a bit more time in the thing that’s invisible, right? In saying, like, “What problems are we solving? Let’s be—” You know, you talk a little bit about being customer-centric and how a lot of companies say that, right? But what does that really mean? And it means asking about what people need and what they want and what they need from your product. And I think it can be sometimes really hard to get through—You know, “We’re gonna build this and ship this fast, right?” But it’s like, “Well, but what about the part where we put the time into design?” I think that’s tough to sell sometimes. To pitch upwards into a team. 

SB Yeah, it is, and so I tell designers, and it’s one of the early parts of the book, is that design is just—it’s a kind of quality. I mean engineering you could argue is a quality too. That’s fine, I don’t have any argument there. It’s a kind of quality. And once you start talking about quality, now you have—people have stakes in that. So one might say, “Oh, is my thing design?” Well, I don’t know. If you say, “Is the thing you’re making high quality or not?” Everyone gets really defensive. “Of course what I make is high quality!” And then you say, “Well, quality for who? How do you know this is actually solving this problem for people?” So ‘easy to use’ is this phrase that gets thrown around all the time, ‘intuitive’—it turns out that that’s mostly just marketing language. There are ways to measure ease of use. You have to observe people using the thing and see how long it takes them to actually complete tasks. How many mistakes they make. How many errors they make along the way. You can measure. It’s not that hard. But very people who say, “We’re making an easy to use product; we’re making an easy to use API,” actually do any of due diligence to justify that word. I think that’s a problem. 

PF Who’s ever gonna admit they’re a hack, right? Like, that is a moment of tremendous empowerment for yourself, I found, when you just finally go like, “No, sometimes I’m kind of a hack. I just kind of got it done and I didn’t really deal with any of the consequences . . . cuz there was a deadline!” You know, right? Like and I think you’re right! If you tell anyone that they’re doing anything less than the most extraordinary, high quality work, they’re like, “Go to hell.” No, I mean, if we were seeing great design work, you’d see a lot of APIs that weren’t complete garbage. And yet . . . when you go out and try to like, you know, authenticate against some public API you realize like, “They never thought about the user. Not once!” 

SB Well, I mean, I remember from my coding days, it’s hard enough to make the thing work at all, right? 

PF Right [Gina laughs]. 

SB And then you’re figuring out how to—what operators, what attributes, ok. It’s all for you. It’s your head. You know? It’s like writing, in a way, that a lot of writers write stuff that makes sense to them . . . but no one [chuckles]—it doesn’t make any sense to anybody else. So, whenever you’re creating something, part of the loop of what you’re making has to be . . . to observe people trying to use it and then learning from that. If you do that, you’re never gonna make anything terrible. You might not make something amazing, but the only reason you have an API that’s that—so obtuse and obscure . . . it’s just nobody else other than the maker was involved in the process of figuring out what quality meant, or what ease of use meant. 

[15:27]

PF That requires a kind of empathy and also one of the things I find to be a real struggle too—And this something I’ve learned over and over. I’m sure you’ve—Gina’s learned it as a public communicator, you’ve obviously learned it as a writer: explaining things requires a level of simplification that people usually find almost obscene. Right? Like, doing good design and thinking through how people actually are gonna perceive, requires you to get almost dumb, and to have a kind of empathy for how complicated things are. And I see it as particularly with engineering and sort of digital driven cultures cuz they just assume that, like, “Well, you know, if they don’t get it, they’re idiots.” . . . You know? And I feel that like, when you’re in this zone where it’s—You know, an API is a great example of something where there is a relatively high baseline and understanding for someone to just know what it is and how to use it. And then people just go all the way, they’re just like, “Ah, they’ll figure it out. To hell with it. Like, they’re me. I’m smart, and I got it. So they can get it.” Which is a nightmare. And it’s why we have so much friction in this world. 

GT I think it’s the difference between I’m solving a problem that I have which is that I have to get this thing done, versus my job is to solve problems that you have. Like, I’m giving you something for you to succeed. And I think that’s the empathy that we’re talking about. I mean, what’s tough is when your customer, or your user, or the person who is gonna use the thing that you’re designing, like have different problems, care about different things. 

SB The word ‘empathy’ is such a—It’s not a bad word but it means this very like, “Oh, there’s an emotional component.” And that’s fine. I cut to core on this: it’s about integrity. If you’re building a thing for somebody else, and you don’t involve them in any way until it’s done and then you don’t even listen to their feedback, you’re a low-integrity maker. 

GT Wow, our design team’s gonna love this episode. I’m so excited! 

SB You’re pretending to make something for someone else and it’s sort of like buying someone an item of clothing that’s 20 sizes too big or too small or like you love rum but they hate rum. And you go, “Happy birthday. Here’s some—” You’re acting out of low-integrity. 

GT Right, you’re giving a vegan a steak [laughs].

SB You’re in denial about what you’re really doing. There is a place for people who really just wanna make stuff that they like, that’s totally fine. That’s artistry. That’s called—

PF Mmm. 

[17:42]

SB You’re an artist. You’re making a thing. And that could be an engineer—the engineering side of that. You’re making a tool but really you only care that it solves the problem in a way that you care about, that’s fine. And you can put that out in the world and say, “You know what? If you like, great. If you don’t, fine.” But if you market a product that says it solves a problem for you, but really you built it for yourself, that, to me again, you have an integrity problem. The mismatch between what you did, and what you’re saying you did, and no one—no one really ends up being happy with that. 

PF Look, there’s an important part of this book that we should talk through which is—and, you know, as I work through it it is the four big questions, right? Like, there are—You have a lot of practical guidance and a lot of ways to see the world. And it’s the four things that you should ask about design, and I’m just gonna—are you ready for me to sort of like—you know, I’m gonna steal some thunder. Well, one page of thunder, if that’s cool with you, and read them out. 

SB Go for it, yeah. 

PF Here they are, Gina, you ready? 

GT Ready. 

PF K, get your integrity aligned here [chuckles, Gina laughs]: What are you trying to improve? That’s number one. Two: what are you trying to improve it for? Question mark. Number two. And number three: how do you ensure you are successful? And four: who might be hurt by your work now and in the future? So, you know, you’ve got a big book and you’ve got the four most important questions. How’d you get there and why those four? 

SB The first draft of the book, I’m not sure it had any of those questions in it, maybe it had the first two and the form of the question was what I had learned as a—in school and as a project manager, and that problem was always—The way we always framed the question was what problem are you trying to solve? Because in so many meetings where you have smart people: engineers; designers; managers; but you have all these ideas, you’re brainstorming, and it gets really fun. And then the idea goes into all these interesting places intellectually to you. And my job as a project manager and a team manager, I’d be in these meetings and someone was just like, “Wait a second, this is fun. What are we solving here? Like, what does this actually do? It does something that’s interesting to build cuz creatively and intellectually it’s interesting but are we solving a problem for anybody here?” And that would usually bring the conversation back to the real world: we have a customer base, we have a bunch of goals, let’s bring it back. And so a more positive way to frame that—I’m a New Yorker, I tend to frame things in a cynical, skeptical way, better than what problem to solve, I was coached into framing it as: what do you wanna improve? It’s a more positive way to frame it. So that’s where that first question came from. So the second question is you have to pick and study and think hard about who you actually are building this thing for but also, the non-goal: who are you saying, “We’re deliberately not building it for them.” And if you don’t do that, you end up with something that tends to be mostly about you cuz you’re the only user that you naturally intuit everything you try out. “Oh! That works fine!” If you don’t specify that, you have no idea if you’re actually making something that will solve anyone’s problem. So those are the two that come first in teaching anyone about how to make something good. Whether you’re an engineer, a designer, you’re a chef, those are the first two: what are you trying to improve and who are you trying to improve it for? And every good business, every good book, every good apartment complex, they all had some amount of that thinking, they were clear about: “What are we improving and who are improving it for and who are we not thinking about that never are gonna be our customer, let’s make sure we don’t fall into the trap of building stuff for them cuz that’s not who we’re aiming for.”

[21:01]

PF It’s a hard struggle. 

GT It is. 

PF We do it all the time because we market the services of the firm and we’re always trying to figure out who to communicate with because we need to speak very broadly to, you know, to ranges of people who, you know, most people will find this interesting but also who people who will wanna buy services, right? And it’s so easy not to. It’s so easy to just kind of dwell on what’s interesting [mm hmm] in the moment and not think bigger picture. And it’s a continual, endless fight. And we don’t think of it—we think of it almost as a marketing challenge but listening to you talk, it’s like, well, that’s actually a design problem around how we communicate as a firm and how we talk about this podcast and all the other things that we do. And the way we do our case studies, like are we always making sure we’re hitting that group? And it’s easy to slip. That’s the easiest thing to let go. So I’m not surprised that you would anchor that, you’d anchor your design strategy with those. I have a big question: what comes to your mind when I say the words ‘design thinking’? 

SB [Sharply exhales air] Well, I have mixed feelings about that. I think anyone who has a design background has mixed feelings about that one. On the one hand, the positive hand: design is basically an unknown thing to most of the professional world and most of the real world, the wider, general audience world. So, it’s the first example of a positive thing that’s not assumed to be about fashion or handbags or interior design which is what most people think of when you say ‘design’. It’s this term that’s about problem solving, it’s something positive. So I think in terms of marketing the whole idea that designers actually have skills and a skillset that’s useful, I think it’s great. 

PF Whoof! We gotta be careful there. They’re gonna start asking for things. But ok. Ok. I got it. 

[22:39]

SB On the other hand, it is a trivialization of what makes design hard. You now have this simple playbook, it’s a step-by-step thing. It’s a process. And it implies that just by knowing that process, you will now be a good designer. And as you just pointed out, Paul, it’s a constant struggle. A lot of the things that make design difficult, it’s this balancing act. It’s very easy to get out of balance. And knowing that process does not give you the benefit that—the necessary benefit of the experience of having designed many things . . . and learning these nuances and these little corner cases to be actually a good designer of something. And a lot of people have taken a certificate course in design thinking and now they think they’re as qualified to design something that someone who’s been a product designer for ten years. That trivialization is real. But, on the whole, I think the benefits of it have been better than the negatives. 

PF You know, in tech that’s like Agile, right? Where it’s like—it’s a reasonable technology to keep—a reasonable approach to keep you from never shipping software. And software sure as hell doesn’t wanna ship. Like there need to be ways that you can approach that specific challenge, but the minute it becomes the sort of Agile religion and people start lecturing you on scrum versus kanban or whatever, it’s just diminishing returns, and it can be one of the most exhausting—You know, I’ve seen it in so many conversations where people just sort of argue as to how the process is more important than doing the work and I, you know, my brain starts to leak out of my ears when I hear those conversations. 

SB Yeah, it’s the—I agree. It’s a similar trap. I have the same fear of—not fear but distaste for process centricity. The magic is never in the steps. The steps help you learn and give you a framework. Whatever project’s different, every team is different, and I have a little hesitation when there’s an Agile scrum master, whoever, who’s a master of the process. But hasn’t really shipped that much themselves or designed that much themselves, they’re a master of the process [mmm] but what is the pro—it’s sort of like a writing expert . . . who hasn’t published a book or [Gina laughs] or like they’re an expert and they actually may give good advice but I wouldn’t look at them the same way as someone who’s actually done it and can speak from the experience of doing it. 

PF Cool! 35,000 English professors just burst into flames [Gina laughs]. Like, that’s fine. That’s fine. Everything’s great. 

GT Let’s—can I—I wanna jump in, I wanna go to that question about who could this desi—I don’t know if I’m phrasing the way it is in the book but who could this design hurt? And this is something that I think we think about in tech—Well, we often think about it after the fact. Like, there’s designing for the happy path and thinking about the best use of this thing. “I’m trying to solve a problem for a person, so I’m gonna create a tool that they can, you know, solve a problem or achieve an end, right?” You’re rarely during that process thinking about all the things that could go wrong. And then when things get launched, particularly at scale from a big tech company, for example, there can be unintended consequences around privacy or, you know, data, et cetera. How do you weigh—And I know this is a really big question but how do you weigh the risks of the way that a product can hurt someone with the reward of the service, the thing that it can do for those people? Right? Cuz every tool can be used [chuckles] for good or for bad. I just think this is a conversation that we all have to have. Constantly. 

[25:55]

SB It’s a great question. I don’t have an easy answer. This is ethics. I included it in the book because most of the time—and I had this experience as an engineer in college. There was no mention, not in any course, in any workshop at all about the possible danger I could inflict on the world through my ability to write code. I think that’s wrong. I think that is a low professional standard. And engineering, computer science, is not new anymore! This is decades [yeah] old! As a profession. And we look at the impact we’ve had on the world, it should be something—Anyone who makes anything gets some slice of: “You are gonna impact people. And you’re gonna make things that hurt people. You better have some basic understanding of how to think about these problems . . . before you put stuff out into the world.” I’m not saying that startups sholdn’t start stuff and like, “Hey! Let’s see what sticks.” But ok, but they should have some awareness that these little things, once they become popular, have different effects. They should know those stories. And be familiar with those questions. Most books for design and engineering say zero about morality or ethics and I’m not saying that it should go into detail and say how to be moral, that’s way too complicated. But it should say: “Your choices in engineering have morality issues in them! People are gonna get hurt by what you make. And the more thoughtful you are about that, you can probably make something that is closer to your dream of actually changing the world in a good way.” To do that requires some sensibility around these questions. And that’s [yeah] why I put it in the book. 

PF No, I mean this is real, right? Like, it’s not built into the curriculum, in some of the programs it is an extra, you know, it can be a required course but there isn’t a—there are very few documents in sort of fundamental texts about ethics that connect ethics to the actual practice of programming. I think also because academic programs tend to be about computer science . . . which is very abstract . . . in its—

GT Yeah. 

PF As opposed to practice. And look, I mean, I bring this up a lot, it’s my favorite document along these lines is if you just search ‘risks dash L’ it’s a mailing list that’s been going on since the eighties about the risks inherent in computer systems and, you know, read that for a couple of months and your eyeballs will just ex—will just pour out—

GT You’ll ever do anything ever again! [Laughs] 

PF Everything you touch can—can kill everything. Like, my mouse can kill. 

[28:16]

GT It’s like when I had my child, suddenly everything in the world was something that was gonna hurt or kill her [laughs]. 

PF Oh yeah. 

GT And not just some innocuous object [chuckles] that was a piece of furniture in my house. 

PF No, it’s true, children make you realize two things: they make you realize you live in a murder factory no matter where you are [Gina laughs] and the second thing they do is that actually children are tremendous consumers of designed products. Like, I watch my daughter using like, you know, a keyboard or I watched her do Google Hangouts once and it was so frustrating that she couldn’t edit a message. That she a had a tantrum on the floor when she was like, five years old, and she was supposed to be, you know, typing to her grandmother and—

GT Yeah, my kid is figuring out a trackpad, right? For remote school right now and she’s seven, and I’m just like, “This isn’t intuitive at all! Nothing about this is intuitive.” 

PF No! These are—We really take them for granted. These are human participants in the system and they are like, “No way!” So, actually let’s—We’ve been talking about people who do evil and bad things unintentionally and people like Gina and I who lack all integrity [Gina laughs]. But let’s talk about who does it well? You’re obviously a fan too, right? Like you wouldn’t be doing this if you didn’t love design and care about it and think about it. Like, when you’re watching this industry, you know, I think everybody in the world would be like, “Oh, Jonny Ives!” But who do you like, watch and think, “I need to see what they’re thinking and what they’re doing.” 

SB That’s a totally fair question. I don’t know that I have a good tech centered answer. Well, here is one. I don’t know that you’re gonna like it but it was my birthday a few weeks ago and—

PF Hey, happy birthday! 

GT Happy birthday. 

SB Thank you. Thank you. I don’t need very much. I’m a happy guy. I’m not really like, a consumer kinda person but I bought a new axe. Given I can’t go to the gym anymore, and I live kind of in the woods, I split wood. I had a really bad, old, Home Depot 20 dollar fiberglass piece of crap axe. And so I bought like a decent axe. This axe is just well made, it feels really good in my hands, it’s easy to sharpen. It just works really well. And so my productivity for wood production [laughs]—

[30:15]

GT [Laughing] I mean that—No, but that’s real. I mean, it makes you wanna do this thing that—

SB It does. It makes me—It’s just so comfortable, it makes me wanna do the thing. And that’s the bar! And I’m still thinking about the axe while I’m using it cuz it’s still pretty new but I’m thinking about how much easier, it’s just so much less frustrating to use it, to do the job. 

GT You know, I—this might be function of my age but, you know, I spent ten years building a spec for to-do lists—a markdown language for to-do lists and building, like, apps to manage to-do lists, and I got to this [mmm] place where every time a thought came into my head, I wanted to build this practice that if I had a thought and there was something I wanted to do or at least wanted to look at, that I would get it out of my head, you know, as quickly as possible, this is part of a Lifehacker thing or whatever. And at some point I was like, “I do not want to pickup a piece of glass and have to turn it on and do the face ID and then launch the app and then type the thing, I just wanna write it down,” and so I just picked a pen that I really love and a notebook that I really love and for the last two years, I use a pen and a notebook. And every single day I sit down at my desk and it is inefficient and it takes ink and I’m killing trees and my handwriting’s really not that good but it’s become part of this, like, ritual that I do in the beginning of the day where I sit down and I write down my schedule and my tasks, and I love to do it and so I do do it and I’m just much more effective and so the reason I’m going off on this is that I’m looking at my notebook and my pen here but I just think that the tools that feel good to you and that let you do things that are kind of annoying that you don’t really wanna do but make you wanna do them, that’s so powerful. 

PF Well, you know what? What both of you are describing, right, is that it kind of invokes a ritual and a sense of sensation—in a group of sensations when you interact with these objects. So it’s like, “Oh, it’s wood choppin’ time.” For Gina it’s like, “It’s writing it down time.” And I think that—Like the computer never gives you that clarity cuz there’s always—You can always just flip the switch to another frickin’ thing and all that—You know the SDKs kinda blur together and you’re in the infospace. 

GT Yeah. 

PF And you’re just kinda like movin’ stuff around. 

GT It’s true. So Scott, for takeaway for our listeners, like what is the big takeaway that you would like for people—First of all: the name of the book is—

SB How Design Makes the World. 

GT It’s really good. I really enjoy it. I love that it comes from someone—I mean it’s obviously written by someone, by you: someone with passion and curiosity about design. What’s the big takeaway? What do you want people to take away from the book when they put it down? 

[32:32]

SB This first thing I want: people should be curious. “Why do I love this thing?” “Who made it?” “What other choices could they have made that would’ve made it worse? Why didn’t they do that?” And the same thing about things that frustrate them: “Who made this choice? What were their alternatives? Why did they have the power to choose this thing that affects me? What questions can I ask when something new is being made?” All that comes out of the book: curiosity, being curious about all the things that we use and that affect us. 

PF And, you know, this is an obvious point but it’s a very visual journey. Like, there’s a lot—there’s a ton of thinking and a ton of good design to look at and think through in this book which is very fun as you’re reading it. Scott, how do people get in touch with you and how do they acquire said book?

SB It’s on Amazon, it’s basically on sale everywhere. My name is Scott Berkun. My website is scottberkun.com. I’m most active on Twitter at @berkun. 

PF B-E-R-K-U-N, friends. 

SB Correct. 

PF Well, this was great. It makes me feel like I have a major integrity problem. However, I am even more committed to design after this conversation. 

GT Yeah, I’m fired up. I’m fired up. I’m ready to start talking about integrity in our design meetings. I’m excited—

PF Ah—

GT This is good. Thank you for joining us, Scott [laughs]. 

SB Thanks for having me. This is fun, you guys are fun. 

PF Thank you very much. This was great. Ah, Gina. 

GT Ah. 

PF That’s a good—good person. I like that person. 

GT That is a smart and passionate person. I like people with opinions and state them clearly. 

[33:56]

PF He has stayed on this track too. This is an important subject to this industry. 

GT Yeah, there’s a lot of thought here. 

PF People should go read that book. We really do try to factor design into all the work we do. And we, you know, we think about APIs that way; and we think about the platforms we build as objects that will be used by other human beings. And it isn’t always something that everybody’s excited about. They’re like, “What are you talking about?” It’s an API, just use this library and make the API.” 

GT We often succeed and no one says anything about it [laughs], right? Because good design disappears!

PF [Stammering] [Music fades in] Oh, yeah. So look, that’s just—it’s time for us to disappear [Gina chuckles]. That’ll be the sign. Like, this podcast is gonna vanish. 

GT Yeah, we’re just gonna vanish. We’re gonna disappear into the back of your life. 

PF Just something that’s in your ear, it feels so comfortable. 

GT Yeah, thank you though for listening. And thank you for having me, this was a lot of fun. 

PF Yes, you’re no guest! Alright, well, look, if people need us, Postlight is your digital product partner. We work with you to develop product strategy and then we help you build—design and build the things that you need to do in order to make that product strategy real. So when you are getting your business into the world, through the web, through mobile, we are the ones who will stand by you for months and often years to get that done. So, if you need us, how—how do people get in touch? 

GT You should send us a note: hello@postlight.com. When you’re thinking about your product and you’re thinking about design, you’re thinking about the ways that it could be better, reach out! Let us know what’s goin’ on. We read every email, all of us, and reply . . . a lot. And you can also get in touch with us on Twitter, @postlight. 

PF That’s right. We’ll give you a plan. We’ll give you a product. Alright, friends, let’s get back to work. 

GT Bye, Paul. 

PF Bye, Gina! [Music ramps up, plays alone for three seconds, fades out to end].