Key Steps To Know for the UX/UI Process
I can’t speak for everyone’s experience towards writing papers, but I will say that I really appreciate the effort my English teachers put into teaching me the benefits of rough drafts. Alas, I have hardly used them since. I always started on the final, with maybe a little editing and whatnot. In my mind, I called this efficient, in my teacher’s minds — a procrastinator. Still debatable.
Well, design doesn’t work that way. At least not when starting out.
You have to go through the steps of brainstorming, writing a rough draft, editing, re-writing, re-brainstorming, etc. You should be an expert on what you want to create before you even touch the final draft, otherwise, you’ll end up wasting time and effort.
Note: I refer to different screens as pages a lot, and interchange the two often, even though some projects may not even be digital.
This process is a rough outline of how projects go for me when I’m designing. It’s not going to fit every project in every company, but overall, you should be hitting these steps at some point. The examples come from the website redesign we did for our company around last summer, so even since then, things have changed!
Also, I know some people skip right to the wireframes or high fidelities, and if that’s your style, more power to you. But for those a little less experienced, it’s better to do your research and get familiar with the vision before putting anything down.
1) Researching Your Audience
Just like writing a paper, you start off with your research first, right? Really get to know who you are making the product for —it’s not necessarily your direct clients, but perhaps the users of your clients. What problem are they trying to solve?
Ask if you can read the Product Requirements Document, or if you’re involved in writing it up, spend some time interviewing your client and getting a good idea of their customer base. It’s also good to look at their competitor’s sites for a gauge on the market, plus you can get some design inspiration that way.
Think demographics — age, country, accessibility, etc. Consider being in your user’s shoes and the sorts of things you’d want to accomplish from the application. What aspects could be made easier? What are the most important functions?
Create user profiles, name them “Tom” or “Martha” and give them actual personalities. Refer back to these profiles when you’re designing the initial wireframes and when you’re in the User Research phases.
As you’re researching, you can also create an inspiration/mood board of all the things you find. This will come in handy later during mockups!
2) Define End User Goals
Start at the end and figure out what you want your user to accomplish. Are they clicking purchase? Hitting that share button? Always keep the final goal(s) in mind, otherwise you risk getting lost in additional features along the way. If a new button isn’t going to help the user, or worse, will impede their journey towards the goal, then don’t include it.
Much like anything else in life, creating more distractions will keep you away from accomplishments, so stay focused during the process by constantly referring to the goals you set.
Keep them pretty simple too. See if you can condense some of the activities together if they start to get too specific. If your goals include “user should enter email for subscription service” or “user should follow us on Facebook,” rephrase the two into “user should interact and participate in company updates,” or something likewise.
3) Create a User Journey & Information Architecture
Maybe these should be separate steps, but I usually end up combining them together. A user journey goes through the different courses of actions that your user can take. So it might be the flow for signing up, or for checking out a cart. I stick with the UML Activity Diagram format, but use whatever visuals make the most sense to you.
Now, the information architecture is the hierarchy of your product and shows the general layout of the screens. Kind of like a big flow chart, it should go over each page and its purpose. Examples could be a home screen, a contact form, a blog, etc.
You could also add in a stage of user testing here, if possible by doing card sorts to help with categorizing pages. I talk about user testing later on, but honestly, you can insert a test into any step you think would be helpful.
Your information architecture should support the user journeys and show where each one would start. If you wanted your user to give feedback on their interests, does it make sense to do it on the home screen or in a detail view? Also, keep in mind the number of levels your user has to go through. Don’t hide an important action three or four pages into an application.
4) Prepare the Copy (Text)
There is some debate on whether copy or wireframes should come first. You can go with whatever makes sense. Sometimes you do a little copy to insert into wireframes and then go back to finalize the copy after. But for me, I’ve found myself in trouble when I go to high fidelities and realize I’ve made space for more text than I have. Just make sure you do both at some point!
“Content precedes design. Design in the absence of content is not design, it’s decoration.” — Jeffrey Zeldman
Take some time to flesh out the text you want. It should be able to convey the message of your client without any distractions. Don’t fill empty space with fluff because you didn’t plan for it — be purposeful with your words. Your design should support them, not divert from.
You don’t need to have the final copy done (especially if a copywriter needs more time to refine their words), but do think about the gist for each line. Instead of putting filler text everywhere, insert something that would actually make sense going there.
5) Wireframe
Now that you have your building blocks established, you can start formulating the pages together. A wireframe helps you visualize the architecture of your project and focus on functionality. It doesn’t have to “look pretty” just yet. It can be done digitally or even with a pencil and paper. Its purpose is to identify where you’re hitting your user goals.
Does the home page really need a contact form? Or is it repeating what’s on the contact page? Maybe it should just be a link there instead?
Should we use a button or a toggle? What would make sense to the user?
Does the title belong there? How big should it be?
You will probably spend a lot time on the wireframe state, as it’s the first “visualization” of the entire project. And it’s okay if you want to go back and change any other step prior to this one because you identified a new problem. Maybe a new user goal manifested itself when you realized you were lacking a key element. Keep iterating until the pages make the most amount of sense with the least amount of clutter.
6) Create Protocols for Developers
Document the functionalities of your designs! When you hand them off to developers later, they may not know what your intentions were. It’s easier to remember the button and toggle actions now, while you’re still wireframing, rather than later when you have to explain each detail.
Also, developers may start setting up the backend of a project, such as implementing a database or creating the algorithm for some machine learning module you want. Who knows what they do? ;)
This is also a nice stage for brainstorming because your developers may tell you if something is doable or not. Sometimes our ideas get a little ahead of ourselves and while it might be fun, other factors such as deadlines and costs may have to bring them back a little. Work with your developers if you can, they can fill the knowledge gaps you might have!
Lastly, as you continue with your designs, you can refine the protocols as their functionalities become clearer and clearer. Your final handoff should make the dev’s jobs easier, not more confusing.
7) Theme Building (Style Guide)
We’re still not on the fun part?
Yep, you have to figure out a style guide before you start throwing everything out onto the canvas like a Pollock painting. Creating a style guide helps with consistency, from header sizes (hierarchy) to font matching (complementary) to site colors (branding).
It’ll make the low and high fidelity process a lot easier and more efficient. Of course, you can always go back and edit this later on when you realize something else will work better. But it’s better to see things from the big picture before trying to lay it on top of your wireframes. Involve your client in this step as well, in fact, they may already have their own style standards established.
This is something I recently came across in a video by one of my favorite channels, The Futur, but stylescapes are also really popular. They lie between a mood board and a style guide, but give off the general aesthetic and branding of a project. Check out some examples on Behance or Dribbble to see if that’s a step you’d like to add, especially if you’re establishing branding for a company!
Also, use your style guide to create a library, if your software supports it. Since we use Sketch, it makes it really easy to apply a text style to certain headers and whatnot.
8) User Testing Pt. 1
Due to company resources, sometimes you just won’t be able to do two or more user tests, if one at all. However, it’s still good to get some feedback on the wireframes and copy because (I know, I keep saying this) you can focus on the function.
Does this product work? It should make sense even without cues such as color and typography.
Maybe you test the wireframes out on friends and family. Maybe you round up some co-workers and do a group session. Individual tests might give you in-depth knowledge about your site, but it takes a lot of time and I’d save this step for the mockups/prototypes. Group sessions are quick and can give insight to problems that you missed.
This site lets you post your application (for a price, of course) for other people to walk through and test out. Doing a smaller scale test at this stage could benefit the project, but again, it depends on if you have time or not.
Start thinking about analytics too and what sort of data would be beneficial to see if you are supporting your user goals. For example, if a button turns out to not be utilized by users, you can begin to pinpoint if it’s a location or labeling problem. You can coordinate with the developers later on for setting up analytics into the product before launch.
9) Mockups (Low Fidelity & High Fidelity)
Finally, the part that everyone really enjoys right?
You should have a thorough understanding of the entirety of the project at this point. Everything is practically set up for you, so now you can focus your efforts on aesthetics. Add pictures to your heart’s content and play around with opacities and bold patterns — whatever you want.
My point is, the “pretty part” is only surface level. You’ve already done a majority of the design with all of the previous steps. It needs to make sense to the user and fulfill the needs established from step 2 and 3.
Start with low-fidelities, so you add a little more detail but won’t get too invested in a design just yet. Play with color palettes, typography, and layouts until you’ve got 3 or 4 solid designs to present to a client. Then move onto more and more details for high fidelities.
Usually, I do “creative explosions,” as my manager puts it, and end up with about 10 different versions. Some are similar, some are entirely different, but I find that the later versions tend to look better than the first ones.
You’ll probably go thru quite a few iterations this round too, until the client feels it is just right. Notice how it’s not when you are happy with it? Although, I’d say that we’re harsher critics to ourselves making us more likely the ones that are harder to please.
Some clients will want to get updates weekly, so don’t overwhelm them with too many designs, but also keep them in the loop. Make sure you’re listening to their feedback. And some clients trust your process entirely and only check in every so often. So be flexible and work within the limits of your sanity and their happiness (if possible).
Navigating the client presentation is a blog post for another day, but I’ll end this step with saying that your satisfaction with your project increases by a half-life with each iteration, meaning that you will never fully reach 100%. So stop yourself before you’ve exhausted the design beyond the point of return. Stick with deadlines and stick with your goals.
10) Prototype
To be honest, I don’t utilize this step as much as I should. I typically stay behind on the dev team and help them add in animations and am there to explain all components of my design. However, that isn’t always the case. You’ll have to pass off your work to a different team, who may not understand all the interactions you have planned in your head. Refer back to your developer protocols document, which hopefully, you’ve been updating the entire time.
Prototyping can be useful in actualizing the final product. You can add in animations, screens transitions, etc. Some programs offer really nifty tools for creating more than the standard movements you see. As with any design step, make sure you stay in scope of the project. A little jiggling bubble animation that seems easy in your head might create a lot of overhead for the developers, especially if you make custom animations for everything.
It’s also the closest thing for the client to hold in their hand and play with. They’ll really get a feel for how the application functions and can give great feedback. Plus, a prototype can lead very well into the next step…
11) User Testing Pt. 2
Get the idea that user testing is pretty important? Yeah, this one you’re probably not going to want to skip.
Whether you’ve made a prototype or stuck with your mockups, this is the big test to see how your product will do when (if?) it’s launched to the public. Since you’ve worked on this project, seeing how someone unfamiliar interacts with it will show how intuitive it is to use or not and reveal some blind spots.
Use your user journeys to create tasks for testers to go through. See if they get thru it the way they’re supposed to.
Maybe your new idea for the hamburger menu to a hotdog menu wasn’t well received. Great! Change it up and try again. Also, look for patterns, don’t just change something simply because one person doesn’t like it.
Another thing to not get caught up in, is subjective feedback, such as “I don’t like this color.” Prompt them with why, and encourage them to think out loud. Also, do your best to be as unbiased and influence as little as possible. But if the tester is truly struggling, do move onto the next step. Remember that if the user can’t get through your application, that’s on you, not them.
12) Iterations
Got some results from user testing? Great! Take what they liked/didn’t like and apply it to your designs again. Iterate. Iterate. ITERATE! Use the same websites as before to get users, or test it out on people that you know. Again, stick within your budget.
Sometimes you’ll go all the way back to your wireframes and change those up. That’s okay too. For me, I typically end up staying in high fidelities once I’m there.
Also, make sure your naming schema is accurate and that you try your best to keep files organized. Don’t name it ‘final.version’ then ‘FINAL.version.’ Keep your source of truth updated, and always refer back to if you are accomplishing what you set out to do.
Eventually, you’ll reach that same point again where you’ll need to stop, even if you could go on because face it, you’d probably go on forever. Or it’s just deadline time. (Which shouldn’t happen because you’ve planned well, right?)
13) Release & Maintenance
Congratulations! You made it!
Well, sort of…
Even after you hand over your designs to the developers, there will be plenty of problems along the way because nothing ever goes smoothly. And maybe a couple months later, you’ll look back on the project and realize that it could use another design pass. Plus, there might be new features to add! See what the analytics you’ve collected on it have to say and go from there.
The point is, a project is never really truly over. There are always new things that can make it better as time goes on, and one day you’ll look back and realize that your projects are markers of where you experienced growth as a designer. Which is always a nice motivator when you’re feeling frustrated or down on another project. Keep it up and know that you improve the more you practice!
I hope you found this guide helpful and apply it to your own projects! This is just what I’ve found works best for me, but everyone is different. Eventually, you’ll figure out your own process and maybe write a blog about that too!
