#013 - Design Thinking for Non-Designers

Robert Greiner 0:02

Welcome to the Wanna Grab Coffee podcast. In today's episode, Igor and I discuss the fundamentals of design thinking and break the concept down into manageable chunks anyone can take to increase their effectiveness. As always, don't forget to hit the subscribe button. And feel free to reach out at [email protected] or on Twitter at Wanna Grab Coffee.

Hey, Igor how's it going?

Igor Geyfman 0:22

Hey, what's going on, Robert?

Robert Greiner 0:24

Doing well, doing well. Hey, so just real quick. Since we're having a virtual coffee. What are you drinking?

Igor Geyfman 0:30

I am drinking blackcurrant flavored black tea from Twinings of London. Yeah, what about you, I saw I saw Chick-Fil-A cup.

Robert Greiner 0:39

every now and then we'll go and grab Chick-Fil-A for the family for lunch. And I'll grab a gallon of unsweet tea there. And so I'm drinking black tea from Chick-Fil-A. And so even though we very frequently go out and grab coffee together, we definitely get tea a lot of the time as well. So there we go, both drinking tea today. Alright, so we're doing something a little bit different today.

You, me and Charles at some point, over time, deliver different presentations at work for different concepts. And yours, which really resonates with me is around this idea of design thinking for non designers. And I think that in the same way, if you're in a profession that doesn't require you to write code every day, but you can write a script, like that's almost like a superpower where you can automate. If you're an accountant, you can automate your spreadsheets, you can you can automate formulas, you can, a lot of your workflow can just be taken care of. It's faster, it's more precise, that kind of idea. And so with design thinking, I've found in my career, that those kind of components, those elements that you've taught me over the years, have informed my craft as well. And so I'm really excited today to cover your design thinking for non designers presentation. So we're doing a little bit of an experiment here, because we're virtual, you're not in front of an audience. But I think the content is definitely worth sharing. And we'll do our best to make it as interactive as possible.

Igor Geyfman 2:13

You're so right, Robert and I I distinctly remember, you know, when I, my first job out of school, was like a marketing and sales job. But, through college, both through the coursework in college, but also side gigs that I had, I learned how to design. And I learned how to code. And when I started my sales and marketing job, I implemented both my development skills and my design skills. And my my colleagues, my boss, they thought I was a magician, because I was able to do all these great things, in my regular day to day job, which had nothing to do with design or development, that, maybe somebody else wasn't able to do. So it really is a superpower to kind of integrate these little hacks and these little skills into whatever you're doing, whether you're professional sales and marketing person, whether you're doing, you know, operational things, or maybe finance, I really think design thinking and the skills that comprise design thinking are very, very helpful and can sometimes make you seem like a, like a magician.

Robert Greiner 3:17

Yeah, definitely. So what do you have for us today?

Igor Geyfman 3:20

Yeah, so I'm gonna just start out with a question. And design thinking, a lot of times goes back to well, who uses design thinking? Or where did it come from? It came from designers. Right? And so I'm going to lob a question back at you, Robert. And just ask you, what do you think of when you hear designer?

Robert Greiner 3:44

Yeah, I have the stereotypical graphic designer. So images, and maybe assets that you'd put into a software system, or you're creating some kind of copy for a magazine or an advertisement, you know, those kind of things. It's very much my initial sort of anchor, my bias towards that term is very surface level, visual colors and typography and things like that. And I know, after especially working with you for so long, that's that's not the case at all. Like there's so much depth and nuance in this space, that you really doesn't even do any good to talk about design as a general term because it could mean so many different things.

Igor Geyfman 4:35

