hey everyone and welcome back to my channel so in this video i'm going to give you an overview of a typical design process that a ui ux designer or product designer is expected to follow your design process will be slightly different depending on your role the team you are at and also the company that you work in large companies often have different design teams across different products if you join a large company you may be expected to work on just one tiny part of the product instead of all of it your role will be more
specialized in one product only whereas if you join a small company you are expected to know each product inside out and you will be able to design cross product this is why some companies have teams doing only ux design ui design interaction design or simply just prototyping only so depending on which team you're at which role you're at your design process is going to be slightly different so our design process is similar to that of a design thinking framework this design thinking framework is pretty common and is popularized by ideo and you probably heard it
many times over if you google design thinking or if you google the ux design process you will typically see images like this a design thinking framework consists of five stages discover define ideate prototype and test so in my version of the process it typically looks like this you start with discovering which is understanding the business the uses and then you move on to defining the problem statement which is to determine what problem that you're trying to solve before you even start designing in the ux design process it's really not fancy five stage diagrams that you
see on the internet all the time sometimes you go back and iterate and sometimes you may not need to go from stage one to stage five you may probably be able to start from ideation right away if you already have the problem statement defined beforehand so stage one discover user research consists of the first stage and the second stage we are not our users it doesn't give us the right to assume something that we think our users want like a feature we don't know the problem or the answer until we actually ask our users there's
also a myth that user research is expensive and time consuming well it doesn't have to be i'm a big believer of simplifying processes if you don't have the budget to do a full-fledged user research or hire a user research agency or build your own user research team that is fine you can still do it for free and it can be done anytime and anywhere keep the end goal in mind the purpose of this user research process is basically to understand your users understand how can you help them solve a problem through your designs there are
different ways to conduct a user research depending on the method you use the deliverables of the user research will also be different sometimes you could use the typical user research methods to get your problem statement defined already you do not need to dive into super fancy advanced user research methods all the time common user research methods can be split into two quantitative and qualitative a typical quantitative research method is like a survey where it's actually a questionnaire that you can send out to a large volume of users gather their responses and analyze them later whereas
for the qualitative user research method there are many ways that we can do this for example user personas jobs to be done framework empathy mapping user journey maps affinity diagram user interviews usability testing gorilla testing card sorting the ones that i've just shared are one of the common ones that we use the tools we use for research method varies depending on which method we use and one of the common ones are google meet and zoom for user interviews when we do user interviews we will set up a one-on-one call with the user we will prepare
a set of questions and tasks beforehand and if we are doing some surveys you could use three ways like google forms you could send up a typeform survey you could also use maze or build your own in-app survey no matter what user research method that you use ask open-ended questions so if you ask users open-ended questions they will be able to answer you something more elaborate so yeah this is stage one of the user design process where we talk about discovering our users understand them better and sometimes we might uncover some learnings that we never
expected next up we will define the problem statement the purpose of this stage is to find out what problem that you're trying to solve for your users it will set the right mindset and expectations in later stages this stage should not just fall on the designer the stakeholders also play a part in defining the problem statement it is a team effort by stakeholders i mean people like the business team the marketing team the product team your product managers product owners and also the designer and when a team works together to define a problem statement it
is more likely that we stay on track and not lose sight of the goal as charles scattering once said a problem well stated is half solved a problem statement should be user-centric it should help solve a problem that the user is facing the problem statement should not be about product metrics business metrics or technology typically in a problem statement we can start off by saying how might we or what can we do to blah blah blah for example how might we increase the sales for our website versus how might we improve the shopping experience for
our users the latter is a better problem statement because it is user centric after the problem statement defining stage we might probably find out that the problem statement isn't right or we will need to go back and understand our users better this is when we jump back to the first stage which is the discover stage and do it all over again in the case where you finally have a problem statement that you're happy with you move on to the most exciting stage which is the ideation stage this is the part where we go crazy draft
out of the box design ideas and the sky is the limit here some of the common ideation methods again fancy buzzwords here are crazy aids sketching user flow mapping storyboarding mind mapping and then we move on to the prototyping stage we can build a prototype in a design tool like figma which is pretty easy to do it should take less than a day to build a prototype on figma you're not expected to spend days and days of prototyping because it could be expensive to do that and it's not effective i will usually build mid fidelity
prototypes that is clear enough to help users understand what the design is going to look like but not too high fidelity where every pixel is perfect once we have the prototype ready this is when we test it the sooner you test the prototypes the sooner you will be able to understand how to improve your designs so as i mentioned earlier testing shouldn't be expensive and time consuming we can do this remotely before the testing we will start by defining the questions that we are trying to ask and also the user task in a note-taking tool
like notion stakeholders can also come in and give input on what insights or questions they would like to find out during the test we will also have a rough script ready so that we don't miss out anything during the test and to make sure that the prototype works exactly as expected and once we're done we basically just schedule a test with the user during the testing it will typically take from half an hour to one and a half hours depending on what you're trying to test and also the scope we will get the participants consent
that this session will be recorded they will need to share their screen turn on their video camera so that we can observe their expression we will also give a brief introduction about why are we doing this who are we and what is expected of the user to do for example speaking their mind out loud after the testing we're just going to document those insights on notion summarize them and present to our stakeholders so that everyone learns about what we found during the test if it's a survey we are going to summarize all the survey results
and also present to the stakeholders it is also normal to go back and iterate once you find out that after testing there are things that we could improve on or maybe the design is not going to solve the user's problem the more you do this the more you'll be more confident with your designs that it will truly solve the user's problem for example if the checkout experience is confusing to our users at least during testing we find that out quickly so that we don't have to risk having a bad user experience after launching it this
process seems tedious at first but it is necessary to go through because it will save you a lot of time headache and money in the long run say now you already have designs that you are satisfied with and truly solves the user problems based on the testing results and then we are going to prepare the designs for handoff on figma if there are animation specific design specs we are going to stick that clearly in the design file at this stage we will also set up a call to with our stakeholders and also the tech team
if it involves other teams we are going to bring them in in the call as well and we'll walk through them with designs the context on why are we doing this maybe share a little bit on the test results when you bring tech leads into the design process early on they will be able to expect what's coming next and give their expert inputs on whether this design is technically feasible and if not how are we going to work together to solve this problem in the meeting if they have any questions we are going to answer
them as well so that everyone is clear and good to go and then once we have handed off the designs to development we are going to continue to be on standby to answer any questions that the tech leads or the development team have found when they are inspecting our designs we will then move on to test the designs in staging which is similar to a production environment but it is not out for the public it is only for internal testing if there are any ui or ux issues it would be great to point that out
as well when we are done testing the product in staging we are finally ready to launch the product post launch there are bound to be some bugs or feedback on how we can improve our experience after launching the product you can also ask questions like what worked what didn't work how are the users responding and was the problem solved in the first place if there are anything that we're unsure of and we need to validate we will also implement a b testing to test out which image or copy is more effective this is the perfect
time to also iterate on your product if there are any ways to improve it one thing these stages have in common is constant communication and collaboration when you google the design process you will find lots and lots of fancy methods and buzzwords or formulas even to have the perfect design process but you do not have to follow all of them by the book pick and choose whatever works for you as long as you make sure that you are really solving a real problem through design don't make assumptions about our users because again we are not
our users at the end of the day the goal is to design a great product that truly solves a problem frameworks are great but don't follow blindly i'm sorry that i couldn't dive into every single detail because each stage of the design process demands a video by itself and i could go really deep into all these topics but let me know what kind of topics that you would like to see in the comment section below if you want to learn your ux design remember learning paired with action brings you closer to your goals so i'll
see you in the next video bye
