04. How Do You Define UX? Does It Matter?

04. How Do You Define UX? Does It Matter?

If we all define UX differently, how do we build great software?

This topic is something I really wanted to cover early before we get into a lot of other topics because I think it’ll give you an insight into how I frame some of the various opinions I have about the UX profession.

It will also give you an insight into how I might make overall decisions when it comes to my work as a UX professional, how I approach problems, how I approach solutions, and how I approach working with my team.

I want to clearly define our language so we’re all working with a shared understanding later.

So what is UX Design? 

This question is often way more polarizing than I think it should be. And honestly, I think it’s really unfortunate.

I did some digging, trying to get some quotes to use for the show. I found some examples where UX designers describe the craft as something like: “UX Design is the process teams use…” or “UX Design is improving the experience…” or something related to empathy for users, which I do want to stress is really important. 

I found an article on usertesting.com that had 15 experts weigh in on what they think UX design is. Only one of them thought that UX was about solving problems. That kind of blew me away, to be honest. Only one of them! 

There are so many people around today that connect UX design with visual design. As if UX designers are the evolution of web designers or digital designers. Tôme, that implies that in order to be a really effective UX designer you have to be a dribbble god with more likes than anyone else.

And that just isn’t the case.

Or there are a lot of people out there that associate UX design with some specific process where you do a series of things like there is some magical formula for good UX. And while I don’t think that’s necessarily wrong, I have some nuanced feelings on that.

What UX design is not

So Let’s establish what UX design is not first. 

• UX is not visual design or even UI design.
•  UX is not about simply crafting a beautiful interface. 
• UX is definitely not mastering Figma.
•  UX is not color theory or typography.
• UX It’s not even really about data hierarchy. 
• UX is not about design systems. 

All of these things can make or break the user experience, but just mastering these things will not lead to a great user experience. 

Because at the end of the day, UX design is about solving problems for users. If you don’t solve the user’s problems, it doesn’t matter how good any of that other stuff is, it still won’t lead to a positive outcome or positive experience. It just won’t, because the user still wouldn’t have been able to accomplish whatever they set out to accomplish using your tool. 

A beautiful app that doesn’t work for you still sucks. End of story.

So what is UX design?

Before we can dive into what UX design is or what a UX designer does, let’s think about UX more broadly.

Don Norman coined the term “User Experience” in the 90s. What he said was “User experience encompasses all aspects of the end-users interaction with the company, its services, and its products.” Notice he doesn’t mention anything about design, or tools, or processes. It’s all about the end user’s interaction with the company, service, or product.

So basically, UX is the experience a user has. It’s literally that simple. That is what UX is. The experience a user has. Full stop. It’s right there in the name!

So it’s important to remember that when we talk about this other stuff what we’re really talking about are all the things that actually influence the user’s experience.

So when we talk about design systems, visual design, processes, research, tools, whatever, those aren’t UX. Those are processes that influence the UX. They are processes we use to design the user’s experience. 

I want all of the designers reading this to take away one major point from this episode. And that is that what we, as UX professionals, do on our own does not fully make or break a good user experience. There are many other factors outside of our control that may influence the experience a user has. 

What else can influence the experience a user has?

I’ll give you a hint, it isn’t just the interface design.

• The number of bugs in a piece of software can affect the experience a user has. 
• The speed at which the software loads can affect the experience a user has. 
• It’s the environment the user might be in– maybe they have a spotty internet connection or are in direct sunlight, so they can’t read the screen. 
• Or maybe the API you’re trying to connect to isn’t working. 

You may have designed the most amazing, wonderful, award-winning interface. But if any of those things go wrong you’ll end up with a bad user experience. 

At its core, the experience a user has is improved when we solve a user’s problem. If you don’t solve a user’s problem the experience will be negatively affected, because otherwise, what was the point of using the stupid thing? 

I downloaded your software, I created an account, and now it doesn’t even do what I need it to do.

Fail. 

It really doesn’t matter how thoughtfully laid out the interface was. How attractive the typography and color scheme were. As a user, you wasted my time.

• Or I downloaded your software, but there were so many bugs and error messages I couldn’t get it to do what I needed it to do. Fail.
• Or I downloaded your software and it’s not compatible with my computer or phone. Fail.
• Or I downloaded your software, but it would never load because my data is slow. Fail.
• Or I downloaded your software but it doesn’t meet my accessibility needs. Fail.

So a good user experience will only happen when we’ve solved a user’s problem. That’s it.

We need to bring a compelling story to our teams

So how do we know what a user’s problem is? Or if users have accessibility issues, or if the users might have slow data? Well, it’s simple really. We ask them. 

This is why research, qualitative and quantitative together are so important. 

We look at numbers and the numbers give us some insight – that’s quantitative.

Then we talk to them. We get the why behind the numbers. That’s qualitative. 

We understand our users. We build empathy. We create artifacts that help us understand their problems. 

What we design should always be tied back to the research. We don’t design for other designers. We don’t design for dribble. We don’t design for likes. We don’t design for ourselves. We don’t even design or stakeholders.

We design for the users with our main goal to be solving their problems in some way, while obviously working within the constraints we’re giving, understanding the business value, and how it all works together. 

And then the other big part of our job is to share the knowledge and empathy we’ve built for the users. To evangelize on behalf of the users. To get everyone on the team to understand and empathize with the users so they all want to build the best goddamn software they can for those users, because they give a damn too!

So when the product team is thinking about the next feature they put the users first. So when the QA team is testing stories they want to catch as many issues as they can because they care as much as we do. When there are bugs or the APIs are broken, or whatever other technical issue might come up, the engineers want to fix the software because they care as much as us.