Absolutely. And, even for me, still knowing all that and having been in a lot of different spaces over the years, somebody says designer to me, it conjures up an image of a human being. They're probably wearing a lot of black. They probably have some sort of scarf that's helping to embellish their outfit, maybe a hat, maybe some really amazing glasses that they're wearing. They've got some sort of a big computer monitor a lot of color swatches going around, you know, little toys on their desk, but still this like very cartoonish stereotype of what a designer is. And there is some, and there's a lot of different designers, right? There's just traditionally, there's graphic designers, there's industrial designers who design, what is this pen look like? What is the mouse look like? What is the chair look like? There's architects, there's, there's, there's a lot of sort of sub genres in the designer field. And so there's a lot of different folks that, quote, do design work. But design is really a bigger term. And so when I when I think of design, I think back to an old Steve Jobs quote, and well at least I attributed to Steve Jobs, maybe came from somewhere else, and somebody knows, better attribution, please let us know. He said, design is not just what it looks and feels like design is how it works. And that understanding of what design is he didn't say design is not what it looks like. He said, you know, but it's, in addition to all those things, it's also how it works. And so that's a pretty expansive definition of design. And so to me, that really bears a more expansive definition of who a designer is. And I go back and I think of people who we might think of as an industrialist, you know, Thomas Alva Edison, for example, right? We probably know him for like the light bulb. But at its core, Thomas Edison was a designer. Right? A real designer, the Orville and Wilbur, the Wright brothers, were designers. Right? You go back and you look at someone who Akio Morita of Sony. You know, at some point in our life, we ran around with a Sony Walkman. And that's thanks to Akio sun. And Steve Jobs. He didn't go to design school. But a lot of people attribute design to Steve Jobs. Right. So he's a designer, but but also with that expansive definition. And maybe it's so expansive, that it gets to the point that it's maybe not useful anymore. But everyone's a designer. Every person who alters their environmen to be better to solve some sort of problem, a human problem is designing. Right? Like that's the core of design. Somebody asked me, Well, what is design? It's, it's basically solving complex human problems through some sort of intentional actor activity. And an even Curious, George, I'll talk about why. But Curious George, the cartoon character is a designer. And we'll go into that example a little bit later. Yeah, so we're all designers and, and design is really solving these complex human problems. And so that leads us to the next phase, what is design thinking. And I would say about five, six years ago, design thinking became a buzzword. Design thinking existed, obviously. But, you know, five or six years ago, it was on the cover of Harvard Business Review, it was on the cover of Wired and Forbes and fast companies. There are all these articles being written about design thinking, and it's the new thing. And if you want to improve your business, you employ design thinking, there's a lot of thoughts on, on what design thinking was. And in a lot of ways, it was presented as like a cure all, you know, if your company is struggling, just put a little design thinking on it, and all your problems will be solved. And it really culminated in a backlash. And I think about a year ago, maybe it's a two years ago now. There's an article published by one of the principals from Pentagram. Pentagram is a design collective, design partnership out of New York City, and has really famous designers in it, Paula Scher, who's an amazing graphic designer, and Michael Beirut, and, and many others, right? They're part of Pentagram, big collective. And basically one of the partners of Pentagram published an article and a video that basically said, why design thinking sucks and is a waste of time, and I hate it. Something something to that effect, right? Like, like all this hype around design thinking. All these articles in Forbes and HBR culminated with somebody really respected in design community coming out and calling BS on it. And then of course, you know, counterpoints being created but I want to go back because I don't think design thinking is a cure all. But I also don't think it sucks and it definitely has its place. And I think it's just important to understand how we can integrate design and design thinking into our everyday craft and everyday practice of what we do, and make up our own minds. Right. And so what actually is sort of the design thinking as a definition. And it's really a set of tools, and processes, design thinking is, is a collection of tools and processes to help us solve these complex human problems, which we do as everyday designers. There's a lot of benefits to design thinking, I'm not going to go into all of them, you can obviously go and look up articles, and we'll post some of those in the show notes. Things like making really expensive mistakes, losing market share, not getting maximum adoption for the things that we're creating, having competitors eat our lunch, not being able to disrupt ourselves, being disrupted by others, these subpar experiences, degraded relations, relationships, they all come from not employing some of these design thinking principles, as a way to, to resolve those. And I have a personal interpretation because design thinking to me sounds very passive. I'm going to think about it, I challenge people with the phrase, I think design thinking is actually much less about thinking and much more about doing. Design thinking is a couple of different things. And I've got them listed out in four different sort of areas. And we'll go through them one by one, and we'll talk about each area in turn. So design thinking is one, human centered. Two, it's integrative.

Three, it's action oriented. And four, it's iterative. And so let's let's go through one by one and kind of talk about what those things are and why they're important. So the first part of what design thinking is, it's human centered. Um, a lot of folks will use Human Centered Design or user centered design, you hear those terms thrown around, and design thinking and user centered design and Human Centered Design, they're not all the same thing. Right? So you can't actually use them interchangeably. Human user centered design is not a process or a set of tools. It's like a mindset that you bring to problem solving. And so the what is the mindset of being human centered is you start from what people humans sometimes call them, users customers, what they need, or what they want to do, what their motivations are, what problems they're trying to solve. And the key ideas here is that it's all about having empathy, for the people you're designing solutions for. It's not about you, or what you need, it's about what they need and what they're trying to do. And you need to develop the ability to understand and share the feelings of others to effectively engage in a Human Centered Design thinking process. What do you think about that? I mean, that's as that's the first component of design thinking being human centered. How does that resonate with you, Robert?

Robert Greiner: 12:59

