Published on <a href="https://blog.prototypr.io/a-common-product-ux-design-process-55af4ab5665e?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Thai Lam <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*YY9u6KrsDXpIh6kHF_duqQ.jpeg">Credit: <a href="https://unsplash.com/photos/gcsNOsPEXfs">https://unsplash.com/photos/gcsNOsPEXfs</a> —  William Iven
I got many questions from my friends. So what design process do I use? How do you start? What and how many steps are there? If I just say in a small chat I believe many of my friends will do it wrong. So let’s break it down here.
<blockquote>Editor’s note:</blockquote>
<blockquote>It has been more than one year since I first published this article on medium. I realized there are so many people found my article on Google search (40% of traffic comes from Google Search). I’m happy that my writing can somehow help everyone get the first understanding of UX design process. Hence, in order to make it more approachable and practical for readers, I decided to add more details and turn this article into 2nd edition.</blockquote>
<blockquote>However, the UX process itself is very flexible, depends on different situations and different product teams will have different ways of implementing their process. This article will give you the idea of a general and common design process so that you can start apply it right away. After times you will find the differences in reality and what I wrote here, start improvising and then you can understand UX clearer and better.</blockquote>
<h4>First thing first, UNDERSTAND</h4>
<blockquote>“If I had only one hour to solve a problem, I would spend up to two-third of that hour in attempting to define what the problem is.”</blockquote>
<blockquote>— Matthew Wakeman from the book <a href="http://shop.oreilly.com/product/0636920048336.do">UX Research &#8211; Practical Techniques for Designing Better Products</a></blockquote>
Define the problem first. You need to understand clearly what are you trying to solve, ask your clients if you are working in an agency, ask the business stakeholders, the Product Manager if you are in a product team or even the CEO if you are working in a start-up. UX design is the process of solving a problem for user, helping them achieve their goals with ease and more than that make them feel delightful while doing so. This very first step is the principle of whatever method you may use in the process, understanding the problems and the objectives before working on it
After understanding the problems, usually your next step is to land on Google, start to search for some inspiration, competitor’s product, or any other products with same functions. Then you start sketching your ideas, doing some wire-frames…
But that is not a good way to start a project. Yes you can do research on those matters, but as soon as you do it, you may fall into early conclusion about your design direction. We should avoid doing that.
<h3>1. Instead of Research on Google, do Research from Users</h3>
(Research)
This is the very first steps that any design process will need. Start thinking about your users. Who are they, where are they from? Where can you find them? Take a look at all the requirements, and list out the questions about things that is still in doubt, even things that you are sure about then give it to the users.
You can use many available tools to do survey, collect ideas from users. There is not always good ideas, but there will be some really good ideas come from the users. It&#8217;s an unlimited source of ideas. I&#8217;m not getting deep into the user research and survey, take a look of these articles for more understanding:
<ul>
<li><a href="https://medium.com/@userfocus/60-ways-to-understand-user-needs-that-arent-focus-groups-or-surveys-8510e13b3408">60 ways to understand user needs that aren’t focus groups or surveys</a></li>
<li><a href="https://uxdesign.cc/ux-tools-for-user-research-and-user-testing-a720131552e1">UX Tools for User Research and User Testing</a></li>
<li><a href="https://medium.com/@userfocus/the-7-deadly-sins-of-user-research-22857c5a971b">The 7 Deadly Sins of User Research</a></li>
</ul>
<h3>2. Build User Persona</h3>
(Analysis)
Great, so now you got some first data about your users, what they need, what they expect. The next step is to summarize those users into user persona, you may get 2, 3 or more personas from what you collected. But wait, what is a persona?
<blockquote>“Personas are fictional characters created to represent the different user types that might use a site, brand, or product in a similar way.” <a href="https://en.wikipedia.org/wiki/Persona_(user_experience)">Wikipedia</a></blockquote>
<blockquote>“The purpose of personas is to create reliable and realistic representations of your key audience segments for reference”. <a href="http://www.usability.gov/how-to-and-tools/methods/personas.html">usability.gov</a></blockquote>
These 2 sentences can simply explain what persona is and why we need persona. We will build our product bases on those personas. Creating solutions for the needs of those “people” — our targeted users. However, as soon as the personas get its reputation in the UX design industry (it also was created to solve Marketing purposes), I found out that some designers only care about creating fancy and colorful persona, putting some unrelated information. In my opinion, the user persona for UX design process is different from one for Marketing. Our user persona focuses on delivering the user goals, the pattern and often represent a group of people sharing similar goals and their obstacle that prevent them from achieving their goals — which is our product’s main purpose. We also include some specific points of the users that are related to the requirements of our products. By that we can create design that serves different types of users. So don&#8217;t just pull off any persona template on the web, build a real persona based on the data you collect, base on the user research, surveys you did in the first step.
<blockquote>A <a href="http://www.uxbooth.com/articles/personas-putting-the-focus-back-on-the-user/">persona</a> is a representation of a user, typically based off user research and incorporating user goals, needs, and interests.</blockquote>
<blockquote>Design personas focus on user goals, current behavior, and pain points as opposed to their buying or media preferences and behaviors. They are based on field research and real people. They tell a story and describe why people do what they do in attempt to help everyone involved in designing and building a product or service understand, relate to, and remember the end user throughout the entire product development process. Design personas are good for communicating research insights and user goals, understanding and focusing on certain types of users, defining a product or service, and avoiding the elastic user and self — referential design.</blockquote>
<blockquote>Source: <a href="http://www.uxbooth.com/articles/creating-personas/">uxbooth</a></blockquote>
Here is some good resource for you:
<ul>
<li><a href="http://www.uxbooth.com/articles/creating-personas/">Creating Personas | UX Booth</a></li>
<li><a href="https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/">A Closer Look At Personas: What They Are And How They Work | 1</a></li>
</ul>
<h3>3. Create User Stories/Scenario Map/Sitemap</h3>
(Analysis)
Now is the time to bring in the team. We had personas, we have user insights. Let’s get the party start.
The reason to let the team in; team here includes: visual designer, UI designer, probably any designers, product managers, the VPs, developers, QA also can join at this stage; is to give a chance to everyone to understand the products at the very beginning, <a href="https://medium.com/@jaf_designer/why-product-thinking-is-the-next-big-thing-in-ux-design-ee7de959f3fe#.hbhsn490p">everyone owns the product, not only PMs</a>. You may think it does not need to do this at this stage because it will take a lot of time, but it’s just not that much of time later on when you are in design phase and some PM suddenly ask a random question about why we go with that color? To prevent confusion and make sure everyone is clear about what we build and what is our goal, you always need to include people from the early step.
Even more than that, someone even says it’s the agile era, design sprint and you need to be flexible so don’t stick with just some solutions at the beginning like this. To answer this we have backlogs as a solution. I’m sure that when doing brainstorming together there are a lot of crazy ideas and solution that you don’t want to throw away, put them in backlogs, so we can have a look later, or treat it as a future plan.
<h4>Create Scenarior Map</h4>
So now you just convinced everyone to join, I believe the team is very exciting and eager to join (however team should have around 10 people is perfect). Show them the user insights and the user personas. Ask everyone to define the goals for user, based on our product requirements, write these goals into separates notes and stick it on your brainstorming board like this:
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*OqWDjN0gKVLHKrNthnEWQA.jpeg">
No! just kidding, this is too much! Here is better:
<img alt="" src="https://cdn-images-1.medium.com/max/960/1*LPYbWkMylPPy45P5rN5CSQ.jpeg">
The important thing is to stick your ideas to the user personas. Keep them closed together. Don’t need to make any fancy cool looking board, just keep it simple.
What you are doing is to try creating a Scenario Map for each user story. Every users has a goal to achieve, the team needs to define the step that the user will go through to get to the final goal. An example of Scenario Map I created for redesigning a Career site:
<img alt="" src="https://cdn-images-1.medium.com/max/820/1*2GKmT-6LM-nxQdZrNnwUfA.png">
The blue note is the action user needs to perform, the yellow one is the idea of everyone in the team to solve or explain how the website help user doing the action.
You can see this is a quite simple task, but it’s just a very simple scenario for a user that already known his/her intention and how to achieve the goal. But there will be many different user personas (that you already researched) and so will be more different user stories and scenarios. And the task of the team is to find a simple way for those users to complete their goals. Try putting those scenario map together and at the end you can see the big picture of your product.
Here are a great resource about Scenario Map:
<a href="http://www.uxforthemasses.com/scenario-mapping/">A step by step guide to scenario mapping &#8211; UXM</a>
There is more things to cover when you dig deeper in these processes, they are all belongs to Information Architecture, you are building the flow for you data and how to drive user from start to finish. These are just basic steps, you may have different approaches depends your product requirements.
<h4>Create User Flow</h4>
One additional step is to create the user flow, when the product is big or involves many data from different sides, you also need to create the user flow. Again, try to simplify the flow, but not too simple, you want your user to going through a smooth, easy but clear flow, hence create a better experience
<a href="http://conversionxl.com/how-to-design-user-flow/">Build it with the user in mind: How To Design User Flow</a>
<h4>Build the Sitemap</h4>
If you are designing a website, next is to create a sitemap. I think you all know about sitemaps, it was born before UX design was cool. Every website needs a sitemap, for the user who gets lost. And you need a sitemap for a great product that can prevent user from getting lost. Based on the scenario map and the user flow, create a page for one or some main tasks, link it together. If you are designing for apps, create something similar like screens flow, a collections of screens connected together. Then you can proceed to next step
<h3>4. Start creating Wireframes and Interaction Prototypes</h3>
(Design)
Now come the most fun part from our sides, the more UX design things. Nothing better than something that give everyone a first visual impression about the products.
Many designers like to do high fidelity wireframes, but in my process, let’s stick the lo-fi first. Reason is you don’t want to spend much time on drawing, but to spend more time on exploring the designs. Wireframes help you to do that. Don’t think too much about the pixels, how big or small the text, you just want to explore different design approaches and see what is the best solution. You can try <a href="http://www.gv.com/sprint/">design sprint</a> at this step, it is a very good method for quick but high quality result. The main point of wireframes is to let everyone gives their idea, exploring options and once everyone agrees on one, we can start further design without any changes or confusion.
I was very scared when I received feedbacks from a developer when I export mockup to Zeplin, just because the developer was not involved in the design process. So discuss with them, on the wireframe, see the technical issues that may appear (will appear), solve together as a team and when you jump to real design, you will find it’s fast and clear.
What tools should I use?
For finding ideas, paper and pencils are enough. For more details and put into prototype, I prefer Sketch as my main tool, or Adobe XD (Experience Design). It’s also helpful when you start doing mockups and UI. Sketch also has many available plugins for Marvelapp, Invision, or using mirror tool to see the design right away on your mobile.
There is a lot more things to discuss in this step. Basically it depends on how you and your team wants to do. You can follow design sprint to get quick design, and enhance it later. Move the designs to prototype tools and see if it really works. At this point you can bring the prototype to the real users, do some test and see how they react, fix and create a new prototype, bring to user again.
I believe this is the most fun part but also the most messy part. You will have many versions, many options, people will put more feedbacks, more comments, and usually everyone may get lost for what they wanted to do at the beginning. Stay closely to your first User persona, remember we are still building a product for users. Of course we all have a business objectives, but the product is for users to achieve that business objectives.
<h3>5. UI, visual design and deliver</h3>
Once done with the wireframes, prototypes, the UI guys start doing the rest of the jobs.
However, this UI part is quite complicated to get it right. Reason is some startups are not trying to do much works at their first or beta release. But later on, UX and UI need to stay very closed with each other. UI is about beauty, UX sometimes has different approach, so the two needs to agree on each other. Be strict on colors, spacing, padding, font size. What we often did is to create a UI style guide, a good way to keep consistency of designs. The UX part is not finished here yet, we still need to think about the usability of each UI elements (form label placements, buttons size…). The UI style guide is a main part of design work later on. Hence it needs human effort to maintain, improve time after time. So make sure your UI and UX works well together, easy to maintain and always be consistent.
<a href="http://alistapart.com/article/creating-style-guides">Creating Style Guides</a>
<h4>Delivery to developers</h4>
I recommend using <a href="https://zeplin.io/">Zeplin</a> as a tool between designers and developers. Zeplin helps developers see details of design without open the design files, hence makes life of designer easier. Designers just only need to make the design pixel perfect, follow guidelines strictly and export all to Zeplin. It supports Android, iOS and Web design. More importantly it&#8217;s free for small project. Give it a try and you will love it.
<h3>6. Metrics Analysis</h3>
(Validate designs)
So finally developers finish the first version of our awesome application, let’s roll out to users. Here comes our important part of the job, validate the design. We need to use analytic tools to track how users use our product, how they interact, can they get the goal that we want them to? If not, what is wrong?
For big UX team, they always have a UX Researcher who will do this work. Their task is to test new designs, analysis all the data from users using our products, then give the solutions, recommendation to improve the function, design.
This is also a huge topics, here are some resources that help me cover this part as always:
<ul>
<li><a href="http://adaptivepath.org/ideas/ux-metrics-for-noobs-and-skeptics-an-interview-with-richard-dalton/">UX Metrics for Noobs and Skeptics: An Interview With Richard Dalton</a></li>
<li><a href="https://www.smashingmagazine.com/2011/09/how-metrics-can-make-you-a-better-designer/">How A/B Testing And Analytics Can Make You A Better Designer</a></li>
<li><a href="http://alistapart.com/article/beyond-goals-site-search-analytics-from-the-bottom-up">Beyond Goals: Site Search Analytics from the Bottom Up</a></li>
</ul>
<h3>Final Words</h3>
With our products continue to grow, we will repeat what we did from the first step, research, then analysis, then design, then validate it. This is one of the common process any digital background organization will use. Depends on how big your team and how early your product is, you will find some different approaches or scale. There are also different challenges when the product grows big enough, such as how to maintain designs, how to keep the process useful when team is bigger and product is getting more complicated etc. I just gave you a first impression of how the UX design process is. Thanks for reading and give me comments for what you disagree. No comment? how about a recommendation, this is how you can do it:
<img alt="" src="https://cdn-images-1.medium.com/max/725/1*L-UrDWXiwdc5hHgjzlRDjg.gif"><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=55af4ab5665e" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/a-common-product-ux-design-process-55af4ab5665e">6 Steps in A Common UX Design Process</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

6 Steps in A Common UX Design Process

Top Stories