 I'm very happy to be here with you. I'm actually also very happy that you're all interested in probably the only session to not have a single line of code, nothing. So if you want, you can still jump out. So what I'd like to talk a little bit about today is design thinking and what it is and what it is for us within McKinsey Digital Labs and how we apply the various interpretations of design thinking in the process of delivering smaller, large-scale digital transformations with many of our clients. I was just joking last week, completely unrelated to this session. So I'm currently working on a project in Hamburg, Germany for probably the last five and a half months. And it's a pretty big team, about 20, 25 people. The majority of that, I think, are developers, various kinds of developers, full stack, front-back, microservices, the whole lot. And we used to have this joke that we as designers are the guys who make things look pretty. That's our mandate. Whereas you guys, the developers, are the guys and girls who only write text. Nothing serious, right? So basically, none of our job is extremely serious. But of course, on the other hand, to take it to a more serious level, that's not true. So this common place thinking of you have designers who sit in the corner doing something which is very nice, but by the time it gets built, it's something that's completely unrelated and unconnected to the customer. And that you have developers on another corner of the room just coding something and these two guys are not talking. That's the wrong kind of attitude. And I think that what I'd like to show you a little bit today is how that is not the case through the way that we work with McKinsey Digital Labs. So today, I'd like to talk about design thinking. And design today is being referred in many different contexts. As you have product design, you have interior design, you have UX, you have UI, you have visual design, experience design in a more broader terms. And many times, the definition of what you use to describe design is pretty much based on the output that you want to see at the end of the process. So if you're designing a brand identity to a client, then you would think that or you would say that that's a nice design. And the logo and the colors and everything is designed. But that's pretty far from the truth. So design is a process. I think design actually is a verb. So design usually starts with a business or a social challenge that is well-defined. And then you have a very complex process. I mean, we try to simplify it. But there's a very complex process that sometimes can take months until you get from a problem to a possible solution. And whatever happens before the first output and whatever happens after the first output is design. The actual output, I don't think it's designed because there's so many other factors playing into that. And if you think about it when you will talk a little bit about prototyping, by the time the first rough prototype gets to the user, it has gone through so many different hands and so many different disciplines that it will be pretty unfair to call that design. That's not the output of a designer or a design team. I'll try to keep definitions short for today. But basically, if you want to take a stab at what design thinking is, it can be one of the interpretations. So I think the most important part of this is that it's user-centered. So it really has to start with the user. And I think the second most important part is it's a problem-solving method. So it's not a one-stop shop. And it's not a template that you can always use the same way. It's a mindset. It's a mindset of always starting with what the user has as an issue. Many times, the business obviously plays a huge factor. If there's a business need, that has to drive what you're solving for. But when you actually get to the solution, it has to start from the user. It has to start with the user. And so it starts with the user. It's a problem-solving approach. And it's very important that it's really quick and dirty. So I don't think it's new to any one of you in the room. I don't want to over discuss it. But I think that these are the three traits for design thinking in general. I think it's very important to know that design thinking is not at least to my experience or our experience. Design thinking is not a proprietary designer way of doing things. It has to be something that is being shared by the whole team. My experience is that it usually refers to as different things. So if a designer and a developer are discussing a specific tool, it can be something of a larger problem, a larger part of a user journey. Or it can be something super small like a button and how the button behaves. You will have different ways of describing that problem. And you will have different ways of arriving there. But the fundamental thing is that you have to have that discussion going on from the very first moment. So ideally, when there's a problem, very important when there's a problem that you're trying to solve for, when you define that problem, ideally, that definition is already being discussed and being digested by a diverse group, not just designers, not just a business owner, but a diverse group that definitely has people with the kind of skill sets that you guys have. I think, again, if you want to a little bit simplify of how, let's say, we in McKinsey Digital Labs do it, this is one way of looking at it. It is by no means a sequence. It's more like three different stages. But these stages will always overlap. The first one is immersion. The second one is ideation. And I don't even want to say the third one. But the third one there is iteration. So it's really important that when we talk about design thinking as a process, the first thing is really to understand the user. So there will always be the business problem that's the origin of all the projects. There has to be a business or a social need or a cause or an issue that you want to solve for. But the first thing that you need to do is understand that problem and then go after your users and try to understand how they experience that problem. And what you'll notice is that the more you discuss, like you can never really have enough user sessions, even in the beginning of any project. The more you talk to your users, the better understanding you will have of their problems. And the thing is that you don't have to have really long discussions. Like you don't have to do three, four hour interviews to get really important insights. Something of a three, four minute discussion with, say, five different users. So 20 minutes of your time can be extremely valuable. If you're asking the right questions and if you're using the right kind of methodologies. And I will give you an insight into what those methodologies and tools are today. So immersion is extremely important. There's a whole array of tools that we use or are there in the market. It's really important that depending on the project and depending on the specific problem, depending on the kind of users and the kind of insights that you're looking for, you will use different techniques. So an ethnographic research interview might be a really good fit when you're trying to figure out how elderly people use their television sets at home. Because it's not going to be easy for you to talk to them at the store because you're like 40 years younger than they are. They will not engage with you on the street. So it's probably easier to go for quality and try to find one or two person, for example, who invites you to their homes. You can document the way that they live. So you get the context. It's not just a problem description. I cannot find, if you're thinking about, let's say, remote control, the buttons are too small and I can't find them. That's not enough. Why can't you find them? Are you sure that they're too small or maybe the buttons are just in the wrong order? So that context will only come if you immerse yourself with that particular user. So we use ethnographic research. We use shadowing is when we basically become the shadow of a user for a certain period of time. This user can be acting in the physical space. So it can be in a retail environment or a store. But it can also be an online environment. So just a few weeks ago, I was in Shanghai doing a project. And we had a very insightful user session. We talked to three different types of users who might all be interested in buying the same product that our client is trying to sell. And first of all, China is completely different from most everything in the world in terms of how they consume content online and what kind of content they consume and what kind of portals they get content from. And basically just by sitting with one of these girls, spending probably like 30, 40 minutes of her explaining of how she books travel online. There's no way you can get that from any study or any presentation because the live narrative of that person is not gonna be there. So there's different kinds of user research but immersion in general is pretty much where we get our insights. Also it's not something that you can have enough of. So it never stops. It's just somewhere in the beginning. Ideation is a second, let's say, stage where once we have a specific idea as to what we need to design for, then we use various ideation techniques. It's very important to think in systems in terms of just standalone ideas. I'm sure it's very similar to the way that you're building solutions as well. So it's not just a standalone solution here but it needs to work as part of a larger ecosystem. That's the same thing when we're thinking about user journeys or solutions. And iteration, I mean obviously that's something that I don't have to talk about too much. Like there's never a finished product. Even when you think that your product is great, you can always improve something and tweak something. Therefore, iteration should be pretty much the activity that you just never stop doing. I will also try to give you a little bit more examples to that. So when we say we start with the customer, it's the context, right? So it's not just what is the problem told by the user but what is the context of the problem. So it's really hard to book tickets online to use a travel example. It's really broad. I mean, that can be a number of issues. Or I as a user don't use a particular online booking system because I think or I believe or I perceive that they don't give me the best offers. These are all different scenarios. Like just what I said now, like three, four different scenarios. We need to be with the user. We need to understand the context in order to understand what is it that we need to solve for. So it's pretty much context. And when you think about what it is that we're designing for or what's the root of the problem, it can be an existing pain point. So something that specifically the user says that he or she is having problem dealing with. But it can also be something that they don't know that that's a problem yet. So it's not necessarily some, they will not necessarily reveal the one thing that is really that you need to solve for. They will reveal a number of insights and a number of pain points and maybe needs and you will have to filter them, weigh them and that's how empathy comes in into the whole picture. So empathy is something that allows you to get a better understanding of what they are struggling with and empathizing with your users. Obviously it doesn't mean that you just smile and try to be friendly with them. It means that you really are trying to step into their shoes and really try to understand what it is that their problem is. And there are a number of techniques for that. It's really important that you don't build from secondary information. You don't build from canned information. It's really important that you actually talk to your users. Again, really a three minute session with one really good question or two really good questions can bring you extremely valuable insights. We are working on this particular travel project in Hamburg, Germany and it's a cruising business and we spend about two and a half, three hours on one of their cruise ships, getting to know the ship and just talking to customers. And out of those two and a half hours probably we spend no more than 30 minutes with I think maybe eight or nine customers. There's no way we could have gotten those insights if you don't go to the ship. So it's really important that you have to go you have to be in a situation, you have to be in a mindset where the customers where your users are willing to share information with you and you have to really listen well. And again, taking a video, taking notes, these sound like super simple basic things that we shouldn't even discuss. This is really the most important thing. Like you need to record everything and then you need to have a system to weigh these insights because you will not be able to design for all the problems, right? So if you ask a user, what's wrong with their mobile phone bill? They're gonna name like 15 things that they don't like. The type is too small, the numbers are not clear. It's unclear whether the promotion or the rebate was applied to the final sum or not. There's gonna be 15 issues but you cannot design for 15 issues at once. You need to start with the one that's the most pressing. And in order to do that, you need to really go deep and you need to document everything. I think it's also important to note that you need to be ambiguous to the domain. You need to talk to experts of that particular domain. And it's also really important that when you're trying to immerse yourself with your users, don't just think of very strict competition. So if a user has a problem with an online banking system and they say that they would really wanna use a better mobile app to take care of their personal finances, go and look at how Tinder functions or go out and look at how Uber functions. Because the way that those applications actually make it easy for the user to get something done is something that you can take an element of that and apply the same element and the same thinking to a completely different set of problems. So in marketing or in branding, what usually used to be the paradigm is you have really frequent competitive analysis of how different brands compare to each other. That methodology or that approach is completely useless with us. Because, I mean, not every day, new banking applications don't come out every day, right? So you will not be able, just by looking at the competitors, you will not be able to really think in a holistic way and in a mind-sub-shifting way. You need to look at completely different industries and you need to look at completely different interaction models that actually, even to the extent that if you have a certain demographics or a certain user and you're working towards a better banking solution, feel free to look at how a different target group engages with, let's say, Tinder, which is a completely different mindset, definitely different mindset. Because those are the trends and the different patterns that you can pick up and apply with your process. If this is too fast or too slow, please let me know, let's keep this session interactive. Also, by the way, if you feel like asking anything or if you really disagree with something, I really wanna know it now in front of the crowd. So let's keep even this presentation interactive. So when you talk about ideation, I think another misconception is that you have designers with colorful t-shirts and very thick glasses sitting in a tower and just thinking of crazy ideas that just work out of the box because that's how creative directors are with agencies, they just think and it just works. That's not the case, unfortunately. So the way that we usually use different ideation techniques within McKinsey Digital Labs is always very specific to that particular problem that we're solving for and always very inclusive. So the best ideation sessions are the ones where we're discussing, let's say, customer journey aspects of our solution with a guy who's working on microservices. And it sounds a little strange because what can that guy know about a button or how big the type should be on the screen, but it's those kind of super tiny details that lie underneath the surface that will bring you the best solution. So when we ever get to ideation, usually we try to balance the generation of new ideas and the kind of quick, rapid brainstorming kind of ideation to something that is more structured, more synthesizing and more focused. Also in terms of lateral thinking, breaking pattern thinking. So I don't know if this whole idea of lateral thinking is most probably familiar to you so I don't wanna, again, bore you with definitions, but something that is a really good example of what you can do to bring a really good product or really good experience out there even without inventing a single new thing in it. I think Apple is really good at it. I mean, we can argue whether that's, I mean, obviously Apple is an inventor of a great deal of new things. But when you think about that particular product, that was not new in terms of features. That was new in terms of experience. And if you think about specifically digital products, it can be websites, applications, even not even client or customer facing but internal applications or dashboards. It's not really the number of features that will define the success of that experience or the value of that experience in most cases, but it's how those experiences come or how those features come together and how they play together. So it's in line with this MVP thinking of, you're not necessarily wanna churn 100 features out to make sure that the customer's happy and pick the one that they like the most. You really need to be able to tell what is going to bring the most value to them and combine them in a, apply that combination and bring a solution out there that they will appreciate. And it doesn't have to have the most number of buttons. It doesn't have to have the most number of views. It just needs to be super simple and it needs to delight them. And if you think about your most used applications, these are applications that are just easy to use. They don't even have to be nice. They don't have to look nice. It's this misconception that good design has to be nice. Nice or something that's visually pleasing is a really subjective thing. So even if I have a discussion with any of my colleagues, we're gonna disagree on something. It's not that there's a definition of nice, but there's always, it's really easy to define what works or what doesn't work because you will have the data to support. If a button is not clicked, something wrong with either the placement of the button or the way that the button functions or the way that the button is labeled. But we try not to go for anything that's nice. And obviously, pain points can be really good source of ideas. So when you're thinking about, again, ideation, if you have a clear focus on the most important pain points for a user, then you can have very targeted ideation sessions to address that particular pain point. And it's very important that we try to treat ideation not as a precursor to anything what we do, but as one of the things that we do on a continuous basis. So when we ideate something, the best sessions and the most useful sessions are the ones that are actually, an idea is not an idea when you say it. It's an idea when you sketch it on the wall or the paper or something. And even a paper sketch can be extremely valuable to explain how an idea works. And this is something that sounds obvious. Yet, even myself, I notice every single week that this is super obvious. But at the same time, we don't do it enough. And even we can find ourselves in a situation where we're debating ideas and we're saying that that idea might work, but did you think about that? We spent probably like 15, 20, 25 minutes discussing one or two ideas, but not one of us actually take a paper out and just start catching it, sketching it. And it's actually something that we need to remind ourselves that we need to be much more hands-on and we try to do that. There's no art in ideation. So this, again, this misconception that there are the creative people who can come up with really good ideas and there are the other guys and other girls who are not really creative. That's not how it is. So if you have a really clear definition of the problem, that the definition is shared by the majority of the team, it's really important that I can define a problem in a way that I think is the best, but I sit down with someone and he's gonna have a different definition and it doesn't have to be 100% matching, but the core elements of that problem definition should be overlapping. So have a definition. Again, if we start an ideation session, we like to start by the problem definition even if we have been dealing with this problem for weeks and weeks and weeks or even months in. So it's really good to remind ourselves that this is how we define the problem today. And by the way, that definition can change. So nothing is set in stone, but we have to have a definition when we start an ideation session. Second is that that constraints, there's this really bad explanation of why you couldn't come up with a good idea is that you were too constrained. We couldn't redesign a good solution because the client was constraining us, but we couldn't really build a good product because there was a lot of, let's say legacy systems in place and those were constraints. But I mean, come on, that's the situation 101% of the time, right? The client will constrain you because they will have, in an ideal case, they will have a razor sharp focus of their business needs and it can be something super simple like they wanna shave eight Euro cents of cost on each guest's meal budget on a cruise trip. So they will have a constraint. If you're working on a larger transformation, a digital transformation project where you have a traditionally functioning organization and you want to sort of springboard them into a more digital era, then there was gonna be hundreds of constraints because the system that they're going to be using are systems that they have in place for 10, 15, 25 years. And this is not an exaggeration, that those are old systems. And you might want to build the next spaceship, but it's not gonna happen because you will have to be really incremental in what you target and what you tackle. We have endless number of debates with, so us as designers have endless number of debates with developers and with product owners as to what we should focus on in our next MVP. Obviously every once in a while, I mean, I think us as designers are trying to solve for an experience and we're trying to look for a more holistic experience overview. So instead of just trying to squeeze another feature into the application, let's try to focus on how this set of features will make the user's life better and how that will delight them. But it's not going to happen without constraints. So if we want to make sure that we can display the cabin price there in a super nice way that's really big and that gets a good feedback for the user as to should he be looking at that particular product or not? Is it his or her price range? It's gonna be probably 13 to 20 tickets in Pivotal, Track, or Agira to get to that solution because you just, I mean, you're not gonna be able to get the data live from the database and you're not gonna be able to display the way you want to. So those constraints are there and we have to accept it and we need to work in a way that we embrace those constraints instead of using them as scapegoats as to why we couldn't come up with a better idea. And the third thing with ideation is that we need to think in frameworks. So instead of thinking in standalone ideas, systems thinking is really important. And as much as it is true with your line of work, it's very similar to us designers. So instead of trying to focus on how the mobile view will be beautiful and responsive and very nicely laid out of one stage of the 25 stage customer journey, we need to think in larger systems. So we shouldn't be focusing on one specific thing above all. We need to be focused and we need to embrace system thinking. And that's also something that you probably heard 100 times, but it's just true. So many, many times the problems that the customers or the business will tell you that they have are not the problems that they have. So they might think that the website is not performing well because they think that the customers are not spending enough time per visit on the site. And if you really go deep down, you realize that that's just not important because increasing time spent on a page from one minute 35 seconds to one minute 42 seconds is not gonna give you any value if they will not be converted and go towards booking or go towards purchase or go towards something that's the next step of engagement. So it's really important that while we need to be focused with understanding the problem, ideating in a focused way, we also need to keep our distance as much as possible so that we can really recognize those situations when the problem is not the problem. So iteration, I don't really think that there's anyone in the room who doesn't know 100% what iteration is. I think it's more like, how do we perceive iteration and how do we make it happen? Again, if you wanna put an equation or let's say a definition as to what is innovation, then you have invention plus implementation is innovation and that implementation is the number of iterations that we have. The way we work with an MDL is that we try to be as quick and dirty as possible and as hands-on as possible. This is actually personally find is the hardest of, or one of the hardest things of all because our clients are expecting shiny functioning mind-blowing spaceships most of the time but many times an idea or a problem can be best explained if you just take a paper and just sketch it but many times you cannot just take a sketch to a client, right? I mean, they're gonna say this is what you've been working on in the past nine days. So you cannot do that. So we need to keep that iteration that iterative mindset functioning in a way that we do get hands-on and then we do show progress and that progress that's being shown can be used to fuel further iteration. So obviously in the beginning, the fidelity of the design, if you're talking about design, I mean, I think in this context we're pretty much talking about, let's say customer journey, user journey. So UX, UI, even maybe something that's tangible visual design. So obviously in the beginning, it starts low. Low-fi is where you can achieve the have really rapid discussions about either the overall journey or just specific features. It's really important that whenever we start a project, it can be a three-week project or it can be an 18-month project. We establish a cadence of delivery quite early on. So we do set this cadence within the team, not just within us designers, but also designers, developers, product owners, even project managers, and also try to make sure that this cadence of delivery is visible to the business or visible to our clients as well. So the best prototypes in my or our opinion are the ones that you can just throw away. So they don't take too much time to build. And even the build is quite a subjective term. So we can build staggering prototypes with just pen and paper, and we can sketch and we can glue, and they're gonna work fine. There's gonna come a time when you really wanna make them interactive and clickable, but even when you're making it clickable, there's so much time that you can shave over just by not doing the unnecessary things. So again, if we have a clear focus as to what we're trying to achieve in that particular stage of the project, then we don't have to build a prototype in three, four days. We can really do something in two, three hours. And if that is going to get us closer to test a certain aspect of a journey or solution, that's fine. It doesn't have to be nice. It shouldn't take up the majority of the team's time because the higher the fidelity of the prototype, obviously the more resources it will consume to make. And if that stage will turn out that you will need to ditch it or you will need to do something else instead of it. And I mean, let's admit it in most cases in the early stages of the project, both prototypes are gonna be junked and started all over again. So it makes no sense to go for high fidelity in the beginning. So in terms of testing, testing is something that we like to do on a continuous basis, meaning that even if we have a user testing session, it is no longer than 10 minutes a week. One example is that we're working with a client now and one of the deliveries is a management reporting tool. We can call it a dashboard. So the business is looking at numbers and figures from different verticals of the business. And it's a very complex business. It's a global business. It's a very high operation or operative cost business. And on top of this, the business has, or the company has really, really old legacy systems in place. So it's not that we design in ice interface and you just get data and it's there and it's gonna win awards. It's a really meticulous work of how do you actually show eight KPIs? But the prime, let's say, uses for this particular tool is going to be 10 or 15 executive management members of that company. And five or 10 minutes with these people, men and women, on a weekly basis is super, super valuable. I'm not exaggerating, five minutes. So we actually have, I think, cadence of meeting after lunch every Thursday with three or four people within the organization and another three, four, I think on Tuesdays and five to 10 minutes and we can test whole user flows and we can also test specific functions of how do we visualize a certain set of data. So it's 10 minutes, essentially a week. So formal, informal testing. It's really important that we also, when we talk about process, we are establishing patterns and we are doing this in a way that is not just us designers doing this, but the whole team. So what are we doing? Why are we doing it? And how does success look like? And revisit these along the way as we go along in the project. So the outcome of this is pretty much a design brief. I think design brief is actually not the best word because then a developer might say that well, it's a design brief. So I'm not supposed to be involved in that because that's the designers thing. The way we try to take down this barrier is we hold weekly, let's say, design reviews or design sessions where we don't talk super detailed design. We talk about what we need to achieve in that particular week or two weeks time span in terms of design delivery, but it's not specifically visual design, but more like designing the customer journey. And this session is specifically targeted, not an us designer discussing how one or other feature will work. But if we are trying to solve for this particular UI issue, are we going to get data through microservices? So it's really, really interdisciplinary discussions. And the base of that is always a weekly brief as to what we're doing and what we need to do next week. Yeah. So this is obviously shared, discussed, and it's really important that it's not something that's documented and done, but it's something that's a living document. So our design brief is never finished. In most cases, it's not written anywhere except for a board in the room. So the space that we have in our current project in Hamburg, we have one wide board which is specifically taking up the space for this design brief. And this is the only place where you can find design brief. We don't open a ticket for it. We don't share the document. We're not creating PowerPoint decks. We're not making it look pretty. It's just on the wall. And if you need to iterate tonight, you go up, you wipe something off and you write something there. I think that I've discussed this earlier. So when we're thinking of gathering information as to what the competition does out there, it's really important to have this focus mindset of not just doing your own competitors, but also try to look out for what the other guys are doing. Again, an example, the travel client that we're working with now is developing a number of products. Some of these products are quite simple. Other parts or other, let's say parts or stages of this journey are quite dense in content. So for example, a daily itinerary ticket, the way that they would imagine or the day that they would have designed based on the content that they want to highlight is just not going to fly on a mobile. It's just the content is so much that it's no matter how you squeeze it, no matter how you truncate the content, no matter how you paginate it, no matter how you try to be really fleshed with typography, it's not gonna work. But the only way to do is to do something that's more out of the box for them. I don't really like the term, but it works now in this particular context. And we actually looked at Tinder, looked at Pinterest, looked at many of these ticket-based interfaces. And we're actually testing a very much a Tinder-like interface where customers can look at specific promotions, just an overview of a promotion. They cannot actually click and go to a detailed page because that would defeat the purpose. The idea is that we want them to go through a number of promotions super fast. So left and right piping, it's something that we're testing. I'm not sure it's gonna work, but this is definitely something that was worth a few days of building a prototype and testing it with user. And it would have never come if we only look at, let's say how Booking.com operates or how Kayak.com operates or how any of the, let's say, the airline websites operate. And it's really important that don't just look at it from a visual standpoint. So don't just say that Tinder swiping cards are cool or I like how Facebook does this and that because that's really subjective and it's not really qualitative. So whenever we look at competitors or comparative examples, we always try to look for what works best, what doesn't work, and what is a specific learning from that example. And we try to articulate throughout the team because this is where the learning comes for us. So if two or three of our designers look at a specific solution at a different industry and we say this could work because we could make it work on a UI level, we didn't do anything, we didn't uncover anything. But if we share this finding with someone who's responsible for data or someone responsible for microservices, then we can actually relate that specific solution to our problem and we can say if that's really gonna be a solution process or not. So it's really important that we have these lunch and lunch sessions as well. The idea for today would be that you'll be doing some of the work that normally a design team would do. No coding, no computers needed. We will try to use three different sheets of paper, very sophisticated tools. And you'll be immersing yourself and you'll be stepping into the shoes of your customers, your imaginary customers. You will, the task or the idea is that if we were to build a product for any traveling industry player, let's say here in India, then how would you go about it? This is really broad. We're not gonna solve a whole lot of issues. The idea is not to come up with the best solution, the idea is just to get a little glimpses to how we work and the idea is that you will work in pairs and this is where the workshop starts. So I have four exercises in mind. One is discuss competitive and compare the products within the traveling industry. The second is create user personas or a user persona that you would think would be the best to design or build a solution for. The third would be to draft an empathy map. We'll discuss this in a little bit more detail soon. And the fourth is to just sketch out a possible user journey. So let's say that because you will be working in pairs, one of you can take up train, one of you can take a bus, the other one can take up fly booking, doesn't really matter because you'll be working in pairs and the idea is that the two of you are gonna be working on it, have an ongoing discussion. But let's say that we're building an application for Air India. Look at other airline applications, not necessarily just in India, not just in the region but anywhere in the world, but also look at not just airline apps, but other apps that might be relevant to us. Create a user persona who might be your ideal customer. So you might want to build a fly booking aggregator application specifically targeted for low budget travelers. We'll go for the other end of the spectrum, specifically targeted for the high intensity business traveler. Who's that person? And how does the empathy map of that person look like? What are his or her wants or needs? What they want to achieve and how can they do that? And then how does his or her journey look like? So what would be the, let's say four or five points that you would want to design for because you will not be able to design for 20, 30 different points. So the idea is that you will be working in pairs. My idea was that for each of these four tasks, 15 to 25 minutes should be enough if you're working in pairs. And then it's really important not to focus on getting the best solution or the best idea because it's not gonna come. That's on the point. The point is to have an idea as to how you can understand your users better and just to have a taste or a teaser as to how we usually work when we are at this stage of the project. But before I would go into any details, I really want you to tell me this is too slow, too fast, or if you have any questions or if something is not clear or if in fact this is so boring because you've gone all this all along and you're just being really polite by saying, this is the point where you need to say something. Okay, task number one would be to gather and collate competitive and comparative product. So again, the way we usually do is we look at competitors, look at competitors who might be having a very similar product to what we want to build. But we can also look at competitors who don't have that particular product. So we can, if you wanna build an application for let's say this airline aggregator for business travelers, use that as an example. A train company or any other travel industry player is still a competitor in that sense. But you can also use, you can also look at aggregator sites such as Airbnb. So the way that Airbnb engages with their customers and the way that they offer the different, let's say, well, the way that they connect travelers with hosts, even though that's a different business model than what an airline would have, the way that that connection is taking place is very relevant to us because they are using really tiny innovations to engage the users more. So I'm not sure if I have internet because it was just an hour ago, but how many of you have used Airbnb before? So, but I assume most of you know Airbnb, right? So if you think about it, when you go to the landing page, the main page of Airbnb, something very simple happens. There's a massive image on the top and on that you have a search field and the search field says where to, dates, a number of people. It's not an image, that's a muted loop five second video that's behind the search field. And the reason for that is because they want to, they want to make sure that the customer can imagine him or herself and any particular location or destination that they can travel to with Airbnb. And if you just use a static image, that's just an image, it's not really gonna, it's just a bad stuff for them. So what they've done is Airbnb went all around the world. They went to I think hundreds of posts or even more and they've recorded these really short snippets of like five second video or really mundane things. Like there's a guy in a kitchen pouring coffee and sitting down on the desk and just taking a seat. It might sound like super unimportant detail but it's not because when you go to the side you can imagine yourself being there at that desk and actually having coffee. Whereas if you just show them, show your users a stock photo of two smiling people it's not gonna have the same effect. And that thing came out through research of what customers are lacking or were lacking let's say distrust, not trusting enough with the earlier versions of Airbnb. So these are one things, one thing. The other thing is Airbnb has a very specific photography guide that it lends to hosts. So there's a very specific way that Airbnb allows you or actually prompts you to take photographs of your property. And there's a reason for that because there's science into how you frame a picture. And if you put a back picture there, it's very simple. You're not gonna get conversion. People don't wanna stay in places that are not really to their liking. So the better pictures you have, the better engagement, the better conversion rates have. You have the more money you make, the more money Airbnb makes. But this thing, I think took almost a year and a half to Airbnb to figure out. And then the way that they've done it is that they've done a test. So they went to New York, I think at the end of their first year and themselves, through the founders, actually took pictures of the hosts that they visited. And then they put those pictures up on the side and then they've seen that the engagement rate went up. And that's where they were thinking, that's where they started thinking, okay, so that's the case. We need to scale this up and make sure that there's a pattern that the hosts can follow. So I don't wanna drive the example too long, but Airbnb is one example that if you look at it, there's a number of small things that can make an average traveler more engaged. So even if you take a different kind of traveler, you can still learn from what Airbnb did. So the first 15, 25 minutes, the idea would be that first you find yourself a pair. If you wanna work in threes, it's also fine, but I think the smaller the team, the better, more engaging discussions you have. Also the space is quite limited, so I think it's easy if you don't have to move around. And just try to think of, first define the problem that you wanna solve for, define the business that you want to be in. So pick airplane, pick train, pick ship, pick bus, whatever, but try to figure out what you wanna work within the next hour. And then try to discuss examples that might be relevant. What I've done to help you a little bit is I've looked at Air India, the website, not the website, I'm sorry, the mobile application, I tried to book a ticket from, I came from Budapest, I live in Budapest, and I tried to book a ticket from Budapest to Bangalore. It's not happening for a number of reasons. Air India doesn't have a flight to Budapest. In fact, Air India only has co-chair flights even to Germany where I came through. But tiny details, if I type in Budapest at the search field here, it doesn't give me anything. It doesn't say that there's no such location or no such destination. It doesn't say that I mistyped it. It doesn't say anything. So I can think that the server's down, I'm stupid, the application doesn't work, or they, in fact, don't have a plane there. But by the way, Air India is part of Star Alliance. So I can get from Bangalore to Budapest super easy. And actually that's what Luthansa does. So if I use the Luthansa app and type in Budapest, Bangalore, back and forth, and they're gonna give me like seven or eight different flight options, not all of them are Luthansa options, by the way. So I can, I even have jet airways and I even have Air India flights. The only difference is that within their database they have their partner lines as well. While the database behind this application only has Air India, I think there's lost business, right? So it's not really smart. So you can think of those, when you're actually looking or discussing an application, you can think of those larger scale issues or challenges, but you can think in usually small things. So when we do diagnostics, UX or UI diagnostics, we usually try to look, I try to see at specific user journeys, let's say book a flight or find a flight or compare prices and try to see how easy is that for the user. So if finding a flight, actually if for me getting a flight, booking a flight takes, I think it was like 11 steps, not counting the fact that if I'm not a frequent traveler I'm gonna stock at step number two or three. Whereas the same thing can be achieved through Swiss Air or Luthanzer in seven. So I'm not saying that whoever is using Air India application will immediately use Swiss or Luthanzer app, but I'm saying that there's an issue that you could improve. So usually what we do is we look at things that the app does good and look at things that they could or could or should improve. And that's one way of doing it. And the other thing that I've done for this first exercise is just to give you some idea. So I would look at Swiss or maybe Luthanzer. I would look at Virgin America or Virgin Atlantic. I would probably look at Momondo. Have you know, do you know Momondo? Is it, is also a travel aggregator site like booking.com or kayak.com. Their application is very smart. It's recommendation system and it's really intuitive. So it doesn't let me get lost. And I would look at Tinder, because why not? Maybe you'll find something there that might be relevant to the way that you wanna, you know, have your customers book fights. So the first exercise would be that the next, let's say 15, 20 minutes, you find a pair and then you start discussing certain applications and you try to just note down what will work, what not. You, because there's quite a many of you, we shouldn't like, we don't, I don't want us all to report back and have like a discussion. But I think at the end of each of these four tasks, it would be nice to discuss some of the things that you've discovered and to share back to the group so that it becomes like a group learning as well. And then my idea is that in all the while I'll be walking around and just listening and just happy to answer any questions or push it. Does this sound something that is doable or exciting or worth doing? All right. So find your pairs and pick an industry or pick an industry within travel. I guess it's time to sort of feedback. I heard some very interesting questions and some very good ideas. I think what we should do is, I have two or three questions that I was asked. I wanna quickly reply to them in a way that all of you hear because you might find relevant as well. And then it would be nice to have two or three teams to quickly report back and just present like in two minutes of what they were thinking, what they were looking at. One of the things that was asked is, how do we define what comparators are we looking at? And that's a good question because if you're not looking at competition but you're looking at other players in the market, how do you define which are the ones that are relevant for you? So one of the things can be, is to look at your target user or your user persona and based on that, try to figure out other things that he or she might be doing and go after those applications or those services because then they are designed for the same mindset as you are designing for. Different scenario and differently but same mindset. Or go the other way around, forget about your user persona but go for a similar product or similar offering even if it's for a completely different audience. So in case of, let's say, travel, you're looking at, if you're designing for a plain booking where you can look at Hoto or you can look at Airbnb. If you're looking at, let's say, e-banking or mobile banking, then you can also look at social applications or you can look at things like Tinder because if you wanna engage a younger audience to sign up and start using mobile banking more frequently, you can find ways to sort of trigger them and push them in the right direction. And there was another question which is, was another question which was about how, yeah, social media. So quite many of, I'm sorry, not social media. I'm mixing the two questions, sorry. So there was a question about what features should be high priority for our user later on and are those features present in these applications? And the other one is social media, something that's relevant. So the question was not that but this is how I do it. And I think that it's really important to know your persona. So the second exercise is gonna be not to work on your persona. Once you know who you're designing for and in what category, it's going to be much easier to figure out certain priorities in the features that you really wanna base your application or base your offer. What would be nice if we'd have at least two teams to share a little bit of what they were doing? We'll be the first one. So the question is that, wants to say that a lot of people want to book tickets and that's why people have logins right in the first screen of IOS UTC. And we have a different idea about it. We think that because there is login in the first, very first screen, people who don't understand all these concepts of login and why it is actually required. Because we are from a computer background, we understand that, okay, there has to be a login to do something. So people actually don't book them. They go to agents and they go to people who can book tickets for you. So since we want legitimate people to actually go and book the tickets, then this kind of information should be available without the logins. Yes, so just before the book ends. Let's see, let's see. There are different websites, but you can go and see that. So why? Yeah. With the microphone? I think Amazon has quite a nice solution for this thing, which is where if you go to the Amazon website and you look at product, that gets stored, you've got a tracking cookie with you on your machine and it's there in your history. And you come back, it's there still. They're tracking you all the time. If you click on something and you put it in your shopping cart and then you go away and you come back a week later, it's still in your shopping cart. They try and track you really, really heavily. And then if you're using two or three different computers and you've got stuff in your shopping cart on one computer and you log in and then you go to another computer and there's stuff in your shopping cart and you log in, it just merges it all together. It just, it has as many things as it can get so it can hold on to you. And if you're going and you go to the website and you look at train ticket, know about it and then get the log in. Sir, I'm going to cut you off just for the sake of logistics. So I think this is also a really good point. I think we shouldn't discuss features just yet. So if you remember, the first thing was to look at comparative and competitive products. And it's really good that you went to head and you'll have a chance to sort of discuss those features in the next stage. Anyone wants to share about, okay, I'll go with the lady and then you and then. Hi all, myself, Harshita. G1 here. It is Narayan. Actually, we have trying to develop a new app which is called Najeha Travels, which means? It's Najeha, no, G is with respect whenever you call an elder person or something and ha means yes. So it's called a travel and the target audience is Indian. After reading Indian minds, we came up with general travel solutions which cater to all kind of customers. May it be travelers who are just bachelors and just want to travel to go or they want to have an animal package or they are into the business class, they want to travel for business. So those are the target audience. And the competitors are TripAdvisor, Go Ibigo, Clear Trip and Make My Trip. So what does this do? What is our setting point is we are just giving advices. We are not setting anything. Mindful of the time. So let's not go there, let's not go into the details of what your proposition is. I think actually that one sentence of what you said is about you're going after this in this segment is good enough. What would be really interesting to see is which competitors or comparative examples you've looked at for this course. Yeah, so TripAdvisor, Go Ibigo, Clear Trip, Make My Trip are the competitors. So what we do is just advise them what is better for them without actually selling them so that customers come in because in India, wherever we see free, we go there. So that is one plus advising thing that we are selling. It's not an Indian thing, I can attest to that. Yeah, so Indian rule the market of the world. So I think Indian target should be... Rest of my case. I'm from the country of 10 million, so I'm... Okay, let's get this one. A little bit of different touch, but mostly in the same line. So as the problem is described, people want to have a travel. People want to actually go travel for more than a day. And there are competitors like Go Ibigo and Make My Trip, as they mentioned, and Yatra, who have actually these packages, right? And these are like pre-configured these packages. And then there are competitors like Thorellophilia, who actually, they organize office events and they are customized packages based on the preferences of the companies. And of course they can also go for more than a day. So our solution was towards like make... Coming, so given our origin, given your destination, we should approach, let's say, three vendors who will customize the travel deal packages for the customer. And people can choose to actually go for either of them. So there is a human touch involved in this. So that's the thing that I think that the era of pre-configured travel deals should go away as soon as possible. And there has to be a human touch that should be involved in this kind of deals because... Something that is written on the webpage, like... So most of the time it happens. Most of the time it happens. Make My Trip will book your hotel and the booking is gone for a toss when you actually arrive to that hotel. And the prices are changing for airlines every day in India, right? So yeah, so that's our kind of thinking behind it. So what I would like to push you now is to go to the next stage and start working on user persona. So a little bit about this in detail. So basically a user persona is not a list of demographics or specifics that any user can have. It's an archetype of your most typical user. And you can actually have different user personas. So your offering can appeal to different people, different kinds of people. And you can have persona ABC or more like persona like Joanna, Jack and whatever. It's really important that your persona is a result of a collation of different insights and different interviews from different people. So it's the best archetype that you can find to represent the person that you want to design for. And it's really important that it's different from... So I'll give you an example, right? So this was actually a persona that we did for a workshop a month ago. Her name would be Joanna. That exercise was a mobile account management application. So she manages the phone bill for her family of four. She's somewhat tech savvy. She pays many of her other bills online. She's married, obviously. Her current behavior calls about updates to the bill, keeps paper coupons of deals or savings promotions that she can apply to her account. So she has, obviously she has some specifics like background. She has behavior, very important. So it's not how much she is or how much she earns. That's also important. But it's what does she do? What are her goals that she needs to achieve? And what are her frustrations? So in the case of this lady, frustration was that there was no way to track family usage. And there was no way to, let's say, distributing a data package throughout the family. So if the little kid uses more data and the farther less, why cannot they even it out? That was one of the frustrations. I think for us, if you're gonna go for travel and you're gonna go, some of you will go for the high-end business traveler, there's gonna be quite a lot of frustrations that you've already highlighted. Like if I'm a regular traveler, I don't really wanna spend two hours every week to figure out my travel. I wanna have the one-stop solution. I give you a date, a date of departure and arrival. I give you two or three locations. And I want you to sort out everything. Maybe that's one of the things, right? So you should sort out driver, hotel, flight, everything. I'm not saying that should be the solution. I'm saying that can be the solution. So basically, how a user persona is made is that we take research material that in best case scenario, we create or we gather and build it up into a persona in a way that we try to look for patterns. So we talk to different people. We look for very specific behavior insights. So instead of saying that I'm not happy with the service provider, it's not really specific, I'm not happy with the service provider. And by the way, I'm not sure it's that important, but the bill is really hard to read and it's not really clear how that final amount was calculated. That's your core issue. That's the thing that you need to solve for it. Because her frustration, the reason why she says that she hates that provider is because she cannot have a clear overview of her monthly phone bill. That means that monthly phone bill is one of the biggest frustrations that she will have. So there's a number of things immediately that you can do. You can obviously redesign the bill in this paper form. You can make the bill available online. You can maybe introduce a feature that will allow you to at any given time, with let's say 24 or 40-hour delay, you can have an updated overview of your current spending. So there's a number of ways, but that will only come out if you know what the specific problem of that person is. So, and the reason why it's used is because it's much easier to relate a certain solution or even a journey or a set of solutions to these personas than to just people. So if you say that that person, she has a name, she lives there, she travels this many times a week. She has these specific frustrations. She works at this position and this is what she likes to spend her time with. It's easier to see how your solution is going to work for them and it's also much easier to find research and testing, people for research and testing, right? So again, if my character persona is just a bunch of demographics, Urban lives in Shanghai between 20 and 30, earns 17,000 a month, uses a smartphone, whatever. That's not really useful because you're gonna have one third of Shanghai lining up for your interviews. What you really want to have is you wanna have these behavioral, qualitative little insights and based on that you can actually find really good people to interview, like really people with specific problems. And then when you're gonna take a prototype to these people, then they will actually relate to your problem much better than if you're just looking for them to work. So usually what happens is, there's a number of tools that we use when we're working with user personas. One is an empathy map. This is usually what we start with. The empathy map has six sections. It basically functions so that you can actually have an overview of how to empathize with your persona, with that particular user. So you have think and feel. So what do you want them to think and feel? What do you want them to say and do? What do you hear from them? Oh, I'm sorry, what are they here and what do they see? What are their main pain points and what are their main gains as they go through your customer journey? And usually what happens is in the early stage you're figuring out who your persona is. You create these different maps, following different interviews, many interviews and then you collate them. So then you're looking for patterns. So if there's only one person saying that the bill is arriving late every month in the post, it's probably not an issue. Three, four people out of three, four people saying that it's probably an issue. So you're not just looking for quantitative patterns, you're also looking for qualitative patterns. So if there are certain interactions with your service or your company or your product, which many users find treacherous or painful, then you wanna investigate those issues in a bit more detail. And so what we do usually is we create these maps, then we collate them and then we look for patterns and then we have a empathy map. And then yes, so basically two and three. So this is what we do and then based on these or with these we also work with the personas. So it's, we also have something called the persona sheet, which is pretty much a, it's like a data, it's like a table of the different characteristics of that person, but it's not as important as the empathy map. I think the empathy map is much, it's a better tool of really figuring out how you should find your message on the map. So the next exercise would be that you also spend a little time on, I mean by now you know who you wanna build, roughly what kind of service. The next step should be that you start working on this persona. We have, so we check it out. You would, that's only one to each sheet, not necessarily one to every one of you, one to each sheet. Then you have a persona worksheet that you can maybe fill out and just make it more lifelike or realistic with a persona. And on the second page you'll find the empathy map. And then you can start working like, usually what happens is that actually the empathy maps are really big printouts, actually like big ones of these. And then a group of four, five, six of us gather and then we use post-its. And then we somehow try to, you know, use color coded post-its and then we you can find those types of things easier. So again, logistics, I know, as the time goes on, now each of you can have one and you can try to. So same drill, let's try to see if we can come up with something very insightful in 15, 20 minutes and then we pull back the team. Any questions regarding this particular exercise? Have any one of you done this before or is something similar? Sorry? How do I know who to do? That's a good question. Usually what happens is when you're working with a client and they have rough ideas to who their target audience is, then you will have an idea as to roughly what's that kind of people, what kind of people you're going at. And in practice the way it works is that you usually commission research companies and then you give them a very specific, very specific, let's say probably this, it's a personal sheet with demographics and some behavioral insights. They line up a number of people, much more than you need and then you go and talk to each of them and you actually, you know, some of them, you know, shortly is done. And then you try to look for, if the demographics is not 100% defeating, it's not an issue. What you're really trying to go after is qualitative, qualitative behavioral insights. So you wanna talk to the people and keep talking to the people who have a really good story about a booking that went really bad, about a train, a plane trip that was, I don't know, misbooked about a hotel experience that was really bad or really good. But you can also go for the good stuff, not just the bad stuff. But you wanna go for these quality stories and then you probably end up, I mean, for example, for our project in Shanghai now, we had probably 20 people out of which we kept, I think, nine or 10. And we kept interviewing them for six, five weeks. You can find these people by randomly go to the street or the airport, but you can also, again, commission a research company and then say that, you know, they should find you people. And then, depending, like, if it's a service, it's targeted for 20-some things, urban area, then you'll probably go for the universities and the places that they hang out. And by the way, one of the best customer or user testing sessions we had, I think two weeks ago, was in a shopping mall in front of a travel agent in Hamburg. We went there, we took a very simple typical prototype on iPad, and we swayed the people to go in and come out. And the people who actually went in and spent a little bit more time and maybe engaging with the travel agent, those are the ones they went to go to. People's like now are going to go. So you can be really creative in that. If you know roughly who you're going after, you can really find those people. The questions that I received repeatedly was, how do we use the map? So we use the map in a way that you engage with your customers, you conduct interviews and you represent the stories that you hear from your customers on this map. So it's very important that this map is prepared from the perspective of your users. They can be future users or they can be existing users. So they can be people who already use your product or people who want to use your product. But it's very important that it's things that they think and feel, they hear and see, they sign and do, and it's their pains and their gains. And it's one, maybe an easier way to understand how the map works is you can think about the hope triangle, think and feel, pretty much about them. It's one, they think and feel about you going through your journey. So it's more like perception, right? Then hear and see, it's things that they hear and see through experience in your product or service. So that's actually experience. So that's the thing that they hear and see as they go through your website, as they go to your travel agent, as they go into your physical store. And the last one, say, the bottom triangle, the say and do, that's actually something that is more like, that's their opinion but informed by their experience. So you can think about it in a way like perception, experience, opinion. And this is a specific pain to gain, specific constraints, frustrations as the athletes and athletes that they really specifically told you. And usually the way that we do it is that I was asked how do we make sure that when we get the right interview candidates? So I can give you a recent example too. We're working for this cruise company in Germany and in China as well. In Germany we do regular user testing sessions. So what we've done, I think two weeks or 10 days ago is we went to a shopping mall that had a very popular travel agent and we know that they sell cruises as well. So we spent about 15, 20 minutes outside the travel agent and just looked at people who went in and actually engaged with one of the workers in the travel agency. And as they were coming out, we engaged them and tried to spend like five or 10 minutes, actually less than 10 minutes with them. We had two applicable prototypes for the same journey, we wanted to test something and just wanted to get their ideas. So we wanted to do things, get specific qualitative features but also get an idea as to what the building is that relevant to them. And we actually, the cost of acquiring those test users was basically us spending 20 minutes in front of a shopping mall. On the other hand, in China about a month and a half ago, we were doing a slightly larger, the smaller project but it was a different setup. So we needed to understand really quickly how our typical Chinese customers are engaging with us and what is important for them when they travel with us. So we had segmentation information from the client. So this is our primary customer, secondary customer. We gave that brief to a research agency and that research agency brought us candidates. I think they brought us like 20 or 25 candidates. We had a session with each of them. So we had positive data from them. How old are they? How much they are and where do they live? Have they been on a cruise? And if they have been on a cruise, were they booking and did they book it at a travel agent or online? So we knew all this before we actually met them. And then we met them and then we really quickly feel through the ones that we thought were more valuable. And the way to do that is you're looking for specific experiences that they can tell you as a story. So one of the mom was telling us that she, like her biggest fear when booking a cruise is that she wants to make sure that if they go away for a holiday for let's say 10 days, she can also relax because as a mom, what you will do is you want to make sure that your husband is all set, your two kids are all set. But if you do that and you're not really relaxed throughout the holiday, then you will actually feel like it's worth it. This kind of story is very valuable. It's full of insights, it's full of your own little tidbits that it wouldn't come out unless you actually talk with it. So what usually happens is that we create these maps and after we've done them, we're looking for patterns, we're correlating them and looking for these points where many different segments maybe have similar experiences. So we go for the zones that are very articulate and we also try to look at the extremes. So we look at a few of the extreme examples and extreme stories that we're trying to see which one is wrong. And the next step would be something that we might have time points to make but it's not a deal for a lot of people who have a hard time seeing it in there and also, unfortunately, there just aren't two of them. But usually the third or the fourth thing that we try to find, but as early as possible in the process is it's a customer journey map. I'm pretty sure that most of you have heard about it so it's not going to be a deal. But any little bit of information about how we do it. So a journey map is pretty much, you have a persona, you have some sort of feedback as to what the biggest pain points are. And the customer journey map is basically a tracking of the journey. Very important, it's not a touch point analysis, it's not a process map. So we don't have to indicate every single detail on it to make it valuable. It becomes valuable if you see one of the main barriers of the main obstacles and the behavior of the move. So this is a really typical customer journey for our previous workshop. So we can't say personally that we just started Johanna. This is about a mobile phone subscription. So she was on something so in the beginning she's super happy, right? She got the package, she got the video. I think it's a family video so she can link up every one of the family. Well, that was the first part of the deal and she already gets this point. Something is not clear to see as she would expect. So what happens is that when we take a look at the empathy maps and we have those specific pain points and even the high points, when we try to represent this on a map, we do this in a way that this is the beginning of the journey, this is the possible end of the journey. And what we do is in each of these stages, it's not specific steps. Because if they would be specific steps, they would be a very granular map. It would be really big and lots of information. They want to make it informative. So we have stages and we try to highlight the most important part of the journey that we alter the state of mind of that customer so that we know what we need to examine it. And by the way, usually it's an aspect of the thought in a way that we approach it from, we always want to approach it from the user's perspective, but you can find it in a way that it's based on a customer life cycle. So customers are unaware of the service, customer use value, customer considers, customer affairs, customer purchases, customer orders, on-going units. And then maybe it's 20 years, she's coming here, she's not here. So you have all this, since you've satisfied another layer of it, does it make any sense? Yes, thank you. So the way that we treat these maps, there are by the way many visual representations for us. It's the one where you have, consideration, evaluation, but the way we treat this throughout the project is that we try to set the person on the user's perspective and keep the data in the team code and make sure that it's accessible to anyone. If, as we go on and conduct these interviews, we try to update it if it's relevant. And also we're convenient changing it as well, right? So this is not something that is set in stone. So we can actually figure out that maybe after week three, we thought that these two were the biggest pain points and so forth. But as we go on the project, as we test the users and engage with many users and other interviews, we realize that these are important. So they can be very, not flexible to the extent that you can change them every day, but again, the point is with much of the things that we discussed before is that, as long as there's a team discussion around what to focus on, it's specific, as long as everyone in the team from product owner to developer, from the second designer understands why and what is in this new building, it's good, even if you change a few things. Probably start to arise when there's not enough transparency and maybe all part of it is not to be aware of what's being built. But usually these exercises also, this for example, it takes not too much time. We can spend maybe three hours, perhaps something very detailed like this. And we also like to do it in a way that even before having very tangible, very specific information about our users who like to do maps, because a map already gives us an information, we've got a lot of information about how a user journey looks like. And what can be the most critical of points. Some of that will turn out to be small, but it's fine because again, it's not that it's very early to start, it may or may not even get there. We're finding as fast as I think if you have some questions, one, I think, you still have some time that isn't even in this session, I think that's when you hear questions. What's the entire time you play for this? I'm a doctor, I just play with the entire personal knowledge and stuff. So it's not extremely linear, it's not like we cannot start one or two and finish the other, it's these things we really have at the same time. I personally like, yeah. Can you help the mic? Yeah, yeah, better, sorry. So I personally like to start every project by doing these, even if I don't have all the information. And what we've just done is an ongoing activity. So you revisit the customer journey, you definitely revisit empathy map in person or not that much. But the thing that we did first, for example, looking at competitors and comparators, actually you revisit that as well because as your product evolves, there's gonna be other features that you wanna get in and another example, for example, is online payment. So this client that we're working for now is, you know, we're looking for different payment modules and we thought we had one, turned out that there's some very complex legal and technical issue with it. So we have to look for something else and then we went to Stripe. I'm pretty sure that most of you know Stripe, the online payment solution. It's like basically a two-click solution and you don't have to have very complex, actually you hardly have to have any integration in the backend. It's a more expensive solution, but that's a good short term solve. But that changed a major part of that stage in the UI. So the moment we had to go with Stripe, we had to revisit some of that things and we had to look for other examples out there which were not closely related to the travel industry. Yeah, but so, these can happen in a week. If you have good information from the business or the client and you have a good team of three, four people, then very valuable work can be done in week one or week zero, depends on how the project is set up. Sorry. There's no recipe for that. So there's one schooling that's gonna say, well, you shouldn't involve the developer here because time is much more valuable. And maybe the input is just not there. I don't believe that. I think that it's quite nice to have different perspectives because when you do these things, the role is done that usually a designer or a researcher or a design lead is playing the facilitator role. So maybe I could play that role, but in the team you have different people. And whether you're a developer, product owner, project manager, someone from the business or a designer, as long as you contribute, there's no right or wrong contribution. One thing though is as you go deeper into the journey and maybe you revisit for the second or third time, you wanna have more and more developer involvement because as you wanna tweak the set of features and as you wanna tweak the journey, there's gonna be a number of dependencies and impediments that unless you are aware about, you will not be able to have a good idea about those. So how does one decide the interface of any solution that is like if you are thinking of any problem statement and you make a solution out of it, how does one determine the interface? How does one determine the interface? The question is how does one determine the interface based on these? Well, the good thing is there's no one person who determines the interface. That's the good news because then it wouldn't be a teamwork. The way usually it works is that once you figure out what you wanna do, you're asking a very specific question in terms of design. So a number of things that influence or inform a design direction. So that's what we're talking about. So it will probably be what you wanna do is you wanna look at the context and what the user wants to achieve in that particular part of a journey. So if it's booking, if it's let's say a conversion, it's a conversion focused journey, then obviously you wanna make sure that the conversion, the trigger to the conversion or the call to action to the conversion, let's say a button that says buy or book is visible or is it the right place at the right time? So instead of, I'll rephrase, if that's Amazon, I mean, you look at the Amazon side, it's not, you wouldn't call it a nice side, right? It's a very smart side because whatever you need is always there. If you look at something, it remembers, if you wanna buy it, it's really easy to buy. If you have an account, it's literally one or two clicks, but that's an easy, it's like a lower engagement product. If you're buying something like a business class airplane ticket or you're buying something like a family holiday or even a cruise for like 1,500 euros, that's a product that you will not decide on the spot. So our client, for example, tells us that an average customer can visit the site 27, 29 times before he or she makes a booking and that 27 visits can happen in the span of three, four weeks or five, six months, depending on what is it that he or she is actually looking for. If he's looking for a good deal now for next fall, you'll definitely start looking at it. Now maybe book in February, but in the latter case, like having a visible book button will not increase the chance of booking because you'll still have to dish out 1,500 euros, which is not like buying a book on Amazon. So the rules of the game are a little bit different because what you wanna do is you wanna gradually draw the customer in. You wanna inspire them, you wanna make sure that whenever they have a question or whenever they wanna compare maybe two cruises or two tickets or two high days, then they can easily do it with a click. And then once, like as you get closer to conversion, you need to make it easy and you need to make the barrier easy, right? So you shouldn't, for example, in the case of a cruise or a high day, you shouldn't start with saying, what's your date of birth? Like, yeah, like if I want a book, I'll tell you my date of birth, otherwise why? So that gets back to like, there's no one thing that determines the interface. It's more like what do we want the customer to be able to achieve? And what's the most efficient way? And then you can tweak it and if you have a very, if you have a very dominant brand identity, which some companies do, some companies don't, like let's say Nike does. So a Nike site is very much influenced by Nike and it's very content heavy and it's a good site, whereas other sites might not be like that. So those things also play into that. Thanks all for being here.