Over the years, I’ve put together a list of UX maxims. I tell my students that whenever I get stuck in a project, whenever I feel helpless or uncertain, these are the things I think about in order to get unstuck. They re-focus me and remind me what I’m really here to achieve.

I’ve also talked to a lot of people who are UXers and/or hire UXers about what makes a UX designer officially a UX designer. In my experience, it really comes down to mindset more than methodology. We are hired based on that mindset and how well we can actualize it through a methodology (Agile, design thinking, Lean, etc) and across people and products.

You are the user’s advocate

I kickstarted 2018 with three projects, and on all three projects, the businesses really could not tell me anything about the user except they existed. The users liked and/or needed their products. They definitely interacted with them through some digital service or platform, and the business hoped that in (re)building this interface more users would come.

I have been a UX designer for 8 years, and this was the state of affairs when I started. I don’t think it stems from any malicious intent, but that businesses and the people in the business are thinking about lots of problems that aren’t necessarily user-centric. And because of that, when they look through the lens of their expertise, they don’t see what I am here to see. Therefore whenever I am lost, whenever I am not sure what I should do, whenever I feel trapped between stakeholder decisions, I return back to the keyword in my title—USER. I am here to remind the business that the user is not some mythical antelope or an amorphous blob of millennials. Rather they are the most valuable aspect of their business, and in the end, best practices, conventions, trends, marketing ploys, and design programs don’t matter if their real-life user doesn’t or can’t or won’t. And that there are interesting opportunities for growth if their users can and do and will!

Know when you are dealing with a fact. Know when you are dealing with an assumption. Know the difference.
Because clients and even teammates can easily have blinders on about the user, it’s imperative to know when you are being told a fact vs. an assumption. In projects where I have very little user data to go off on, this is how I hold the line—by being very clear whether I am building on a house of cards or a solid foundation. Or if in that house of cards, I can find the one stone on which to start doing a good process.

For example, for one of the clients previously mentioned, any user data I received had already been scrubbed by a previous agency; it was already interpreted and as the agency’s goal was different from mine (show engagement is happening as opposed to why engagement is happening), I didn’t trust the numbers. So I backtracked to any metric data that hadn’t been reframed (i.e. the heat map showed the most clicked CTA was the “About Us” which was very, very below the fold). And it was from hard facts like this that I started to build my recommendations for the new design.

You must always advocate the UX process

With UX students who are trying to learn all the tools that help them do good UX, it’s difficult to get them to understand that 90% of their job will actually be advocating for the good UX process. The process isn’t tangible to many clients. Many agencies and enterprises also struggle with the adaptability and complexity of it. And often, they see it as a scenic route rather than a straight path to the solution they told you from the kick-off is what they need. And it’s something I struggle with—I use words interchangeably sometimes. And this is where the methodology is important because it articulates a seemingly nebulous process to people new to working with you.

But even when I’m on a project, even when I’m working with people in the know, even in my most difficult projects, I’m still fighting to do good process—user research, user-driven strategy and user-influenced design. And this is why

Know your restrictions

To do a good UX process, it’s paramount to understand your restrictions—time, budget, scope, team, talent, technology, etc. Based on these factors, your process takes shape, is influenced and evolves. In fact, I was recently asked in a pitch meeting how I know what tool or tactic to deploy, and it’s usually based on what I know the goal is and what the restrictions are. The restrictions shape the pathway to the goal.

That’s why when I get really overwhelmed, tangled and uncertain about what to do next, I return to my restrictions, and from there I can reassess my process and next steps. Because the question isn’t what I’m trying to make but what I’m trying to solve next. And this leads to the very important …

Tackle and define the problem before you attempt a solution

On the first day of class, I pretended to be an entrepreneur who had a GREAT IDEA. I tasked the students to ideate on an Airbnb-like app for alumni of their program. This way alumni would network more and continue to build out their community. Voila! When they were done, I announced that I didn’t need to look at any of their projects to know they had failed. And that’s because they had jumped straight into designing the solution. They didn’t yet understand the problem: Do alumni need an Airbnb-like app to help them network and build a community? Or more specifically, they didn’t know the pain point behind the user’s problem and why that problem might mean that an Airbnb-like app was needed.

But solutions are more comfortable to deal with because they are tangible. When clients have solutions, they know what to build, how much it will cost and where it will fit into their overall business plan. But solutions are worthless unless they solve a sharp and annoying pain point. Often, I’ll be brought into project in which clients have the solution, but it’s my job to backtrack and validate the pain point. Once we know the user’s pain, then we understand the user’s problem. And from that problem, the business can and should create a solution to address it.

Or I’ll often be brought onto a project in which the business made the solution, but they are not getting traction from users. And they can’t understand why. Then, I need to backtrack to that pain point and problem. And then, I need to help the business reshape that initial solution into something that will call to the pain users currently feel.

It’s easy to get excited about features and functions and design, but I always try to ground my UX recommendations in my understanding of the problem. Because the problem exists whereas the solution doesn’t. And that’s what you want to build a product around.

Be the mediator between the business’s goals and the user’s needs

Because of the UX designer’s mindset, we really spend a lot of time acting as a mediator. We want to find the problem, but the business only has so much budget and needs the solution in a month. We want to do good process and do user research, but the VP has already decided (for legitimate or not legitimate reasons) that a marketing campaign tied to a product launch must correspond to the new website.

We walk the line, and it’s our job to find the balance.

Iterate. Iterate. Iterate

Good process is based on iteration. Never expect your first deliverables to be your last. Your work is always an ongoing conversation because UX constantly evolves. It’s a dialogue of this is where we are. This is what we’re doing. This is how it will take us here. And here are our next steps.

UX is a team sport

UX isn’t real without a team. It’s easy to just keep it to post-it notes and whiteboards, but the true UX designer uses their tools to create deliverables that empower the rest of the team. The UX process must get to the developers, the designers, the business stakeholders, etc. You’re here to facilitate it, but they’re here to actually make it happen. In fact, I’ve recently changed my mind about all the “UX (fill in the blank)” roles about the place. I feel what this shows is how UX is finally being owned across all teams and levels, and that’s great because UX should be omnipresent no matter in whose hand a product is. There’s enough UX to UX for everyone.

Prioritize. Prioritize. Prioritize.

You’ve got a lot to juggle. So prioritize. And if it fails, then reprioritize. And if it works, prioritize again.

With thanks to Sarah Dzida.