Well, I was just had a conversation actually around building large software systems and the fact that we have a disproportionately overweight of males in software development, the fact that there are entire software teams building functionality that millions or billions of people would use, and they're not even remotely representative of society, and then the user base that will be ultimately interacting with their application. That seems to me like that's a sub optimal configuration. And so this, we have a, we are consultants, a lot of times at a client, I think through oh, you know, if I walked into Best Buy, for instance, I would go through these steps. And so if I'm building a customer application, for a large retailer, I put myself in that position, like what I want to happen, I'd be really annoyed. If every time I came back to the website, my shopping cart was just empty. But I represent such a small subset of the population and around my preferences, and how I interact with organizations that if we just built things, how I thought they should work, that wouldn't be great. And so it would be really cool for someone else on the team, for instance, who bikes to work, talk about how their experience would ultimately be underserved by a decision that's being made someone with kids, someone without kids, those kind of things and, and those are really basic, high level ideas. And there's so much nuance when you build these massive products, whether it's software or I think definitely the the more intentional empathy, I think is really what you're talking about, around forcing yourself to think through how will everyone truly be impacted by the decisions that we're making. putting ourselves in the shoes of the end user i think is is a great place to start. And something that going back to our conversation earlier in this discussion, even a little bit of that would go a long way, because it's just not really happening at all.

Igor Geyfman: 15:13

That so right, just as an example, I remember being being a young designer, and I had a client, the client was like, hey, I love the Porsche website, you know, the car maker, and you just need to make this design look like the Porsche design. And you know, he's a Porsche customer, he was really well off, and they were selling a particular type of product. The only problem with that was the website that we were building was for a product that was mainly targeted towards parents, moms specifically, and folks that were, I would say, sort of medium to low income folks. Right. And, and for them, the aesthetic of the Porsche website, and the feeling from the Porsche website was not congruent to the feeling that they were looking for when they're shopping for this service. And I really had to explain to them like, yes, you, as a human, as a consumer really love this, but the people that are looking to buy your product, they feel differently, they have different needs. And sometimes it's really hard to to convey that, especially if somebody made up their mind. And they think that, they like a very particular sort of thing. And it's important to be humble, and say, I'm not my customer.

Robert Greiner: 16:24

Yeah. And and if I add to that, let's if we could stipulate that this service that was being built was very beneficial for this group of people, then as a designer, your responsibility, your social responsibility is to to accurately and in a compelling way, articulate the value that this product gives to improve the lives of the people who are going to end up using it. So if you dork around and try to go and and build some aesthetic that looks cool, to service your own internal wants and desires, and you don't consider the end users of the product, they may not get visibility to it, they may not buy it, they may not really understand that, hey, this is a beneficial thing for you and for your life. And that through a design decision, demit ultimately could diminish the overall good ripple effect that your product or service has. And that's really scary if you think about it, because you might not even get in front of these people.

Igor Geyfman: 17:19

And it comes off as disingenuous like this company doesn't understand me, they don't understand my needs. Or even worse, they're presenting a product in a way that it doesn't line up with its actual capabilities. Right, they're presenting me with something that looks like a Porsche, but you know, is actually maybe a Kia, for example. And so there's a disingenuous factor there. So yeah, human centered, you know, really important part of what design thinking is, and and why it's important for us to use it. The second component is integrative. And that's all about looking at situations in a different way. And coming up with new solutions, that go way beyond just improving the existing alternatives. And it's, the integrative thinking is really key, you have to consider the system, the systems, the meta systems, the environment, the ecosystem, to look at all the different facets of a problem. And a lot of times, as we approach, problem solving, or design of any kind, we sort of consider the problem at face value. And we don't go to that higher level of integrative thinking, to pursue other entry points, or other maybe more serious underlying problems that we have to solve. So that's sort of the integrative component of design thinking. Number three was action oriented, I mentioned this already, I really think design thinking is much less about thinking and more about discussing and working through problems. And you have to make those ideas real by prototyping by making things and testing those things. The currency of design thinking is prototyping and testing, all the other components, they work to facilitate that process. But it's all about, here's my hypothesis, I need to build this prototype to test the hypothesis, then I need to test it, I need to understand the results. And I need to rinse and repeat. Design thinking at its core is based a lot on the scientific method. And so even though it's a quote, a design tool, I think it's actually very approachable for people who are scientists or engineers who have any sort of STEM background, because it's something that I think is a familiar way for them to explore the world. You know, so to me, action oriented, that's number three, big component of design thinking. And then the last part is it's iterative.

Robert Greiner: 19:56

