This video challenges the typical design process (problem statement, personas, user research, solutions) as unrealistic. The creator argues that personas are useless, and the real-world process often starts with a solution or requirement (e.g., increasing repeat orders), then works backward to define the problem and user stories. Using Zomato features as examples, the creator demonstrates how designers often get involved late in the process, focusing on designing the solution after the problem and target users have been largely defined by product managers and other stakeholders. The video emphasizes the importance of user stories over personas and advocates for a more iterative, solution-focused approach to design. Problem statement is also a requirement in this video I'm going to talk a little bit about the design process, not the design process that we're going to be following. The what I'm going to be doing in this video is explaining to you how a typical design process theoretically looks like and why something like this is never going to work. And throughout the course, your actually going to see me not follow this approach at all. And if you have been a designer for a while, you also are going to know that this is not even the process that we follow. And I'm going to show you a couple of very fun examples to explain this so that you can really understand with an example as to why something like this would never work and what actually happens in the real world. done. All right, next, moving on is order scheduling this again, pretty simple. Now, my best guess is that this probably came as feedback from restaurants, because, you know, restaurants were doing late deliveries, they suddenly got a massive inflow of a very big order, and they could not deliver on time. and customers had problems, right? So this probably came from restaurants is my guess. And this is again, doing user research to identify problems. In this case, the restaurant, the restaurant themselves gave the feedback. So this is pretty much where it would have started. And restaurants would have not said, hey, can you build a order scheduling feature, restaurants would have said, hey, this is the problem that we're doing. Can you do something so that we are known of upfront or we can prepare for things like this, right? And this also could have come from customers. I'm not denying that, But if we assume that restaurants gave this feedback, they probably didn't say, hey, add a scheduling feature, they said, look, this is the problem we are facing. Can you figure out something to solve it? Right? So here, again, this is where the problem was identified. All right. And then this was put across into a small problem statement, a user person was defined, the scope was defined. And again, here, at the end, it is at the end, where the designer was involved, because a product, product manager ideally would have identified that order scheduling is something that is feasible. Order scheduling is something that we do is something that can be done, Because if you have to work with the, the team that manages restaurant, they have to go and discuss over there and figure out if this is something that's possible. And then this feature would come to the designer to design the entire flow. All right, so next is Zomato for enterprise. Now, Zomato for enterprise is quite different for those of you who don't know, this is essentially a simpler way for office employees to actually order food on Zomato without having to pay. So it's like using your office credit card to make, you know, hotel payments, flight bookings and you know, you no money goes out of your pocket. It gets directly built to the company, right? So if you're in a manager in Zomato and you're doing some sort of a team dinner and you want to order pizza for everybody at the end of, uh, you know, at the end of the day, you can just order it from Zomato and the money gets debited from the company's account instead of you having to reimburse it right now. this is a huge feature. This requires a lot of effort, which is Zomato, having their internal tool designing something for the client and also designing something on the app for the employee who is placing the order. So there are three different products that are going to be designed or three different flows or three different experiences, if I have to put it in that way. Right? Now, this, how would this project have come into existence? And some, how did somebody decide that this is what we have to do. And we, we don't even know still how much can you do in this? What are the limitations in this? What can you do? What can't, can't you do? there's a lot of things, right? But this would have probably come as a very high level problem statement, where you want to help companies solve for food expense management, right? And this is also because maybe you're reaching to a much bigger target audience. And because now clients are going to use this tool, it is going to generate revenue. So maybe there is a requirement to actually identify how do you help companies solve for food expense management. And how can we sort of make money from that? Because zomato focus completely on solving problem for actually B2C customers. Can you do something for them as well and generate more revenue? Right. So this is where it would have probably come from the leadership. And then you come up with, you know, very high-level personas what sort of companies, what sort of employees? I don't even know how many questions we need to ask over here. there's a lot, and a designer is definitely not involved over here. Once there is some sort of clarity, maybe a very seasoned designer, a very mature senior designer would have been involved over here, Because this is a big project. You need to ask a lot of questions, right? And maybe a product manager probably even has 50% of the information identified And, you know, 50% of the scope is also defined. And so then the product manager and the product designer, they sort of work together to sort of even set the scope to identify what are the various categories of users we're trying to solve for, Because this is essentially a new tool, a designer has to get involved in the research phase as well. And here is where they could actually speak to each of the employees, or the companies that who might be interested in a product like this, what are their requirements? what are their reimbursement policies? How does it different from other companies? There's a lot of things to be done over here, right? So a designer could also be involved over here. And I have done so many projects where I've been involved, right? in the beginning, where the scope was not at all defined. And then I worked with the product manager, to define the scope to understand who we trying to solve for in what phases should we launch the product. So, at this point, you are not doing the majority of the work, you're basically assisting and supporting the product manager. Because they are the one who has to get bind from the leadership. They are the one who has to confirm that this works. They are the ones who has to look at data. So, there's a lot of work to be done over here, right? So projects like this could also happen, but it's pretty rare and is usually given to very senior and smart product designers, because this is not an easy problem to solve for. All right, Now, why did I speak about all this? The point I'm trying to make here is, if I were to go ahead and now do a redesign of the fold money app, right? So, for example, if I have to redesign the fold money web app, where do I actually start as a designer? Because when it comes to Fintech and finance management, it's not that difficult. There are already a lot of similar patterns, a lot of similar tools that are there online. But what I am doing is I as a designer, I'm just redesigning what we already have. So I'm actually going to start right over here to identify what are the solutions that we already have, what are the solutions that we can add. And then I'm going to work my way backwards for each feature or each solution. And then then think about how do I understand the problem better? All right, what are the various problem statements for that solution, Right. So here we're sort of doing something in the reverse order, which is also what happens in many cases, as I mentioned before, you given the solution, and then you need to work your R backwards and fill in all the gaps, and make sure that the feature that you're launching is actually solving the problem effectively for the right people. So I'm going to pick this up again in the next video. But quickly to explain F money already have already has these features. It shows you the bank balances, overviews of finances, the transactions they have a feature called AS groups, they have credit cards. They recently launched recording expenses and recording cash expenses. Also, right now, the web app doesn't have all of this. This is just the mobile app. And we're going to think about understanding how do we decide what needs to go on the web app, what should not. And there are a couple new features that you could add, for example, budgeting portfolio, and also calculating somebody's network. I'm, and I'm going to talk about this in the next once you have the high level problem statement, the next is to define who are you actually solving this for which is very high level personas. Now I'm completely against the concept of person on us because they make absolutely no sense and they are completely useless. It's just something that's very cosmetic in nature that is going to make your explanation and case studies or whatever. it is very much stand out. persona according to me, is probably one of the most useless things in the design process. And I'm going to tell you what is important to talk about instead of personas So once you have personas, you then go ahead and you try to do user research to identify problems that these high level personas have, right? So this point you you don't really have a super high clarity on who exactly these personas Are you a very high level, right? And to do user research, there are two ways either you talk to users or you get customer feedback. All right, and most of the time it is through customer feedbacks, Talking to users is not something All designers do all the time for every project. Now, in my experience of working for at least, you know, 50, 60 different types of projects over my past six years, in three different companies, the only users that I've spoken to are probably internal employees or people who are in close contact with customers. So which could be things like support agents, operations, teams, people like that. I have never actually spoken to an actual end user of the product that I am designing. And I'm talking about all the three companies that I've worked in so far. A lot of it has come from customer feedback. And that's where most of the problems are going to come from. that you really want to solve. So you don't really have to talk to users and send surveys. All of that is very nonsens and is done in very specific scenarios when you have absolutely nothing to refer from. Now, a lot of the times, which is the majority of the times, is because we are always trying to improve metrics, we always keep looking at data to understand where we can improve. So when we look at data, there is always a requirement to improve this metric. If it's a positive metric, we want to increase it. If it's a negative metric, we want to decrease it. For example, conversion rate is something we want to improve. And waiting period is something that we want to reduce. I'm not going to talk into too much about metrics at this moment, but data is something that helps us identify what are the problems that we want to solve and what are the requirements, right? So once we have this, what we then do is we break that down into smaller problem statements, right? And a small problem statement is essentially something that you want to do when there is no existing solution, or you are unable to do something effectively. So in this case, let's say there was this high level problem statement. And then we broke that down into five smaller problem statements. So problem statement, A, B, C, D, E. Now once you do that, you then go ahead and you create personas Now you have the high level persona, You go ahead and then you prepare those personas So you have, let's say three personas. And then the next step is to distribute those problems. So you want to say persona 1 has problem A and problem E. persona 2 has problem B, and problem D. Persona 3 has problem C. Now let's say there is a persona who has problem A and C right now, does it make sense to create a fourth persona with A and C? And what if there's a persona who has problem D and C, are you going to make a new persona a fifth persona, which has problem D and C. If you keep doing that, you're going to have probably thousands of personas And that is absolutely adding no value. And it's complete waste of time. And it is probably why I always say personas is probably the most useless thing ever invented. And persona is just a gift wrapping or some sort of a container to actually contain the actual information. And what do I actually mean by this? Because what is more important is creating user stories. So essentially, what you need to do is you need to take a problem and consider that to be a user story. And a user story is basically defined as a person who actually wants to do something because they want to achieve something. And so the only thing you need to focus on is user stories. And you don't even have to assign personas to user stories like this. Because if you're solving for user story A, it doesn't matter who the person is, whether they are a male or a female, whether they have poor internet connection or high internet connection, whether they're rich or they're poor. It doesn't matter at all the characteristics don't matter. What is more important is a user story that contains who you're solving for, why they want to do it. And what is it that they really want to do? Because if you see over here, the reason I've put it across, this is because user story A is solving something else. User story E is solving something else. but it's the same person who has two different problems. So instead of putting it like this, why don't we just remove this and create a user story that mentions who the person is, why that person wants to do something. And what is it that they really want to do? Right? And that is how designers in the real world actually do this. And unfortunately, all the documentation and all the theory that's there online focuses so much on persona, which is probably the most useless thing ever. So I would highly encourage everybody to start focusing on user stories and forget about solutions and problems and persona pick up a user story. That is the only thing you need to keep considering when you're trying to solve a problem. And obviously, we're going to look into this completely in detail in pretty much every single video, because we''re doing a lot of designing. All right. And then what you want to do is you want to then focus on the solution UTION. So you look at user story A, and you like, okay, fine, there's a user who wants to do this because of so, and, so reason, how can I solve this problem? Or how can I help them meet their requirement? And that is how you come up with solution, a solution E. And for each user story, you have a different solution, right? So, and then finally, the last step is designing. Now, one of the things that you want to focus when you're doing user stories is to always frame a problem statement as a user goal, or requirement, and do not frame it as a solution. Your user story must never, ever, ever have the solution to the problem. This is probably the most biggest mistake that I have ever seen Juniors make when they're talking about user story. If the solution is with inside your user story, then you have not created a user story, you have just created a solution. And I'm going to show you a couple of examples of user stories, probably in the next few videos, because I don't want to make this video too so let's take a couple of examples. Now I'm going to show you like couple of examples as you see over here, like five examples from Zato. And over the past few years, Zato has actually been shipping a lot of features. Um, and I want to talk about that and how this feature would have actually come to life. And I'm going to give you an example. So one of the features is called as brand packs, which is essentially some sort of a subscription. In a way, it's not really a subscription. And once you buy these coupons, you get certain benefits. So for example, the Starbucks brand pack gives you 10% off on the next five orders. And, uh, there is no limit that you have to order. There is, as you can see, there's no minimum order value And it works at basically all stark outlets, right? And there's a validity of 45 days. And you can buy these five coupons for 29 rupees right? Now, when they designed this feature, how did this actually start? Who decided that it should be brand packs. When was the designer involved? Let's try to understand that. Now, I obviously have no clue how they did this, but because I worked on so many different types of products and features, I have a very good educated guess of how this could have happened. So if you take the same design process, what would have happened is there would be a highlevel problem statement, or a requirement in, in this case, which is basically to increase repeat orders. Because if you think about it, the only people who would actually buy this are people who would regularly go to this. That is, why is this is essentially like a subscription, right? You repeatedly use a product or a service, because you like it. And you are a repeat user, because you're a repeat user, you would definitely want this. And this would increase repeat orders. It does not increase orders. Of course, it does increase orders, but the primary metric that it would increase is repeat orders. And there are many benefits of repeat orders. The main, the main benefit is that it takes less time for a user to order. And that's basically more conversion and more retention, because people keep coming to order on your app instead of another app, which in this case would be SWiy, right? But the primary one is repeat orders, because it every metric affects other metrics. it's not always engagement and retention. Yes, They are always going to be affected in some shape or form. But you need to come to the closest metric as possible for every project you're working on. So, in this case, this would increase repeat orders, because then people would buy these brand packs and they would come back and order from the same cafe or restaurant multiple times again, and again, and not just that. The most important thing to understand here is that this may not work for every restaurant. If Zomato knows that people are ordering from the same restaurant multiple times, the same person is ordering from the same restaurant, they would be a proper target user for this. Because if I'm ordering probably once a month from Starbucks, then I'm not essentially a target user. So Zomato probably knows that there are people who are constantly ordering from the same restaurant multiple times. And so it makes sense to introduce brand packs for those restaurants or cafes, right? So it would have actually started like this, there would be a requirement where they say, hey, we need to increase repeat orders, but we don't know how to increase it. And this is not where a designer is involved. A designer is never ever ever involved in this 99.9% of the cases, because the leadership is the first who's going to decide that they need to increase this metric. It is their job to do it. And then it comes down to the product managers and basically the various teams who are in charge of solving that problem. And so it would then come down to the product manager. So then the product manager would probably decide, okay, fine, we want to increase repeat orders, We can increase repeat orders in hundreds of different ways. Who do we actually want to solve it for, Right? Depending on who you're wanting to solve for the solution would be completely different. So they, again, the product managers would define who are the high-level personas And then they would also sit and do some user research where they would actually sit down and look at data, especially data for this problem statement, data is extremely important. And also, they would probably also talk to the restaurants as well to understand. But in my best guess, they probably looked at data, and they decided to do this. There was probably an operations team that spoke to the restaurants and the data was already there. So the product manager would have collected the data from the operations team, or probably some sort of a represent presentative from the restaurant side, right? I don't know how Zato really works, but a designer is still not involved over here. And then this is broken down into smaller problem statements. And probably this could have been one problem statement. And this problem statement is combined with this user persona as well. So it's never a problem statement first, and a user persona first, right? It's always combined together. So step number four, five, six, and seven is something that's always sort of done in different, you know, orders and different proportions. And sometimes these steps are even skipped, right? So it's typically a product manager who gets involved in doing a lot of this discovery, a lot of the defining of scope, identifying who we are actually trying to solve for, and how big of a project this is and how big is a solution, right? And there could be a way where there is a solution that has been identified. Okay, we need to introduce brand packs because it's impossible for a designer to come and pitch this to leadership and say, hey, we should release brand packs. Because you need to explain why you need to release brand packs. You need to have looked at data. there needs to be some sort of validation. You need to prepare some proof that this could work if we launched it, right? And this is not the job of a designer. So, in this project, a designer would have been involved at the very end, and they only have to design the solution. Now, this doesn't mean that the designer is only going to start mocking up screams, right away. A designer is still going to go and perform all of these actions. All right, probably from here, right? From the mini problem state statement, where they had to increase repeat orders for a certain specific set of users. This would, this is where the designer would start from, right? And creating these user stories, understanding the depth, looking at edge cases, looking at corner cases, understanding how this is going to impact business. All of this is going to be done first by the designer, but the designer is involved when we are ready to design the solution, because the PM is never going to do 100% of the work, a product manager is always going to do probably 60 or 70% of the work. And that's where they would need designers to challenge some of the things that product managers decided to question, to gather more information to solidify everything, making sure that all edge cases are accounted for how this affects the rest of the app, the rest of the teams, the rest of the customers, and looking at the bigger picture, right? So just because a designer is involved in the last step, which is designing solutions, doesn't mean the designer is not going to do the rest, they're going to go back all the way to where they should go. And then they would start designing and this is how pretty much it's done in all the companies by de-designers. Next one is extra change. So the feature is pretty fun. Uh, the feature is pretty helpful. So basically you get extra change credited to as Zomato money on all cash on delivery ord. So for example, you did a cash on delivery order. The total bill was 530 rupees, but you didn't have change. So you gave 600 rupees. So the rider takes 600 rupees, the bill is 530. And because that 70% was 70 rupees was extra that you paid, That is going to be added to zato money. Now, how did they decide that? this is a feature that needs to be solved? Now, my best guess is it probably started right over here, where during delivery orders, riders were complaining that they did not know what to do, because they had to, because they did not have extra change with them. So, this requirement, or a problem, in this case, actually came directly from the rider is my best guess, because they are the ones who would have complained about this. And it is at this point that a designer also could have been involved, because it is very clear who the problem is for, and what exactly is the problem. So, when there is some sort of clarity on the problem statement, and who the problem is being faced by a designer is then going to get involved. Now, this feature of actually adding that extra money to zomato money is something that could have been brainstormed by both the designer and the product manager, because this is quite of a simple feature, and it's very straightforward. This could have been done by the designer and the product manager as well. Maybe there were multiple ways they could do this, but who decided this? I'm not really sure. Anyway, so this is where a designer gets involved, you try to get requirements. Everybody has a different way of approaching a problem statement, because if the solution to do this has already been decided, then you need to think about edge cases, and then you need to look at user flows, and then you need to talk about, talk with the finance team to see how this works. There's a lot of things that goes in, in the back end, right? So, this is where a designer would have been involved in This problem statement is my best guess. Next one, group ordering. Now, group ordering. ing is a definitely something that customers would have requested for. And also, Zomato also could have identified this, because if they see a lot of people are ordering large amounts of orders to places like work, or, you know, birthday parties, or, you know, get togethers it could be anything, right? So there is, there is an actual requirement from users. And they also could have identified this by looking at data, saying that very large groups of orders are being ordered for various occasions. And this could also be coming as feedback from the restaurants themselves, right? So what I have done is I've gone all the way to the end. And I've said the solution was already decided, we need to order group ordering, because there is some sort of a requirement. And if we have to think about what group ordering solves, it's very vague and high level nature. It's very difficult to explain why you need group ordering. Now you I'm not saying that you can't you can, But it's so obvious that even writing it down is not going to give any clarity to anybody else. Everybody who works at Zomato. if you ask them, why do we need group ordering? It is super straightforward to understand. The design process begins with identifying a high-level problem statement or requirement. In the example given, the goal was to increase repeat orders from customers. This is crucial because focusing on a primary metric (like repeat orders) guides the entire design process, unlike approaches that vaguely target engagement or retention. The speaker suggests that other methods fail because they lack this focused, measurable objective. Next, this high-level problem is broken down into smaller, more manageable problem statements. This structured approach ensures that solutions are targeted and effective. The speaker implies that less structured approaches may miss the mark because they lack a clear, prioritized goal. High-level problem statement: A broad, initial description of a problem that needs to be solved, often lacking specific details. It serves as a starting point for further refinement. Personas: Fictional representations of users, created to help designers understand user needs and behaviors. In the video, the speaker argues against their usefulness in the design process, advocating for a focus on user stories instead. User stories: Short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually following a template like "As a [user type], I want [some goal] so that [some reason]". They focus on user needs and goals, not on solutions.
