 You can be a skilled UX designer and still make shit a product because you don't know how to. One skill that nearly every design team is lacking is knowing how to facilitate design decision making. So you might have a team of very talented designers, but when they come together as a group, team politics creep up, team dynamics spring up, group sync happens. So what ends up happening is instead of producing a great product, what you produce is a mishmash of compromises and poorly made decisions. So in this video, we're going to share with you an excerpt of the Design Life podcast where a CEO Jonathan Courtney appeared as a guest if you expect and he's going to show you exactly how to develop that skill. The Design Life podcast is hosted by fellow YouTubers and podcasters. Femke and Charlie do check their YouTube channels out. The links are in the description below and make sure to subscribe to their podcast. It's always filled with fresh design knowledge that you don't want to miss out on. As you watch this video, let us know in the comments below how design decision making happens on your team. We're very curious to find out. And now without further ado, let's jump right in. I started an agency with a friend of mine from Australia. We both moved, we were both living in Berlin and we started an agency because this company we're working at. So we're at a startup in Berlin, both as designers, and we were like, these people don't know what they're doing. They don't take design seriously. They don't care about usability. They're stupid, whatever. We're going to start our own company and it's going to be like, you know, utopia of design. Everything perfect. Love it. Everything will be perfect. AJ and smart will be the shining light and whatever. Anyway, like three years after starting up AJ and smart, we're both thinking of shutting it down because we're like, oh, wait a second. Actually, it just is annoying. Like it's just like doing design projects is so subjective, so political. I mean, we are heavily focused on corporates. I would include like bigger Silicon Valley companies in the corporate thing. I would include Twitter as a corporate and Uber as a corporate. So for me, the problem was, you know, first of all, we'd always be unbelievably excited when a client would call and it's like, oh my God, we've never been able to work with eBay before. We're going to work with eBay. This is so cool. Oh God, it's all cool. We're going to work on a new product for them. And it was always these because we're our company was focused on the beginning of projects. So we were always working on their new cool stuff. And day one was like super exciting. You know, we're doing the kickoff. Day two is like, okay, so we're starting to see some politics build up already. You know, week two, we're showing the first kind of sketches, first ideas, turns out nobody was aligned on anything and everyone's already come up with new ideas in the meantime. And we're like, all right, we got to realign again, still cool, still cool, all good. A week later, the new product manager comes in and has talked to their cousin and their cousin likes the color green and uses Tinder. So now that's now that's the interface that we're going to make. And then four weeks after that, myself, my co-founder, like, should we try to get out of this project because it's going nowhere? And it actually just kept happening over and over and over again for the for like, actually like six years. And we were like, we were living the dream kind of UX wise because we were working with all these cool companies. But like, both of us kind of also dreaded every project. Like, there was always like, I would like clench up every time one of these clients would actually sign the contract. And we're like, all right, here we go. Here we go. We're going into one of these projects that's going to turn out badly. And I think the problem was always the same. It wasn't that we were working with stupid people. It wasn't that we were working at stupid companies. The problem was that collaboration, there was like no rules around collaboration at all. It was like, company A would do this form of design thinking for the research phase. But just this one team within this company does personas, but team X in the same company has never heard about a persona and does business model canvas. And team D, they just go right into the screen design and stuff like that. So there was like this. Most companies kind of had this ability to collect information pre starting a project. And like, you know, they would maybe hire McKinsey to do this or something. It doesn't matter. And most companies had the ability to often badly, but sometimes in an okay way, they had a way to execute it, which was agile, right? Eventually that started coming in. They had agile development teams. So there was this piece in the middle that was missing. And that was, well, how do you go from, here's the product manager or the company saying, we want to make this new fashion app to having a version of it in your hand that is like a nice high fidelity prototype. That part's kind of easy, but how do you get everyone on the same page that, yes, this is what we were all talking about. This is the product or this is the feature that we were talking about. Like we would work on just a new feature for corporates and spend six weeks going around in circles and then maybe six months going around in circles on how to make a wish list or something. Just because we as the agency, as AJ and smart, we didn't have the right tool. So long story short, okay? We started trying everything. Every design thinking conference and workshop imaginable went to every business model canvas, value proposition canvas, lean canvas, all the canvases. We went to all these agile workshops. We spent a lot of money just learning like, how do we just get people aligned so we can sit down in front of the, like, and actually just make the design, do the design work, which is actually what I like to do. I like to sketch it out. I like to put it into back then Photoshop or sketch and now Figma or whatever. It doesn't matter. And that's the satisfying part for me. And so myself and my co-founder were like, trying all these different things and they were kind of working. And finally we're like, you know what, this actually sucks. This is like maybe, like he was, he was actually a musician and I was kind of thinking of going to filmmaking. So we were just like, maybe just quit and do something different. We were like super down on it. Then we were flying to our client actually Lufthansa, which is kind of, we were flying to them to do a normal UX project. And I had the sprint book with me, which I hadn't read yet. It had just come out. And I literally just read most of it on the flight to them. And I was like, holy s***, like Michael, this is the missing pieces of jigsaw that we've been going around in circles for, for the last few years. And so we landed in Frankfurt at the Lufthansa office. And basically, instead of doing the, we're going to do this like innovation workshop for them or something. I can't even remember. We actually just presented the idea of doing a design sprint to them. They're very interested in it. By the way, thank you Lufthansa for just like fully swapping the project around to a design sprint. And we got to do our first design sprint with them. And we realized that within a week, by the way, in a week, we didn't have the final product. But in a week, we had everyone aligned and we didn't have to talk to them every day and keep getting misaligned. So within a week, we were able to say, well, this is the direction. So myself and my co-founder could go away and actually do the design work for the next six weeks, come back to the client. And this is usually the bit where I'm sweating. I'm like, oh God, the presentation. I bet you in the meantime, one of their friends saw some feature in Pornhub and now they want that in the app for some reason. I should say, by the way, that's, that's not related to Lufthansa. You're all very lovely. I was just trying to make a joke. Anyway, Pornhub. And now they're like, okay, actually, we actually saw this new thing and we want that in the app now as well. But actually, what happened was we presented it to them and they were like, yeah, this is exactly what we're looking for. Great. Because you're aligned at the start. And not only that, they were part of the design process, which I was very suspicious about. I was very suspicious as like, I was like arrogant. I mean, I still come across as arrogant now, but I was a very arrogant UX designer where I was like, you know, I'm fighting for the user. Everyone else is stupid. No one else knows what's going on. I am the UX designer. You're all dumb. And actually that's why I was a bit against having people from my client teams sketching, right? In the end, it was the best thing I ever did. And how do you get everybody on board to do this? Like quite a lot of our listeners, they, they sometimes struggle with a bit of skepticism from their teams when they want to introduce a new process or try something different. I mean, the benefits are obviously really clear, getting everybody on the same page, making decisions, getting alignment. But how, do you have any tips for how you might introduce that if it's a totally new concept for somebody at their company? Yeah. So we got lucky that that was sort of the, or unlucky that we were sort of pioneering at least for our clients this topic of design sprint. So no client wanted to do it really. Like they were just like, whatever. Yeah. Can you just make the thing for us? Yeah, exactly. Or they were like, oh, we already did design thinking on it. And we're, and then we're like, okay, we have to somehow work our way around this. Yeah, you only think about something once, right? And so what we did actually was we created this exercise called Lightning Decision Jam, which was a, was taking all of the kind of like the quick wins, the good, the good feelings you get from a design sprint and crushing it down to a one hour meeting kind of structure. And we would basically offer clients and that's actually how we did it with Lufthansa. So when we landed, we ran this like crushed down version of a design sprint. And we ran it on a kind of small topic like how might we improve the design of the kitchen so it's more collaborative or something like that. And they were like, oh, wow, like this would have been something we would have had to talk about for weeks and weeks and weeks. And now I've got this like drawing and I'm actually really excited about it. And we're like, yes. So that's the idea. It's the principles that you just saw and practice there is the idea of a design sprint. And so usually we'll, or back then at least, we would assume they don't want to do it. We would assume because you have to just assume that what you're presenting to them is not interesting. And you have to think about it from their perspective. They want to look good, right? The people on the team, you want to make them look good. So you don't want, they don't want to do a process that might seem like a waste of money or slow things down. So what we offer them or what we still offer even today sometimes is that we'll go and we'll ask them, hey, when do you, when do you have team retrospectives? And they're like, oh, we do it like once per month, the first Friday of every month or never. And, if it's never, we're like, well, you should do a team retrospective and we'll come and run it for you. And we usually do it remote over Miro. And honestly, at the end of that session, you know, the end of that one and a half hour session, essentially the sales pitch starts, I say, well, you felt how good that was. That's how a design sprint feels. I basically say things like, imagine if you were able to do, if you'd been able to do that for the previous product you worked on. And then they're like, oh, so I guess the bullet point answer is don't try to sell. Oh yeah. And the other thing, I'm sorry, I'm just thinking back to the sales calls when I was still doing sales. What I always say as well is that this is not a process change for your company. This is a plug-in and play tool that you should only use when you have a problem that's big enough. So keep everything, like a lot of people come into companies and we used to do this as well. And it's like, we're the digital transformation agency. We're going to teach you all design thinking and then we're going to document everything. And then all of you have to stick to this. We come in and we say, we'll teach you this one thing and you can use it whenever you want. But also I'm recommending, we even say, I recommend you don't do more than four of these per year. And then they feel like it's very non-committal and they don't worry so much about it. That's a really smart way to pitch it because changing processes, especially in a big company, I'm thinking back to the bigger companies I've worked at. And it's like a giant truck that's hard to get moving and it's really slow to start turning those wheels. So frustrating. And if you're a very short attention span, very impatient, person like me, the effort and years it would actually take to turn a company, it's just not worth it for me. And I tried it. Myself and my co-founder tried angles where we had two year long contracts with clients where we helped them build their innovation labs. What a bad idea that was. But things like that where we literally tried to change their company culture from a design perspective. And after a while we were just like, you know what, let's just respect that these companies are slow moving and that they have their it's not a bad thing that they're slow moving. It's also because they own this part of the market. They've got amazing assets. They can do amazing things. But we shouldn't be arrogant enough to think we can actually turn things around here. Hey, are you enjoying this video? Then you should definitely subscribe to our weekly newsletter where we share product design news, latest tech news and tips on UX and UI. Link is in the description below. Now let's dive right back in. So it sounds like you bring in these workshops sort of at the beginning stages of a project or a design process. What about after the workshop? What happens next? Like, how do you bring everything you learned, everything you aligned on into the next phase of the project? What does that kind of look like? In the beginning it was a disaster because we would just do it and run and never like, you know, we're out of there and we would just hand it over to the internal team and the internal team would have the burden of having to like siphon through it all and figure out what to do. We basically create a very simple document that says, this is the MVP. This is maybe version two. But first do this. Here's all the raw files. Here's this. Here's this. Here's this. Here's this. Here's what we would recommend as your backlog, but you can prioritize the backlog yourself. But this is our recommended prioritization of the backlog. And we actually do that with the team. So it isn't a good idea to do the dump and run approach that we used to do. Most clients were fine with it, but some gave us really good criticism that it was like, yeah, you guys come in, everyone's super excited and then you disappear and then everyone's confused. So yeah, we now create like a very clear handover document, which is essentially, it's kind of almost like what would be created at the end of a longer design project to hand over to the developers, but this is also optimized so that the executives know why decisions were made. Right. So that if it does, if an executive's like, why is the wish list blah, blah, blah? Oh, wish lists are my nightmare, by the way. And it's like, oh, well, this is the reason because this, this, this, this, this. And here's how it works in Pinterest. And here's how it works here. And based on the conversion rate and blah, blah, blah, blah, it's all in the document. So the designers aren't left hanging with a lot of the stuff that we might have created. And the other thing I would just say is the design sprint is one recipe, right? It's like 30 exercises strung together into a recipe into a workshop. And I think that's the way you should look at it. I think it's a very good recipe for validating and starting projects, but you need different and often custom workshops for different types of companies. So I think that's the, I'm not trying to bring up the book, by the way, but that's the point of the book is to teach you how do you build your own custom workshops based on a set of principles and based on what your company needs. So that's kind of the, you know, the aftercare of the design sprint is, you know, custom workshops then. Yeah, I find so I work at Uber and it's a very big company. And like kind of what you were touching on earlier about how every team kind of has their own way of doing things. I experienced a lot of that in my role. And so it can be really hard to like get all of those cross functional teams together and like work on a process when everybody has their own kind of process. And we've done a few things like sprints or jams, but they often don't really have any clear outcome. We kind of just get together and do the thing. And then we all go back to our normal jobs and don't really come back to a line or figure out what next steps are. So yeah, that's something that's been really challenging for me a little bit. And so yeah, I'm curious how something like this, this workshop methodology could maybe come into play there would be really interesting. I think, you know, the, what you're describing is how it is at every company. And I also tell my like, we work for corporates that are also not exciting, you know, like, and they're, they always think they're the only ones they're like, oh, we're from an old industry. You know, it's really messy here. Like, you know, it's like really, I'm like, look, believe me, the Silicon Valley companies are just as all over the place. There's sort of the only difference is that they're moving maybe a little bit faster. And they're new. But at a certain point, this like cruft builds up, right? And it's just, it isn't. And that's the thing I also want to make clear is like, it's, it's almost, in my opinion, impossible to solve that on a company structure level from inside all of these companies who even have excellent from the outside standardized systems that it still doesn't work. Everyone just does their own thing. So that's the, for me, why I think it's, it's more on a, on the individual to try to, you know, incentivize these teams to maybe want to run workshops. But I, you know, if, if I was in a company full time right now, I wouldn't, I wouldn't bother trying to systemize things or try to force everyone to do the same thing. I would almost just, I would be the workshopper. I would say I would be the person offering. Hey, I, by the way, you guys, you're starting a project next week on this new feature. I'd love to volunteer that I facilitate this kickoff. And the reason I would do that is because, and I've seen this at Lego actually, once you're seen as the person who can come in and help others do their work better, and with less annoyance, you are wanted all the time for every project. And it's just like, also a great, it's also a great career move because you become like the catalyst for getting work done better. And I think companies are missing right now. There's agile coaches right now. There are design thinking coaches in some country, countries, companies. But I think this facilitator role is missing where it's like, you know, this team that's working on this new headset or something is like, Oh, we've got all these crazy ideas and like, we want to try to work on something and let's just get together next week. And, you know, so that we don't have to all talk over each other and go around in circles and be really annoyed. Should we call in Femke for the next, should we see if Femke is bookable for the next two days? That would be, I think, ideal to have in every company. As I'm listening to you say this, I'm like, this sounds amazing, but I'm already coming up with excuses about why this wouldn't work for us, you know? Yeah, yeah, everyone does. Yeah, like, I don't know, convincing people to take a full day off working on their things that they have to do. Oh, no, don't do that. Don't do that. Don't do that. Okay, so well, well, what I would say is, what I would say is that you have to present it to them in a different way. Presenting it to them by saying, you know, imagine, you know, imagine a calendar week of Monday to Friday. Let's say this project is going to be finished in two weeks, no matter what. Let's say the date of release of this landing page is set no matter what. You can, you have two options. One is we front load all of the decisions. So 80% of the team doesn't even have to think about it anymore. So front, front load it all into Monday, and then 80% of the team can walk away and not think about it anymore. Or you can spread it out over the entire two weeks so that you're constantly getting distracted and pulled away from the thing you want to do when actually we just need you. And usually, you know, usually it's just like four hours or something like that. We just need you for four hours. I don't even call it a workshop. I call it a strategy session or a kickoff session. I just would rather present it to people as a better and more efficient use of time and not as a big complicated annoying schedule, destroying event. And also, by the way, I also say, hey, I'm facilitating it. You can pretty much sit back and relax and just give me information when you need it. So that's the other thing is the as a workshopper, your job is to make the experience super enjoyable for them. One of the things that makes workshops so tiring or meeting so tiring is that everyone has to the whole time think about is it should I talk now? What's happening next? Like, is it like, is that like that person who's the extrovert, they'll just figure it all out, right? I actually know the answer, but I know that this person will talk over me. And and there's like this weird political thing going on with this person. So I'm just not going to talk. And, you know, she's the intern. So maybe she shouldn't talk either. And like, there's all these weird dynamics that are secretly bubbling in the background. When you facilitate, you just remove this layer and everyone can actually just put all of their brainpower on the problem, which is actually more interesting and enjoyable. So what I say is, Hey, by the way, when I walk into the room, by the way, I even have a worse situation. A client books me. And then I walk into the room and everyone in the room is like this, like, why is he here? Like I could have done this myself. And what I say is, Hey, everybody, I am, I'm Jonathan. I'm actually here just to make your meeting more enjoyable. You have all the information. You are like, I'm the guide. I'm not coming in here to solve your problems. But what I am going to do is make this meeting just feel very smooth for you. And I'm going to take, I'm going to take all the heavy lifting off of you. I'm going to document everything. I'm going to photograph everything for you. All you got to do is just give your skill that, you know, you are really good at. And I also say, and you're going to feel at the end of this, like, you know, you're going to feel way less tired than you usually do because you don't have to talk a lot either. Developers love that bit as well. That sounds like listening to you talk about that. I'm like, that sounds amazing. Like trying to picture that in my work environment. Yeah, it sounds like it would take off so much of the heavy lifting, the weight, the, even like the dynamics, the political things that play that you mentioned can sometimes be really draining. 100%. Yeah, it sounds amazing. I need to figure out how to bring this into my team. Yeah. And on my side, as a, like, you know, design team of one on the marketing side, for me, I love the sound of having other people and more involved in the process. Yes. You know, I feel like so often it's just me and my computer, like, stressing over, should it be here or should it be here on the screen, you know, getting more feedback and more input, having other people just as invested in the project sounds like a dream. And it's faster. It's more efficient because the, like, our designers never have to sit down at their screen and just make something from scratch. The whole team, and it's, it's like one of those things where people usually ask, hey, isn't that designed by committee? No, it isn't because in the end it is anyway, because you make the thing you want and then the team is like, nah, we're changing it anyway. And eventually it's compromised, compromised, compromised, compromised, compromised. So it's nothing like you started it out no matter what, you know, you show it and it's like, all legal can accept this because this and this and this and this and this. I'm sure at Uber you know about that. Every design change means you have to go through legal and that's pretty much every company and often what we do in these sprints is we recommend, hey, bring someone from legal into the room so they can tell us, especially when we're working on banking apps. I don't want to have to go around 10 times and change a button's text 50 times until legal can tell me, okay, yes, the font size is okay. And yes, the GDPR rule is okay now. But yeah, I think the point is as a workshopper, your goal is to be the guide. And that's the thing of, you know, being Gandalf rather than Frodo, you're there to unlock their superpower. You're not there to show off how good you are. This was my mistake in the beginning as being, I was a workshopper and I thought, I thought my job was to show off and show how good a designer I am and how like confident I am and all that kind of stuff. And now I'm like, I'm here so that you enjoy your work more. Hey, I really hope you enjoyed watching this video. Let us know in the comments below what your main takeaway is and how your team does design decision making. Also, don't forget to subscribe and hit the bell button. It really helps us spread the UX knowledge even further. And I'll see you next time. Bye.