Well, hey, so real quick, going back. So if I'm a software developer or an architect or an accountant, and I'm working on my project, what's something I can do in this space to create a hypothesis and and test something. So I know if I'm going down the right track. Give me some practical tips there.

Igor Geyfman: 20:15

You know, for example, let's say that you, you have a particular issue that you're working on, as a developer, and you need to build some sort of resolution for it. And a lot of times, you're like, okay, I'm gonna go whole hog, I'm gonna write the user stories, and I'm gonna start working into those user stories, I'm going to develop the solution, I'm going to make sure that all my data and services are in the right place, I'm going to make sure that my business logic is in the right place, I'm going to make sure that my front end code is right. And I'm just going to ship it right by the time you're able to do all those things effectively, you may have spent a really significant amount of time, and then you're shipping it. And really, that's your prototype and test phase. But that prototype and test phase that you just went through unintentionally, is really long and really expensive. And so what you have to think about is, what is a smaller increment of work that I can do, to see if I'm going in the right direction. And so, just as an example, I may not need to create all those data and services, I may be able to just do some quick mock and stub data, right? And work that into just like a super simple interface and just show that first. And that will probably take me one 10th of the effort and time to test with, users or stakeholders, rather than building the full solution. And so you want to think about, okay, what am I actually trying to understand here, and me quote, solving the full problem, whole hog is not actually going to give me the best outcomes, I'm going to do something smaller, I'm going to build a little prototype, I'm going to fake some things to get a reaction to learn, and then I'm going to ship that, and then I'll know okay, well, you know, this solution didn't really work. And so now all the services that I would have had to write to make it work in a production environment, I don't have to write because I know that this solution didn't work, I didn't just waste the other 90% of the time solving the problem in a way that may not work, right. So that's a small example. But if we abstract away from from that particular example, it's all about breaking your bigger problem down into smaller experiments. And then designing small sort of prototypes that you can test one 10th of the time,

Robert Greiner: 22:33

I think that's really insightful. The idea of you're going through this prototype and test and feedback phase, whether you want to or not, it's your choice, as a team, as an organization, how long that phase is. And if you want to cram everything into a single release, that's very infrequent, you are going to ultimately put something out that potentially has a high risk of displeasing your user base. And then by the time you get that valuable feedback in, the reviews, the one star reviews in the App Store are there. And it's just going to take a Herculean effort to fix what could have very easily been identified and remediated early on.

Igor Geyfman: 23:14

Yep, that's right. And so that's what I mean, like, you can't think of design thinking as extra steps. You have to think about it as trying to gain more efficiency. And the process that I described in that last example, is, the same thing that Eric Reese talked about in the lean startup and MVP, as Eric Reese defined it was, as a minimum viable product was, what is the smallest amount of work that we can do to learn the next thing that we need to learn about whether this startup is going to succeed or not. So just as an example, and then the last part is this idea of it being iterative. And the road to a successful solution is definitely not a straight line. So anybody that says, you know, we're gonna implement this design thinking process, and it's very linear. And then there's step one, step two, and step three, and step four, and step five, and then we're going to have some amazing results. It's just not realistic. That's not how the world works. The road to successful solution is not a straight line. It's an iterative line. It's messy. Sometimes you have to go through loops. And those loops are understanding, creating and learning, understanding again, and then creating and learning. Right, that's, that's the big iterative loop. And that's it. Like if you really think about design thinking in those four ways, as being human centered, integrative, action oriented, and iterative. That's, that's really what you need to know, as sort of like the big, big takeaway here.

Robert Greiner: 24:46

So for anyone listening who has a normal day job outside of design, thinking about these four concepts, and maybe one of them will stick out as applying like, oh, you know what, I haven't shown what I'm building to anyone in a while or I wonder what our end users think about this, or what was the last time that we ran a focus group? Or what can I show as an experiment and a hypothesis around what a good idea might be. Is that the right thing to do, if you're in one of those normal day jobs is just think about these four concepts and see which one sticks out to you as making sense to go and explore more,

Igor Geyfman: 25:25

I really, I really think so. You know, if you really want to dive into design thinking as a methodology, we'll post it in the show notes, you can go check out the original material from the Stanford design school, right? That's kind of where it was developed into its original methodology, as we see it today, there's probably a dozen different design thinking methodologies, if you Google that you'll be able to find, but really, it's good enough for you to dive in and, and go through the D school methodology, it's pretty straightforward. It's got five components to it. You know, empathize, define, ideate, prototype and test. And you can see how it all sort of works. But, I think it's a little bit more helpful, especially when you're starting out, is to ask these four questions, you know, am I thinking of my customers, rather than myself? Or the organization? Right? Am I being human centered? Am I being integrated? Am I looking at the solution from a lot of different angles? Am I considering all the systems that involve, the meta systems, the ecosystem? And am I am I looking at different facets of the problem? Am I being action oriented? Am I designing experiments? Am I understanding what I have to learn? And am I doing sort of the minimal amount of work that I need to, to have that understanding to have that learning, rather than trying to do something in a big bang? And then am I comfortable going through the understand create, learn loop and being iterative? With with my approach, I think if you're thinking about those things, I think you can go a long way into implementing, you know, the goodness of design thinking, without having some deep understanding of the full methodology and all the different processes and methods that are involved in it. Right, you don't need to have crazy design thinking, certification program that you go through those four concepts, I think are pretty accessible.

