The UX Design process is very flexible and is dependent on things like project, team, requirements, timeframe and more. In this article, I aim to give a general overview of what a typical UX Design process looks like for me, how I start and how I think about the problems ahead. If you are looking to start a career in UX Design then this article will be a great help to you, and if you’re an experienced UX Designer please drop a comment below if you have any thoughts on my process and how I can improve.
It’s all about problems, I wouldn’t even start putting pen to paper without first discussing the problems. Remember in UX Design you’re typically not alone, you’ll likely have a boss, product manager, stakeholders, CEO overseeing the project as well as other team members working on the same project. There absolutely must be a kick-off meeting, the point of any product is to solve a problem. So we must first identify the problems as well as the product goals and requirements, this can be done in many ways but the first one will likely be a meeting. In this meeting, you’re going to want to get a total picture of the problems the product is designed to solve and start thinking of solutions in your head. Ask all the question and roadblocks you think a user might have and any other problems we want to solve.
Now is the time to go away and figure out what’s out there, who’s doing what we want to do? Who are our users, where can we find them? what do they like? what do they dislike? What problems are they having? There are many ways I would go about this such as surveys, user feedback, competitor reviews, forums posts, Facebook posts, Twitter and even the news. Google is a powerful tool so you must know how to use it, people complain all the time online so finding users problems shouldn’t be too hard. And if all else fails then we’ll have to go out and ask people ourselves on the street or with something like Skype. Here is a good blog post about Ux Tools for User Research.
After I have figured out the problem it’s time to really understand the user, their motivations and goals. Now they are most likely not in the room with you, unless you are very lucky so you’ll need a little imagination. This is where we rely on some UX Designer techniques to figure out our users and empathize with them. I would start with personas, depending on the scope of the project and the target audience I might only need 2 or 3 but the more the merrier. A persona is a representation of a user, typically based on user research and incorporating user goals, needs, and interests. I would also suggest building a persona yourself rather than from a website, it helps you connect to the idea a little more and understand the problems a little better.
Let’s say for example we are a company selling male grooming kits, razor blades and gels etc, we offer high quality but low-cost products compared to major name brands.
Super Simple User Persona Examples:
As you can see I have quickly come up with some people we can empathize with and think about when designing. Just from creating this small list of 3 personas I could easily start thinking about the sales copy of the product, and to which audience we want to talk to. You’re going to want to refer back to these personas throughout the product design, so it’s a good idea to spend some time on them and get them right. Here is a good article about Personas on the Usability website.
Tip: It might help to use people you know when making personas. I use my Mum or other family members as a reference sometimes.
This is best to do with a few people, I would try to get as many people as you can who are involved. So anyone from a Dev, Designer, QA, Social, Content, Copywriter, Manager, CEO, anyone who wants to join can but maybe limit this to 5-8 people. I would book a room with a whiteboard and use either the whiteboard and pens for this or I would use post-it notes as long as I have different colours it’s going to be fine. Graphic of this will be below. So the plan here is to take all my personas starting with the most obvious one, not the edge case. We are going to map out and create a scenario for each persona, with the steps they will take using our product to get a good idea of the questions and solutions they will face.
Example the steps our persona “Tim” might take:
So here we have mapped out the steps Tim will take when arriving on the website and going through our funnel to check out. The next step would be to think of the questions, ideas or comments Tim might face for each of these steps, based upon what we know from the persona like so: Typically you’d have this horizontal, but because it’s a blog post I will write mine verticle.
I did this pretty quickly and off the top of my head I have fleshed out a ton of details about Tim and his needs with our product and how he’s going to interact with it. You can probably see how having a group of people in the room to think of this stuff will give you a ton of different perspectives on all aspects of his journey. Now do this a few more times for your other personas and you have a really good understanding of what your users are thinking and the problems you are going to solve. Tip: Sometimes users make errors, so make scenarios where errors occur or users need to go back and redo something. For a great read about Scenario mapping checkout UX for the masses step by step guide to scenario mapping. The image below is from that post.
I think this step is one of the most overlooked steps in all websites and apps, an actually thought out sitemap and flow. It’s not even hard to do, I have worked on sites where the onboarding sitemap would look like a bowl of spaghetti instead of a nice flowing horizontal progression. I would design the sitemap with the main users in mind first, then make sure users with errors or edge cases are well accommodated within that map. The most simple sitemap could look something like the image below, which is from the Ten Touch UX website. This sitemap shows a very simple website design which links going out to subpages.
An Onboarding sitemap or flow would be a lot more linear, with one entry and one path to finish signup. The onboarding signup would, however, have little branches breaking off for things like forgotten password, error and confirmations. An e-commerce sitemap or flow could be very simple on paper but very complex depending on the user’s behaviour. Either way, it is very important to get all this down on paper and then mockup up with some design software so we know where the users are. If we have any dead ends or pitfalls, then we can help to get users back on track and moving once again.
Time to put pen to paper, this is where things start to get exciting. I always start with sketching first. If I jump right into a design program it’s easy to get carried away with UI too early. So Pen, Paper, make a rectangle and start sketching pages. You’re just drawing shapes, so you don’t need to be an artist. The headline here, logo here, an image here, CTA here, etc, etc… I would suggest you do quite a few sketching of each page, try different layouts and refer to our previous work to decide what needs to go where and why.
This is also a weird but great time to get feedback from various team members, Devs will bring up technical issues and other team members will have other things that could improve the overall experience. Here is a nice wireframe sketch example from Kristen Joy Baker:
Don’t be a Grand Revealer! This is something I work on personally, it’s not helpful to sit at your desk designing away for 2 weeks then having a grand reveal to everyone. There will be too much feedback at once and things will be lost, it’s far better to get people involved often and get feedback on smaller things rather than the whole website at once.
Tip: You’re going to have to deal with a lot of feedback from a lot of different people, some good some bad. Just take it all in, write it down and try to focus on those user personas and build a great user experience that meets the business objectives. Don’t take criticism personally, improve, iterate and adjust.
What Tools do I use?
My absolute number 1 tool for all things UX/UI is Figma, it came out of beta last year and I love it. It allows me and my team to collaborate and work on the same documents at the same time. It also has code previews, device preview, team libraries, components, prototyping, web viewer/editor and Jira integration. I used to use other software like Adobe XD, Sketch, Invision but this blows them out the water in my opinion. But, if you love Sketch, Invision, XD, whatever and you are powerful with those tools then crack on.
Time for some colour in that dreary wireframe, I would assume I would have a style guide if not the basic colours to use for the branding. Maybe I would have all my buttons and page elements predefined in a nice style guide so I can simply take the elements and put them to work to match my wireframe. If not then this is a bigger task, where we need to probably do several designs of the UI but maintain the original UX wireframe design. I would again use Fimga for all of the UI and prototyping phases, making sure I use/create the team library components so elements will be shared for future pages and designs. UX is still a part of UI design so button style, colours, font size and style all have an effect on a user’s experience so keep all that in mind.
This is where we would need to head on over to prototyping, again I use Figma for this but you could use Invision or something more advanced like Framer if you need super advanced animations and interaction but it seems like overkill to me. There would normally be a bunch more feedback in the UI and prototyping phase which will need to be addressed, then it would be a case of handing over to the dev. Figma has a great code feature which will give developers all the specs of any element they need to see, and anyone can leave comments on the file for revision. Here is an example of a simple style guide with a couple elements from Medium:
Nothing solves a design dispute like data, the number of times I have wanted to do something one way while another person the other. Stop talking about it, do both then A/B test it, loser buys the drinks. Validating your designs is very important, it’s not always about getting better results but even when you lose you learn. You must learn what your users are doing, anyway I won’t go into detail about A/B testing but know your KPI’s and variants should be small to learn. You either win and figure out what works for your users or you lose and learn some more about your users. Either way, you learn and you adapt for the next design. Smashing mag has a good write up about A/B testing and design.
So that’s it, this is my general UX Design process in all its glory. In fact, there are a few more little bits in there but you get the general idea of what a UX Designer would do and the process they take. After it’s all said and done and you need a new feature it’s always good to implement these steps, to understand the user, the business, the problems, solutions, objectives and overall the experience. Problems, Research, Users, Story, Plan, Design, Design, Validate and repeat.
I hope you found this post interesting and helpful if you have questions about the process or would like to know more please leave a comment below or email me.