top of page

I design things that people use.

I don’t know if this has ever happened to you, but for me, it’s very common to take some things for granted. (And I’m not talking about the importance of being humble.) I’m talking about something I like to call the “obviousness paradox”. This consists of being so caught up in our own life/ environment/ work that we start to think that what we do, or think, is obvious for everyone else, so there’s no need to explain! Right? Wrong.

 

Recently, I became aware that I suffered from this “obviousness paradox” syndrome. By talking with clients, creative directors, other UX designers, and colleagues I noticed that I had been taking my design process for granted. 

 

“It’s all about the user”. That might sound like a big cliché coming from a UX Designer, but I mean it. That is what drives my process because my personal opinion or my client’s opinion doesn’t mean much if it goes against a validated user need. The real talent of a successful UX Designer is in how they search for and discover the right problem(s) before creating any solutions. My process includes Discovery, Research, Structure, Validation, Design, and Delivery.

 

Discovery - I consider this to be the most important phase in the process because during this brief period of time you go from not knowing anything about your client, his business, or his audience to being well-versed in all of the above. And I don’t mean “having some idea”, I mean that you need to get to understand most of it, if not all of it. Otherwise, it will be very difficult for you to achieve quality results.

 

Research - This phase is super important because it will help fill in all the informational gaps by asking the questions for which you still have no answer. You probably noticed that I keep going on and on about getting informed, and this is for a reason. Without specific information to guide the design, you will end up creating something that doesn’t solve a problem, or attempts to solve it but for the wrong audience, or that altogether has no connection to any business goals whatsoever.

Structure - When I get to this stage it means that I’ve got all the information that I needed to clearly define the problem statement, the audience, and the needs and pain points of the target users, among other things. Now it’s time to start building.

 

Validation - It’s paramount that I test whatever assumptions I may have. And right now I have a whole bunch of assumptions in my hands, in the form of wireframes, wire flows, or a clickable wireframe prototype. Now it’s time to test.

 

Design - This is, for many designers, the fun part. You get here once you’ve done all the “UX detective work”, collected information, tested assumptions, and so on. It’s time to give life to your project. I like to start out by creating a visual mood-board, where I collect inspiration that is relevant to the current problem that I’m trying to solve, and to the audience that I’m trying to solve it for. That way I can get acquainted with the standard visual languages used in a set field, for a set audience. This is when I start playing around with your defined UI structures. Start by building typography hierarchies, a color palette, an icon style, and so on to move your design from wireframes to high-res mockups.

 

Delivery - Now you should be ready to hand over your work to the dev team. We all know the drill, so I’m going to make it short. It’s time to prepare all the exportable assets, the style guide, and all editable files. Be involved. Help out the dev team in any way you can, be ready and available to prepare extra assets, to explain how things work, to do QA, and so on. Ideally, the dev team should be soaked in the project’s status and requirements, since they were involved from the beginning. Once the project is launched, I try to do some further testing, and watch over the analytics and other data, like direct feedback. Follow up with the team and see, with the data in hand, how you can further improve the design. And yes! Prepare for round two of the process.

bottom of page