The Insider's Guide to UX Design #learnux #uxdesign

Hey there, hi, Anirudh here. Welcome to my YouTube channel. This is Roadmap to User Experience Design episode number 3, and today in this episode I want to talk about life of a UX designer. Yes, life of a UX designer. I would want to cover what is it like to become a UX designer in a startup versus a well-established organization. What are the actual roles and responsibilities of a UX designer? Well, the topic is very huge, that's why I would want to restrict it to 3 important aspects. First one, what is the actual workflow? How do we get requirement and how do we fulfill the requirement? Second aspect, what are the actual roles of responsibility of a UX designer, that in startup versus in an established organization? Aspect number 3, the actual growth in terms of monetary and in terms of skills. So without any further ado, let's get started. First thing first, let's say you have already become a UX designer. How did you do that? Well, maybe you got yourself a formal education and then got the job. Secondly, you started it from scratch, leveled up your skill, and got yourself a job. Simple, right? But working in a well-established organization versus working in an early-stage startup is way too different. It's totally upside down. It's more like two different faces of a single coin. Too much hype, right? So let's just dig into it. First, let's try to understand the workflow in a well-established organization. One of the most important benefits of working in a well-established organization is that the complete process is very streamlined. The total hierarchy and the reporting structure is very well in place. So that's why, as compared to startup, in an organization you would get very little ad hoc tasks because everything would be pre-planned. So let's just talk about the complete hierarchy of getting a requirement as a UX designer. Stakeholders and the business team. The requirement actually starts from the top level of your hierarchy. The stakeholders and the business team would come up with some idea. For example, there is a niche market or an untapped market that the business team and stakeholders would want to tap. So they would understand the requirement, document it some in the other way, and give a conclusion saying that this is something that we would want to do. And this is the actual problem statement, and let's just solve it. Well, cool. Now the same thing would go back to the product managers. Product managers, beautiful people, to be very honest. Now the product manager would try to analyze and understand the actual requirement. He or she would want to talk to the stakeholders to get a detailed understanding of the problem statement. Maybe just to and fro, and product manager would understand the requirement. Once he or she does that, they would start with their primary initial research. Around the problem statement. Let's say the initial research is done very well. Now the product manager will start documenting it. Now the documentation process is done in something called PRD, Project Requirement Document. It's a very beautiful tool or a very beautiful documentation process. I would definitely make another video onto it altogether and talk about all the components and features of a PRD. Moving on, once the PRD is done, means the requirements are very clear, this requirement or the PRD document is given back to the design leader. Depends on organization to organization whether it's a VP, design head, leader, or say design manager. Now once the design lead gets it PRD, they try to evaluate the efforts and the number of hours that it would take. Also understand the actual skill set that it will require to complete this task. Now based on that evaluation and some estimation, they would give this task to a specific designer. Let's say you or me as a UX designer. This is the actual point once you get a requirement from your design leader, is the actual point when you get started with the requirement, and that's how the actual handover process from a stakeholder to product manager to design lead to actual designer is given. If not talking about the solutioning part, because that would actually require altogether another video, maybe we could talk about design processes like UDC or Double Diamond or maybe Design Thinking process, but let's just say you try to solve it. Now, once you are already done solving the actual problem statement, you have come up with some of the wireframe. Now, point number 2, how do you actually give back this requirement to the company? Well, the complete structure is upside down. The moment you wanted some requirement, it came from top to bottom. Now the submission of this requirement will go from bottom to top. For example, you as a UX designer came up with some solution, you would Share the wireframes with your initial design team member and get an early stage insights or feedback. Let's just consider the best case, there are no feedbacks on it and everybody likes it. Then this will go back to your design manager or design lead. You would have a discussion saying that, hey, this is the requirement, this is the solution, what do you think about it? Let's take another positive case that, you know, even your design manager likes the design. So without any other iteration, it will go back to the product manager. Now you would present your design to the product manager Product manager will make sure that, you know, all the test cases and the scenario is fulfilled. And once he is totally satisfied and if there are no any number of iteration, it will go back to the next level, which is the stakeholder and the business team. Now this is the point where your actual storytelling and presentation comes into the picture, because before all the stakeholders round, the actual thing that you're doing is sharing your idea and thought process, because you all as a team are coming up with a solution, not only you as a UX designer. But when it goes to the stakeholder, you make sure that you sell your design, you actually sell your thought process. So that's the complete process of getting requirement versus submitting a requirement in a well-established organization. Now the thing with startups, more specifically early-stage startup, is totally different. It's not like an organization because the team, the structure, and the hierarchy is not very well established in early-stage startup. The team size is compared to an organization, very small. For example, a team at a very early-stage startup would be like CEO, CTO, or a co-founder. A small development team may or may not have a finance or marketing team, may have a smaller design team, maybe one or two. For example, in my case, it was just me, a single designer. I had no design team. So in that case, the complete requirement structure would work in a direction where the CEO or the co-founder would directly come to the designer and share the requirement. They would have an initial discussion round. Maybe you would jot it down some point or scribble here and there and document the complete requirement. Once that is given back, you would try to sit back and understand the requirement, and you would initially go back to the CEO or co-founder and have some stakeholders question. You would ask, hey sir, when do you want me to do this? What is the actual requirement? I don't understand this. Or maybe a lot of any other questions that you have. Once you have cleared things out, you would actually start on the designing part of it. There's no other people involved over here. The design process again depends on how you want to do it, but there is no third party involved over here. You would directly start to work on your solution. Once you think there is one part of the solution is done, maybe iteration 1 or ideation 1 is done, you would go back to the co-founder and sit together with him and discuss the solution. Number of iterations might take place, and once you mutually decide that this design is good to go for your minimum viable product which is MVP, you would give that complete design to your developer. So there is no people like product managers, stakeholders, design leads, design manager, or design director. There is no things as such, only your co-founder and the designer. That is the simple working hierarchy in an early stage startup. But eventually, once the startup gets to get funding, the organization would work, and eventually the early stage startup would turn into an well-fledged, well-organized organization. So eventually the team structure would be formed, team would grow from like 5 people to 50 people, and eventually the complete workflow would be same as an organization, right from the stakeholders to the product manager to design leaders to you. So that's all about the requirement that you get as a UX designer and how do you fulfill at a startup versus a well-established organization. Roles and responsibility of a UX designer in startup versus well-established organization. Now if you try to understand the complete structure of a workflow was very different in startup versus in an organization. So similarly, the roles and responsibilities differ up to very extent. Let's just try to understand how. Over here, I would want to start with startup. In a given startup, the complete list of deliverables is very high, and each UX designer, depending on the number of designers that do we have in a startup, For example, if there is only one designer, you would have to go through the complete list of deliverables of the UX and provide it back to the CEO or the co-founder. For example, right from understanding the problem statement, the complete initial research, the market research or the user research, going back to the complete wireframes, information architecture, user journey, user flow if it is at all required, do the visual part of it, style guide, Everything would be done by a single designer. If the design team has more than one designer, then this responsibility would be divided into two different factors. Maybe you would take part of the research part, maybe the other designer would take part of the complete UI and the wireframes. Let us say a startup comprises of a UX designer and a UI designer, then you would take care of the complete UX deliverables till the wireframes, and the UI designer would take it forward. That is how it works in a startup. If it's a one-man army, you get to work on all the domains of a UX designer, all the deliverables. Unlikely not in well-established organization. As we discussed that any given organization which is very well established would have a complete reporting structure, the hierarchy and the processes are very streamlined. So that's why there would be very less ad hoc work and any given design team would definitely comprise of a UX team, UI team, or maybe a product team. We would definitely have some dedicated motion designers, graphic designer. We would have some UX copywriter or a copywriter in general. So that's why the roles and responsibility over here depends on person to person. That is all about the roles and responsibility of a UX designer in a startup versus well-established organization. Today, by 2022, the world has already understood the importance of UX design. That's why people are today hiring for a very specific role, specific research role, specific interaction role, specific UI role, specific design system architect. That's why you would see it's very likely, low possibility, that one UX designer will have to do each and everything, right, all the deliverables. So that's why every time you apply for a job, make sure to understand the roles and responsibilities responsibility. It's not about the organization, or it's not about getting into an organization. It's about the work that you do as a UX designer. If that roles and responsibility makes you happy, go for it. Let's just talk about growth— the financial growth, the skill set growth. So I want to keep this section very short and simple because all I'm doing right now, I'm just going to share my personal experience, and I don't want you to go out there and make this a universal truth because it is something that I have experienced. So working in a startup, the actual growth in terms of skill set is very high. And how is it that? Like I said, if the startup is a very small startup, it's not an organization, the team structure would be very intact. It would be a very small team. You would get an opportunity to work on multiple things. Say for example, you are very good at UX UX, but not at UI, and you would have to do the complete end-to-end flow. So you would eventually become good at UX to next level because you are doing it all over again, and you would start learning UI because that is the need of the hour, that is the need of your roles and responsibility. So over here, you already became good at what you already know, and you also get to learn something new. So eventually, getting to work on end-to-end process in a small startup because of smaller team structure, will help you grow exponentially in terms of your skills. Let's just talk about the monetary growth in terms of startup and in terms of organization. I don't want to run in circles. I would be very straightforward. Today, by 2022, the world has already understood the importance of UX, like I told you. At the same time, the world has already understood the importance of an employee. So your salary or your financial growth on yearly basis is directly proportional to the amount of knowledge, experience, and the value that you bring back to the table. If you're working really very hard in an organization, you would definitely get the rewards. Unlike few years back where the demand was very high and the supply of very low. For example, the demand for UX designer were very high, but the supply for a UX designer was very low. So that's why people would get very high salary in in a startup versus that in an organization. But today it's other way around. It's totally purely on the amount of knowledge, experience, and value that you bring onto the table. So irrespective of the salary that you're working on right now, please give your 100% and definitely your organization will give back to you. If not, there's always a choice to move on. That's all I have for you in this episode number 3 of Roadmap to User Experience Design. If you have any questions, please put that into your comment and I will revert back to you quickly. This is me, Anirudh Palaskar, signing off. See you in episode number 4 where we'll be talking about getting started with UX design. Bye-bye.