The designer and the developer: A happy marriage

Thanks for showing up. I know you had a party last night. I hope you are well prepared for this session and the rest of the day. If you fall asleep, I will definitely bring the party last night and not what I'm saying up here. I would just like to know who you are, what you do, not in that much detail, but how many of you work with development? From Back Home Development? Yes. Do we have any designers? Few designers? Yes. Any project managers, key account people? Yes. Okay. And maybe a male crowd. I appreciate the women also showing up. We don't see a lot of those in these crowds. I'm Laura. I work with digital business development and I do that in my own company. I used to work for People with these great guys and for designers also. I work with the digital business development process, facilitation and project management for different companies. Some of those I've worked with in the past are huge global accounts like Mariel, who is a pharmaceutical company providing meds and vaccinations to pets and production animals. And those of you who know me will know that I'm very, very scared of dogs and cats and all that. And I don't know such things. So that's pretty weird. But for Designit, we did a corporate website in Ombrako, but we also helped them set up a digital acceleration lab because everyone wants to know about digital. Everyone wants to work with digital and can we do it any faster than we are doing right now? So that's what we help them do. I also work for a lot of Danish companies in the public sector. This is Kroa, who also has an Ombrako website done by the great guys from Mariel. And then I work with a manufacturer of components. Gortek, they are based in China in the Shandong area, which has a lot of industry facilities and manufacturing facilities. But we also help them understanding the concept of user experience. I wouldn't say we succeeded that much, but now they know there is such a thing. And a bit of design expertise. This is very noisy, isn't it? A bit of design expertise because they wanted to move into consumer electronics. They do these, you know, Apple headsets we all have. They do PlayStation controllers and all these things. So they want to accelerate that part of their business also. So that's just the part of digital I'm coming from. Then I am very much inspired by the design thinking methodology. And that's also very much what this session is about. Design thinking. And what is design thinking? Design thinking is actually a very structured way of working with creativity and innovation. And design thinking always focuses on the user. And that's also what this session is about. So just to get a bit of understanding. And I really apologize because usually I'm at these very bad projectors. And then when I come to a screen like this, my sights get very pixelated. I hope your eyes won't bleed, by the way. But design is good for business. There are a ton of these statistics out there. This one says that design conscious companies perform better than other companies. You will find a ton of these examples. But what is design conscious? Design conscious is actually also what we call user driven. So those companies that focus very much on the user and the user experience, they tend to do much better and outperform the other companies. And outperform their competitors. And design thinking is in no way about the designer. We know the designer diva, right? All pixels have to be very perfect and all that. And it's not about aesthetics. It's about a way of thinking. And it's about a way of understanding and acknowledging user needs in another way than just making things pretty. Because it's all about people. And these people are all users of the products that we all do every day. The products and the services we deliver. So I would like to introduce you to some tools and methodologies about how to understand these users and how to make them really, really happy. Yes. A few tools. This is the design thinking process. And there are also a ton of varieties of these. But this is from the D.School at Stanford University. And this actually explains it very well in very broad terms. The design thinking process always starts with a lot of empathizing. And actually empathy is something you can train. And you can teach. And you can learn how to understand these users. So you actually go into an empathizing phase. Then you move on to a definition phase. Because the design thinking methodology would always say, we don't know what's the actual problem before we talk to the users. Maybe we think we want a corporate website. But if we go into empathizing and understanding, understanding users, it might be something completely different they are looking for. Not a new corporate website, but some kind of tool or service that they use every day that can help them make their lives much easier. That's the definition phase. That's when we decide, well, what do they really want and what do we want to help them do. Then you go into ideation. You go into prototyping. And you go into testing. And I won't focus a lot on these last phases. They are also very interesting tools to ideate, tools to prototype, tools to do testing and experimentation. I won't go into these. I'll focus on these first phases. Empathizing. The reason why empathizing is important is that you have to understand users. You have to know where they're coming from. You have to know what are their pains. What would they like to gain? How can you make their lives easier, better, whatever you're trying to do? And what you also have to understand is, that they are not rational in any way. Not rational at all. And when you start talking to them and you ask them all these open questions, you will get a feel of what really matters to them. Because if you ask them all the right questions, and then provide you, they will provide you with all the right answers. Would you like a new corporate website? Oh, yes, I would very much like a new corporate website. But if you ask them, well, how could we make your everyday lives easier? How about your work life? What are the main pains? What are the hassles of your work life? If you start asking these open questions, you will get all these not very rational answers, but they are what you really want to do, what you want to know in order to do right, and not just what they think they want. They are also very emotional. And I'll get back to that, because some phases in a digital project become very stressful, and some become even painful, and you don't sleep at night, and it's all very... tense. And just to understand that users feel just the same is actually pretty helpful in that process. I'll get back to that. Users are not like you, and they are everything like you. We should never try to project our own feelings about something, or our own perception of things, onto what users might like. We have to really understand what they would like. And they are people just like you and me. So, how do you understand these users? You can do a user journey. And actually, a user journey is a lot of things. And I'll just try to address certain methodologies in the user journey that you can all dig deeper into. But the user journey is great for understanding users in a lot of ways. The user journey focuses on the actions and the experiences. So instead of asking these questions, would you like this service? Would you like that digital project? You would actually ask the user journey, tell me, what do you do when you get into the office in the morning? What's the first thing you do? What do you talk to your clients about? What do you talk to your colleagues about? Okay, then now you're at your computer. What's that like? What happens? What do you do when you turn on your computer? Which programs do you use? Which calls do you make during the day? So you take the user through a specific day, and then you find out, okay, this is where it hurts, or, this is where I might improve the experience. And the user journey is great because you get to focus on actual actions. So you don't ask them, how do you feel about that? You just ask them first, what do you do? And then what do you do? And then what do you do? And then at some point in that conversation, they start talking, and then you can ask, okay, but why? Why do you do that? Oh, that's because the system is just overloading and not enough performance, and blah, blah, blah, something, something. So you focus on the actions first, because then you get a broader understanding of what their everyday lives at the computer actually is. And then you dig into these experiences and get a bit more information about those. The user journey is also a great way of addressing a problem or something you want to define, because there's always a before, a during, and an after to an experience. So every time your clients, for example, interact with a website you did, there's a before, there's some way they learn about the website, maybe they read about it, maybe they heard about it, something, something. You get to address all those issues before the actual experience. Then you ask about the actual experience. Well, coming to the website, what do you think? What do you want to accomplish? How did that happen? Was it hard? Was it easy? What did you do? And then there's always an after. And the after, I said after, actually. That's Danish. There's an after, and the after is really important, and I'll get back to that, because actually what users tend to remember is how the experience peaked and how it ended. And those two sets, those two points in the user journey are the most important actions at all. So remember how the user journey, peaked and how it ended, and then try to optimize and enforce those actions. Then you identify touchpoints. This is what we do a lot working with digital projects, right? We know when the user interacts with AdWords or our CEO, or when they come to the website, when they go to our Facebooks and Twitter and whatever. So we are actually quite skilled and trained in identifying touchpoints. But what we could learn from in digital projects is also addressing the non-digital touchpoints, right? So if we have a customer service department in our company, we could go talk to them, and then they just ask, well, how could the website improve your everyday work? What could we do to address clients' needs? What do you experience about the clients' needs? So just identifying touchpoints, both digital but also non-digital touchpoints, is very valuable. Then there's a guy called, Slavotsky, I think. He talks a lot about hassle maps. And his concept is, if you try to understand people's hassles, and you help them solve those hassles, you make their lives easier, they will be happier and healthier and everything else. But if you really try to identify, okay, where were the hassles in this user journey? I actually wanted you to sign up for my newsletter. Why didn't you? What were the hassles? I couldn't find it. The form didn't work. I didn't get a receipt, so I didn't know if I was signed up or I had to do it again. So if you really try to take an interest in what actually happened and what worked and what didn't, you can work with those areas and then try to make the user happier. And then there's the peak-end concepts. And there's a guy called Daniel Kahneman, who's a behavioral economist or psychologist, I think. He's a Nobel Prize winner. He did a book called Thinking Fast and Slow, which is really great. He did an experiment. Actually, he got inspired for his own experiment. He found the inspiration in the studies of colonoscopies in Danish rektal undersøgelser in the 60s. No kidding. And I'll get back to that. Not the colonoscopy, but the findings of that study. But what the study showed was that what users actually remember relates very much to how the experience peaked, what was the experience when it was at its very best, which is very strange talking about colonoscopies, and how did it end. That's what users remember the most. So that's what you should also try to focus on. Thank you. Then the user journey is great for identifying some kind of baseline. Users always have hassles, and they always have peaks. But you can talk in the project team about, Okay, where do we want to put our baseline? Because we all know that user expectations are going through the roof and they want everything now. But you can try to set a baseline, and then you can say, Let's bring them up to the baseline and then start working on the other experiences that are the peaks and the endings. So you can always do some kind of baseline and agree in the project team, okay, we really, really need to address these hassles because they're actually blocking, and then start moving on to other parts of the user journey. Then the user journey is great for identifying moments of loyalty. You will always know if you ask users when did they talk to other users about a certain problem or a certain great experience, and then they will start telling other users, and another user journey starts. And it just goes on and on from there on. Then they involve new users, and you get a lot of ambassadors. But back to understanding the clients. Actually, users are for you guys. They are end users. They are all kinds of people. They could also be a client if you work for an agency. They could also be your colleagues. But I have just tried to focus on the client user journey because actually we all know we tend to stress the end user experience very much, and that's so important. That's why we do the information architecture and the wireframes and the user experience and the navigation and blah, blah, blah. But actually for you guys, you also have a client who's probably calling you or pinging on JIRA, or Teamwork or Basecamp or something. So the client journey is actually pretty important to take into account because I think that will make maybe your workday even better. So this is where I did a drawing. And I always try to do this because it's really, really ugly, but that shouldn't stop you from doing drawings and illustrations. It's a great tool for trying to understand these things. So I did a client journey. So, um, and I actually made it even uglier because I hate dogs. So, uh, we have a new project, a communication, um, girl or guy. Let's say it is a group from Cora. She gets a new project. The top management decides we have to have a new corporate website. Then Glee thinks, Ooh, shiny new project. That's funny. Then she goes into a phase of collaboration with different colleagues and you are probably not even involved at this, uh, stage. So she goes into some kind of collaboration. So they have some discussions within the organizations that we as agencies probably don't know anything about, or we don't know the specific details of these conversations, but they have some conversations and then they end up sending the RFP to a variety of, uh, agencies. And then they're really, really tired because that's actually quite a stressful phase getting to the RFP. Then they get a lot of, uh, proposals back and they, they get a lot of presentations and hopefully they're very happy about those. Then they go into negotiations and purchasing has to have its say and technicalities about contract. That's actually pretty frustrated or straightening. And this is where we meet the client, right? Because the key account people did all these initial discussions and work on contract and scope and budget and whatever. But actually around the, the signing of the contract. And the agreement, that's where we get into the picture as the people who have to in the project teams who have to actually do something in this project. So then we have a kickoff and then we have a design phase and user experience and all the fun parts of the, uh, of the project. And then at some point we have some design concept approval. Everyone is very happy. Then we go, I know this is a caricature, but just to say this face is very, very stressful for clients. We go into a face that I call the black box of development. And some of you are very skilled in working with agile and you do your constant release cycles and you test with the client and your demo for the client. But actually the client feels a bit insecure in this face. Some of them might be very technically skilled, but actually the tendency is the digital projects are within human resources or communications. Or marketing. And they are not that digitally savvy as you are. So it's actually a very, very stressful face for the client. They have a heavy content work themselves. This is where they realize, oh no, I can't just do a copy paste from my old website. I have to rewrite all the content. I have to onboard some someone to do the new photo work. Maybe we even need to show new videos because they're so outdated. If we even have some of those in, in, um, in our old, in our old website. So that's actually what's going on in the client's head. There are all these kinds of prioritizations. The client comes back and say, oh, it would be really cool if this feature was doing like this instead of like that. And then you say, that's all pretty cool, but I didn't do the search yet. Wouldn't you like me to prioritize finalizing the search? And then we can go into all these detailed discussions. So it's a very, and they have top management coming knocking at their door saying, Hey, where are we on the digital? Project is anything happening? I haven't seen anything yet. No, it's coming. It's coming. So it's a very stressful period for the clients. And I actually think we have, we have, you know, the, the prelaunch stress. The client also feels that very strongly as you all do. And then we get to launch and hopefully everyone is really happy because you're, it's actually such a relief that we even got there and then the journey can go in all sorts of directions, right? After launch, you can just go back into depression because now, you know, the workload you still have in front of you. You can also feel secure because you have someone helping you out or you can just go peak and say, this was just the coolest project ever. Now we are going into the world telling everyone about it and everyone loves it. Yes. So how do you understand what's going on in these clients mind in this very stressful, stressful period that I call the black box of the development phase, you could do an empathy map. And this is also a tool for the design thinking from the design thinking methodology. What you actually do is you, uh, you map out what the client says, top left, what the client thinks, top right, what the client does, middle left and what the client feels, uh, middle right. So I did an empathy map of a client, a typical client in this black box of development phase. So she could be saying, please let me know what's going on. Why aren't we moving faster? Yes, I know I said so, but I'm sure it's a minor issue, but can you please fix this? Please help me out. Could be things the client is saying. Then what does the client do? Well, she calls all the time. She keep bringing up issues that are addressed already. She talks to clients, colleagues and top management and gets new ideas. She puts a lot of stress on the project team and she adds to the workload. So it could be quite frustrating also for you as developers in this phase. Then what does he think? She actually thinks this is hard to understand. I can't really get a grip of this. I don't know what's going on. I think they're helping me out, but I don't know exactly what they're doing to help me out right now. They could, they could also be thinking, am I making the right decision? Feeling insecure? Not knowing exactly if they're making the right decisions. Why aren't my colleagues prioritizing this? They feel alone in this project. They are the main project manager and they have to keep everyone else busy, but everyone else is busy doing everything else. So they feel quite stressed and quite alone. And I could really use some help around here. Then what do they think? They become really grateful whenever there's a fix. They become happy. They become very happy when they experience moments of success, but they also feel very insecure and tired and way too busy. So if you do this kind of empathy map, you actually understand the client a bit better, and then you can address what are the main pains for this client? What are the main gains for this client? Because usually a client will jump into solution mode saying, this doesn't work like intended. Could we please fix it like that? If you understand that it's actually because the client is feeling insecure, for example, and you talk about this in the project team, right? You get a feeling of what this client is about. If it's an issue of making the client feeling insecure, instead of jumping to a solution, you could just make the client feel secure about going into the discussions. They feel they have to have an answer for you, but actually you can help them provide the right answers. So it's all about discussions along the way. If it's a client, they're feeling very insecure, which some of these communications and marketing people actually do. It's all about discussions along the way. They can also feel that they are way too busy. Maybe your project manager can help them in some way, just getting a process understanding of how they could attend to these things without being heavily overloaded. Maybe they just feel they don't get any understanding. Then you can help them get some kind of acknowledgement saying, I really understand this is a stressful phase for you, but this is always like that up until launch, and we will get there and it will be great. But it's just a matter of digging a bit deeper to understand what's really going on when they seem very angry or stressed or whatever. There's always something behind it. So how do we work with this in project teams? We know it's all about the actual experience, and this is Daniel Kahneman. And a very specific thing, you could do is you could try to identify what is the peak of this experience. What do I want to be the peak of this experience that I am part of? And what is the end? And how can I optimize and improve this? This is actually the study of the colonoscopy. And patient A, patients were asked to rate the pain they felt within 30 seconds. So they rated their pain within every 30 seconds. And actually, patient A had a way shorter experience of this colonoscopy. And patient B was under this experience for a much longer time. But actually when they all come out and they were interviewed after that, and actually they were interviewed immediately after the study, and then they were interviewed three months after and one year after. And how they remember these experiences and yet to improve, experience. And that's what it's all about. Patient B had a much greater experience than patient A. And this study has been repeated over and over and over again, not with colonoscopies, but also just holding hands in water, for example, and then turning up or turning down the degrees so it feels uncomfortable at some point. But all these studies show that if you have a bad experience, it's probably because the ending was really, really bad. And then the way it peaked was also very bad. So always think about your peaks and your endings. And I have some very specific examples. What you do in service design, for example, is you do service evidencing. And as service evidence, the most prominent example that you probably all know, I didn't stay at this hotel because the hotels I stay at are not this fancy that they put a gold sticker on the toilet paper. But what they do is that every time there's been a maid in the room cleaning up the room and doing the bed, she will do some kind of folding to the toilet paper. And that's a service evidence. That's a way of making an intangible service tangible. So you know that there was a maid that cleaned the room and you can see that, right? You can see it on your bed and you can see probably things aren't lying all over the floor anymore. But this is the service evidence. And we can work a lot with service evidencing in digital projects as well. If I go back to the very ugly client journey I did, these stars could represent some kind of service evidence because all these experiences and deliveries you do, they can be very intangible and they can be quite hard to understand. But the more tangible you can make them, the better. An example. When you communicate your to-do lists. That's why project managers, I am one, love these to-do lists because it's a feedback. It's a feedback saying very tangibly something happened on something very intangible. Actually, it also releases endorphins in your own head every time you check, you do a check mark in such a box. It releases endorphins every time you do a to-do list mark as done. Then there's the understanding. And you don't have to be psychologists, all of you. But it's really helpful for a client sometimes if someone just says, I understand where you're coming from and I know that you have a lot of work on your table and I know it's very stressful and how about your colleagues and what about top management? Are they behind you? If you just spend two minutes in such a conversation, they will loosen up. And then remember your feedback mechanisms. Actually, the service evidence. It's all about the check marks, right? Also, we can work digitally with all these smaller transitions and receipts. It's also a very tangible way and actually a kind of digital service evidence every time we do all these things. You all know them from MailChimp. Then from Skripal. Skripal works a lot with the endings of projects. And I don't think that Maiken is aware. Or Anders Hector or whoever decided. But actually, when we know that endings are really, really important as to how we remember the actual experience of a project, this is how they celebrate a launch, for example. Actually, these were four launches in a week. Then we have a glass of champagne together just celebrating. And I know a lot of you have these celebrations. I also see posted on LinkedIn from time to time like a launch cake of some kind. So just like a kind of celebration. So you have to make tangible all the intangible projects you are going through. And then because you know that the endings are so important as to how people remember these experiences. Actually, we also got a few bottles from one of our clients, which is also a very cool idea. And after that, we decided to send the client two bottles of bubbles every time we did a new launch. So the client is also celebrating. Just us within the project team. We also invite the client to celebrate this successful launch. Yes. That's pretty much it. Any questions? At all? I think I have one. Yeah. And when I read your introduction... Do we need a mic? I can... Okay. When I read the introduction to this, I was thinking about the relationship between the developers, the designer, and the customer. Yeah. And what I experienced is often that I was very much relating to what you said about knowing and emphasizing the customer. But we often, I think, as developers, feel that our customer gets to be either the designer or the customer. And I actually feel that is... I don't like that situation because I shouldn't be earning a hug from you. I should be earning a hug from the customer. We are pure aware. Do you have any recommendations or thoughts about how to improve that process? Yes. Very much so. Because actually, we could do this user journey for... Actually, this is the client, right? We could do this for any participant in the project. If you want to... Actually, be a bigger part of the project, right? You need to have your project manager understand this part of the process. How stressful it really is. And if you, as a developer, you are the main person that could cause less stress in that period of time, in that project phase. You need to be part of the project much earlier on. And I actually think we're... At the agencies where I worked previously, I actually think we invited... We invited the developers earlier and earlier into the process. But, you know, it was not natural. Because you invite the designer and then the key account person and then the information architect or something to the first kickoff. But actually, at Skrybol, they do. They invite the development team into the process at the kickoff stage. I think sometimes... And I know where you're coming from. Because actually... As a project manager, I have met a lot of developers that are introverts. And probably as an introvert, you don't feel that secure in that client conversation. Where you have to address issues or problems or something. So you have to identify the developers in your organization that likes to have these discussions with the client. So the project manager just doesn't have to feel... Well, I don't think that Troels feels comfortable going into this conversation. But you could go to the PM or the key account or whoever and say, I actually know that these people are comfortable going into this conversation. And we know that the client is very... You know, it's a very stressful period up until launch. And this development phase creates a lot of insecurities. And they don't know exactly what's going on. So please invite us into the process. Because we can actually reduce the stress of this period. I tend to say that you don't have to... You're talking about not feeling... Comfortable. Yeah. Stuff like that. But you can learn a lot by just listening. So even though you don't sit there in the meeting and say a lot, I think that a lot of developers would learn a lot about the customer by just being at some of the early meetings where all this insecurity is there. And just listening to what happens. Because when you sit at the very stressful part of the project where everything is getting... There's change requests. There's everything. Then you will have a much better understanding. Of what is the reason for this change. Why do they want to change it right now? And maybe also, is there something else I can do that is not so time-consuming that would actually mend this part of the process? So my opinion is really, really important to get also the developers, even though they don't say much. I'm not one of those. Really? It's very important to have them there. Because just listening to what people... What people say in this process is also very important. Yeah. I agree completely. And also, I really just think it's about people acknowledging that that phase is very stressful. And we can do something to help provide for the client and also within the project team to create some kind of comfort and security around all these issues going back and forth and being very stressful. Great point. Sebastian? When we are in this period, the black box, developers tend to just run around and work. Yeah. Yeah. How do we feel like having cut out all the middlemen in this period? And having a conversation between the developer and the customer to solve things and highlight all the problems? Yeah. When doing that, like it was a lot of time and talking. Yeah. And not so much developing. Yeah. Which tends to... Yeah. Yes. Yes. How... Yeah. Yeah. It's all about striking the balance right. Because I just found out it's my earring making all these noises to my headset. I'm really sorry. It's all about striking the right balance, right? Because I tend to be one of those people going into the middle saying, we don't have budget for that. And going to the client saying, you can make all these change requests now. We will never get to deadline. So I think it's a matter of... It's a matter of having that conversation with your PM saying, I need to work for nine straight hours in a row without anyone disturbing me. Can you give me eight hours in a row? It will be Tuesday. I will work from home. I will get a lot of things done. So you just make some agreements and just speak openly about it. Because everyone can understand that you need to work for eight hours straight. Because I also think that we PMs tend to disturb a lot. We have... We have... Very different work processes. PMs are on the phone, on emails, on Skype, and being in constant in and out of projects where you tend to immerse yourselves. I'm speaking to the development part of the crowd now. Tend to immerse yourselves much more in these projects. And actually, PMs just want to get things done. So if you can, you know, just make that argument, I will get a lot more done. If you just give me eight hours, I will get eight hours straight without any disturbances. I actually think it is almost a human right. Because I don't like that either, working for, you know, ten days straight and just people disturbing you all the time. So if you make the arguments, I will get a lot of things done. I just can't be disturbed all the time. But can we just do one day Tuesday, one day on Thursday, and then you can disturb me on Monday and Wednesday and Fridays. Hmm? Yes. Yes. Also, most times, you do a lot of inviting the clients into a Trello board to make a total transparent process. Yeah. That helps a lot, especially with the first phase. Yes. Much more, like, you just lean back and say, you've done it on the phone. Yeah. You see the process, the progress on the project. So, yeah. Yeah. A great idea, inviting the client into Trello boards, of course. Just getting... So they see there is some kind of progress. But actually, some of these clients may not understand all tasks on the Trello board, right? So it has to be supported by some kind of communications. But your PM could also do that. You're the one moving tasks and just finalizing, finalizing, finalizing. But there needs to be some kind of communication around it. If you wrap up every day, just spend the last ten minutes just doing... cutting out these... just do a screenshot. This is what was done today. That's it. So just... supported by some kind of communication because they don't always know what these tasks are all about. And I don't either. Yes? I have a little extra tip. Normally, in my projects, the last stress phase when you're doing the launch is already the critical thing. And normally, it's only one or two functions or so to make the launch to finish. That's the problem. So remove it from there. Take it out and say, okay, this has to be in the phase two because you have to meet the deadline. So not everybody is waiting about the launch and say, okay, this process is only going deeper and deeper. You're not meeting up with the deadline. Yes, I agree. Yeah, because digital projects are never finalized. We can always launch and then we can launch and launch and launch again. Deploy, deploy, deploy. New features and bug fixes and do a lot of issue resolution after launch also. Yeah. You're absolutely right. Any more tips, tricks, questions, comments, concerns? René? Yeah. You talk to them. Yeah. Yeah, exactly. Or maybe you discuss in the project team, right? It's just a matter of sometimes you need to have that discussion in the project team because you can feel he is so annoying. I can't talk to him because he's just making all these demands all the time and I can't say anything. You know who I'm talking about. He's just making all these demands and I can't even say anything. But if you just spend five minutes trying to dig a bit deeper saying, okay, what is going on? Why is he so stressed? Sometimes you may not talk to him because you're not in a position to do that because the client is so stressed and you can't even, he doesn't pick up the phone when you call. But maybe you just have this discussion in the project team just trying to figure out, okay, what's really going on? Why is he making all these demands? Is he in a very stressful situation? Top management is on his back and we really need to help him deliver something. How can we provide for that? So just trying to understand, why is he like that? Asking, but why, but why, but why? Yeah. Any more questions? Yes? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah, exactly. Actually, that's a very good question. Because this is just from my mind, you know. I just did this. But it's just a tool saying, you could have peaks, but try to find out what they really are. But actually, I did a, I left out a slide, so I'll just, because that actually answers your question, I think. Here we are. Can I do this? No, I can't. I have to unskip. Because this was actually a project, I, I did. I like, I like telling about all my failures also. This was very much so a failure. So this is a, this is an app for, not dog owners, but pet parents, as they're called in Mariel. So pet parents wanted this social community, sharing all these great photos of their dogs, getting some health advice and tips from, from vets. So that's the app. It is launched. Ooh, shiny, interesting. Then the onboarding really, really sucked. People couldn't sign up. When they signed up, they couldn't log in afterwards. It was a mess. So the user experience is really, really bad. And then, okay, they get support. I'm in. Check out my cute dog. Hey, where is everybody? Because everyone is left on these onboarding screens. No one cared to call support, right? So everyone just forget about it. And then where is everybody? And then, which app? Why would I even use it? So this is an example where you need to improve your baseline, right? You need to really, really work with the hassles because the hassles are blocking everything else. So it's a matter of defining, are these hassles blocking? No, they're not. Okay, then let's try to work a bit on the differentiating experiences also. But if you have any blocking hassles, then you should really address those and then bring them up to baseline. And then you can start working on your differentiating experiences. So it's a matter of how blocking they are. This is a service anticipation gap, right? So there is an anticipation, and then there's a service, and then there's a huge gap. So you should always try to bridge that gap before going into these peak experiences. Just one example. I have a ton of those. Yes? I think we need to make room for the next speaker. Thank you. Thank you very much for coming. Thank you for all your questions. And have a great CodeGarden. Thank you. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.