A UX designer’s job is to represent the users and to be an advocate for them within our team. Every decision we make and every decision our team makes should be filtered through the lens of the user. Every compromise we make with our product and engineering partners should be made through the lens of the user. 

UX Design is fundamentally about keeping the user top of our minds and solving their problems first and foremost. Otherwise, what is the point of doing any of this?

So personally, I think one of the ways we can be most effective UX designers is by being great storytellers. To inspire the people on our team to want to build the best possible product we can. 

What part does the rest of the team play?

What I want to also stress is that as we’ve defined it, The User Experience is not the sole domain of the UX designer. If we define the User Experience as the experience a user has, then it becomes the responsibility of everyone on the team, from the stakeholders to the product managers to the software engineers, QA testers, etc. to be concerned with the experience a user has. 

The product team and stakeholders have a responsibility to understand user problems, needs, pain points, etc. so they need to work with the proper UX professionals to help conduct research, maybe document it, and maybe talk about this during whatever meetings they facilitate. They have a responsibility to focus on users as they approve roadmaps, look for funding, identify resources, define metrics, or whatever it is they might do.

The software teams like the developers, scrum masters, and QA teams, all need to keep users on top of our minds while writing stories, defining technical requirements or designing the architecture, testing features, etc. It’s not about shipping the bare minimum as fast as possible, it’s about shipping what is right for the user.

Every software team is different. Lots of teams have different names for different roles, so it’s impossible to talk about every role and how they might play some part in the experience a user has, but hopefully, you’re getting the picture here. That UX is something everyone should care about, not just UX designers.

What I want to stress is that the experience a user has is not the sole domain of the UX designer. So many things can play into the experience a user has. UX design is not just the components on the screen. It’s not just the fonts and colors. It’s not just the visual design. It’s not just the copy on the page. It’s not just the load time. It’s not just the number of bugs. 

Really great software teams take all of these things into account and they think about how the user is using the system as a whole.

So to that end, I wanted to give an example of “User Experience” gone wrong and hopefully highlight how the UX design team, and even the entire software team, can do a lot of things “right” by the book but still miss a huge portion of users and end up with a bad experience, regardless of how good the visual design is or how well the same design might work well for a different set of users.

A real-world example

So let’s talk about Calendly. Have you ever used calendly? It’s a really useful app that allows someone to connect a calendar like google calendar and set availability so that other people who want to schedule a meeting with them can see their availability and quickly set up a time to meet where both can make it. It basically cuts out all the back-and-forth emails when scheduling a call or something. I want to set up a meeting with you, I see your availability. I select a time that works for me.

Boom. Meeting.

The thing that’s interesting about this tool is that the interface works really well when I go out and find someone that I want to meet with and they send me their calendly link. I find a time that they are available that works for me. I hit send. We meet. Done. Perfect.

I’ve felt this myself for some time, and it kind of put me off, but it didn’t really hit me until I heard someone on a podcast recently give this same anecdote as it relates to UX. I wish I could remember what podcast this was. I tried going back and looking for it, but I couldn’t find it. So if anyone out there is listening and knows what I’m talking about, please let me know, because I would love to link to it.

Now here’s where something like Calendly completely fails, in my opinion. What happens when I have the calendly account, and I go out and I try to find someone I want to meet with? What happens if they don’t have a calendly link, but I do? Do I send it to them and ask them to find time to meet with me? If I reached out to them, what kind of experience are they going to have with calendly when they hear from me out of the blue, then I ask them to do some work for me, so that I can meet with them? 

I’ve had this exact situation happen to me. And when it happened the first thing I thought was “wait, you’re reaching out to me. You wanted to meet with me. Now you’re asking me to go do some work for you. To set up a meeting. For you to have with me?”

This team could have done everything by the book. They could have had a solid problem statement. They could have done substantial research, solid design, and solid usability studies. I’m sure really talented designers, researchers, software engineers, and product teams worked on this. But they didn’t account for this one thing and now some set of users have a bad experience with their product, and maybe put them off completely to the tool forever. 

Now, I’m raising this example, but I don’t have a solution. I don’t know how to fix this problem, but that’s not the point. The point here is to highlight that UX design is all about investigating every aspect of the user’s journey and solving for those problems to create a truly great user experience.

Obviously in software, there are tradeoffs and compromises. It’s possible this was considered an edge case. And maybe it is. It’s possible this is on the roadmap to address. I have no idea.

Now before I get out of here, I want to stress something. I don’t want to get a bunch of emails from upset visual designers.

I am not suggesting that visual design is insignificant or not important. Visual design will definitely have an impact on the user experience. Bad visual design will definitely negatively affect the experience a user has.

But, if you’re taking away anything from this episode, I hope you come away with the understanding that really great visual design will not save your software from a bad user experience if the software does not solve the user’s problem in the first place. 

I also want to stress that I am not trying to say that “everyone is a designer” or that I am trying to “democratize design” or take design away from the designers. I am simply saying that everyone plays a part in the outcome of the product and any number of things can impact the experience a user has.

It’s not just the design. It’s not just the code. It’s not one thing. It’s all of the things together, which is why it’s critical we work together and build up our soft skills to make sure all the moving parts of these complex systems are working together, smoothly.

So, please do me a favor. The next time you start a project don’t let dribbble be the first place you go. Start with your users and you will have a better product. I promise.

Helpful Links
• What is UX design? 15 user experience design experts weigh in
• What is User Experience (UX) Design? | IxDF
• The Definition of User Experience (UX)