Robert Greiner: 27:21

Well, hey, thank you for taking the time to explain this. hope it was helpful to everyone listening, any parting thoughts on your end?

Igor Geyfman: 27:28

I'm going to just walk through a little example. I kind of mentioned this a little bit earlier, Robert, I originally developed this as a talk a little over five years ago for like a company conference that we do every year. And at that point, we're still getting together. And the company conference was held in Las Vegas. So I had my presentation, it was ready to go was like super polished. I had all these examples. I get to my hotel room. I turn on the TV. And on the TV is Curious George, like the cartoon. And for whatever reason, I don't know. Like, I was like, oh, man, like, let me watch this episode of Curious George. And I'm watching this episode and as I'm watching it, I'm like, Curious George is a design thinker. And I'll share the example with you. I'm watching this episode, it's pretty incredible. what I ended up doing is actually reworking my entire presentation that night. So instead of using the kind of boring examples from my past professional life, I actually just broke down this Curious George episode for the audience, which kind of a risky move. I didn't know how that was gonna go over, you know, but there's a George, who's like a little monkey is friends with a squirrel. You know, and this squirrel has these oak trees that it's collecting acorns from. And one day, there's a construction crew, they come out. And they're basically cutting down branches from these oak trees that have caused the street to be kind of overgrown, right, so they're cutting back the brush a little bit. But the problem was that the branches that were growing from these two trees helped the squirrel cross the road without ever having to be in traffic, right, it gets sort of just jumped from one tree to the other tree without having to cross the road. And now the squirrel is trying to cross to get the acorns on the other side of the road. And it's creating havoc, right? Like the squirrel almost like died from being hit by a car. And Curious George is like observing this whole situation. It's like, man, the problem here is that these cars aren't stopping for the squirrel. And it's putting the squirrel in danger, right? That was the most visible thing that George could see. And he said, that's the problem that we're going to solve. And so this is an example of being integrated. And so now this thing that I'm able to observe, that's the thing I'm going to fix and so George had this really amazing idea and basically he cut out little circles of red and yellow construction paper, and he plastered them into the intersection lights. And so basically he just kind of like, created a traffic accident. Right? Because he was he was trying to control the traffic light in such a way that would cause the vehicles to stop. So the squirrel could sort of cross the road unimpeded. And by solving this problem for the squirrel to be able to cross the road, he created an even bigger problem. And so all these cars were not able to cross the street. And George is like, hey, that's not something that I should be doing right? And what he did, he went back. And he tied a piece of rope from one of the cut branches on one side of the road to another cut branch on the other side of the road. And now you had a little piece of rope that was connecting the two trees across the road, and the squirrel could sort of run across and like looking backwards on it. You're like, Oh, yeah, like that's a pretty obvious way to solve that problem. But how often are we guilty of looking at a problem that we are facing or somebody else that we're close to is facing and then just going in to solve that problem as literally as possible and not looking for other vectors to better understand what the actual problem is, and to create a better solution that doesn't have the outcome of crashing a bunch of cars. And so to me, that's what I took away from that episode of Curious George, that's what caused me to redo my entire presentation. I just love that example. Right? Because it's written into this children's show, and it's very accessible to everyone who watches that episode. Robert, thanks for having me on and talking about this topic. We're gonna post a lot of extra information in the show notes. If anyone listening to show has questions, hit me up on LinkedIn. Send me a DM and nothing brings me more joy than helping people find their creative confidence in their inner designer in their day to day lives. So I'll be more than happy to to help you out and engage with you and help you out.

Robert Greiner: 31:52

Yeah, I can. I can vouch for that. It's the truth.

Igor Geyfman: 31:54

Thanks, Robert.

Robert Greiner: 31:55

Thanks, man.

Igor Geyfman: 31:55

Yep, see ya.

Robert Greiner: 31:58

That's it for today. Thanks for joining. And don't forget to follow us on Twitter at Wanna Grab Coffee or drop us a line at [email protected]