<< back

I'm MANUEL and this is how I work as a UX LEAD DESIGNER.

I remember the first time I saw that joke. I was in college at a software architecture class. I laugh at that time but without knowing what it meant. I do still laugh about it but this time knowing how serious the issue is and especially how important that last scene is. I would say that this joke makes me realize how often the customer/user is forgotten. Is not about what the customer wants, is about what the customer needs, and in my experience, they usually don't know that answer. As I grew up in my career, it has always been my goal to work with the user in mind, and it got to a point that I shifted my career from software engineer to UX designer.

I made a mistake and didn't save all the photos that showcase how I handle a UX process with clients and users for the projects I have work in the past except for my last experience with CVS Pharmacy. What we are going to do right now to show you how I work is to imagine that someone has hired me to design his solution: A digital wallet.

As with most projects, everything starts with a conversation. I like to know my clients as far as they can let me. I need them to trust me as I need to trust them. I should be able to tell them that something is wrong as they should be able to tell me of something they are not comfortable with. I want to know if they have a clear idea of WHY they want to create this project. I can help them with the WHAT and HOW. I have seen many projects fail just because the client didn't know why his proposed solution existed in the first place.

In our exercise, the following was defined:

The next step is to know how good the client knows his potential costumers/users. Some of them have done marketing research and based their response on the data they got. Others just fantasize with the ideal user who usually doesn't exist. It is also my job to help the client to identify and find the customer in the case is needed. It's really important to know who we are working for.

Questions I make to clients about their customers.

For our fictional project let's assume we found the following:

I usually don't define personas. I don't think they work that well. It's much more beneficial when the client/stakeholder and I find the customer together. It's usually not what they expected and helps them to understand first hand who is buying what they are offering.

Now that we have found our user, let's think of how they can find us. Again, I let the client tell me about its strategy. The usual response is ads. It is not a bad response, is good that the client understands that its product is not going to sell on its own. Word of mouth is another popular response but it is not enough. I try to embrace the client to put his users' shoes. How do I want to find that this product exists? What if I found it but I don't have the time for it? What if it's not for me but I know someone who might be interested?

For our exercise, since we know that our offering is a mobile app, let's assume a situation when the user discovers the product while using his personal computer:

A storyboard showcasing a possible scenario.

When creating the storyboards I let the clients skip some crucial steps (scenes) on purpose. We can see an example in the above picture. The only way Luis could receive an SMS is if he previously gives some information to Robi. Also, the only way the app can open in Luis phone is if he has downloaded it. I like to leave the opportunities for these teaching moments to appear. It makes the client more aware of how something so simple as the previous scenario involves some pre-requisites to be successful.

Now that we have finished our research about the user, it is time for ideas to take center stage. We are about to begin one of my favorites parts of the whole process: Brainstorming. This is where our imagination has no limit at all, there is no bad or crazy thought. This involves a lot of whiteboarding and a lot of sticky notes. The goal is to have a collection of desires we want to see in the final product. The more people (hopefully from various disciplines) participate in this type of exercise the better.

Here's the result of a brainstorming session for our fictional project:

What can I say... Ideation is messy.

In every step of the process, I have shown so far you could face roadblocks. Sometimes the client doesn't feel we are in the right direction and we will need to step back a little and re-visit some stuff that has been defined; but if there's a step that mostly guarantees your work is going to be on hold is when the time to define an MVP (minimum viable product) comes.

The desire of having the most complete product possible at lunch seems like an attractive idea, it is something I'm totally against doing. The more agile the process, the better. I have my theory that the most important thing you should do in the beginning is focused on -The Core-. What from all those notes we have put on the wall are the most important? What is that something the user is going to do constantly? I have an example with the WhatsApp app. That app that allows me to send messages with another person who I know its phone. It also allows me to send voice messages, send photos, send videos, share my location, share other contacts, and many other features; and that's what they are... Features; it is not the most important thing that it does, it is not its core. People appreciate more when you master one functionality instead of being OK on several.

Telling people that we are going to do only the important thing on that wall is tough especially if they are not familiar with the process. It can lead to frustration, anger, and sadness, but this is how we show to the customer that we care, that we want to make it right.

So, how to pick what belongs to the core of the product? In a way the answer is obvious: Everything that is strictly related to the WHY, HOW and WHAT. The rest can go to the features bucket. Once we select the ones that will be part of the MVP. we can proceed to create a user flow diagram.

For our exercise we did the following:

User flow diagram from the start of the app up to the final dashboard.

Creating a user flow is an iterative process. This is also where I start to invite users to validate the work so far. Why this late you may ask? Well, I believe UX is not about what the user wants, is about what the user needs and they only way to find that out is to show them clear and concise proposals where they can tell us they see value in them. Users can understand flows if you guide them through it (moderate test).

Once we have a clear path to follow, It is time to prototype. I'm a fan of low-fidelity prototypes, which at the end they will be refined as wireframes. This is one of the most important artifacts you can build since it is the document every single team member should have access to. It shows what the product managers need to supervise, what the visual designer has to enhance, what the developers need to code, what the testers need to validate, and last but not least, what users are going to get.

Let's have a look at the wireframes we produce for the digital wallet:

You can download a copy of the sketch file here.

We are almost at a point where the product can begin production, but just to be sure we are not going to waste a lot of valuable time (and money), we will ask the visual designers to mask the experience so we can build an interactive prototype, this is something the user can play with on its own and behind the glass we will be closing watching what is he doing. Facial expressions and body language often tell more than the users' words.

Here's a small piece of the interactive prototype for our fictional project:

A simple transition made in invision.

If user testing show signs that something needs to be changed, we will start creating versions of the prototype until we got a satisfying result with users. Finally, we can start production!

One could think that this is where it ends for the UX designer, but I like to think that production is where the role provides more value. We need to be testers of our creation. We need to support those who are building what we design. Sketch, Photoshop and whatever GUI the coder is using could provide different results. Pixel perfect design can only be achieved if we are part of the production team.

We did it! the product has launched, and with the proper marketing strategy, users will give the product a shot. Reviews will come, and we will see bugs or mistakes we missed. This doesn't mean we fail, it's just how it works.

We will want to create usability reports for how users perceive the product. You could create these type of report in with the interactive prototype, but I found more valuable data when the product has launched. This data doesn't lie and point us into what needs to be fixed and its priority.

We finally finish our job you might think. This was just the MVP, remember? It might have taken 1 to 6 sprints to get here depending on how complex was the solution. It is now time to evolve what we created, it is time to enhance it, a true UX designer is just like any user... They always want more.

I want to end this article with my motto that if I'm not wrong comes from furniture designers Charles and Ray Eames: "What works, works. How it looks can change".