UI vs UX: what's the difference?

In short

UI and UX are two jobs, one inside the other. UI is the surface the user sees. UX is what the user goes through, including everything behind that surface.

I wrote up each term on its own in the glossary: what is UI (user interface) and what is UX (user experience). On this page I explain how the two relate and how they differ. I also explain the "UI/UX designer" title you see in so many job ads.

The summary of a short 2021 video by NN/g's Sarah Gibbons calls the two terms "very closely related". The same summary says they are often mixed up. In my experience that confusion usually comes from a single wrong assumption: that a screen that looks good also works well.

UI and UX in one sentence

UI: how the product looks and how people interact with it. This is very close to the definition in NN/g's Kate Kaplan's 2024 article.

UX: every aspect of the end user's interaction with the company, its services and its products. Don Norman and Jakob Nielsen wrote that definition in 1998.

According to his NN/g biography, Norman was the user experience architect of a three-person team at Apple called the "User Experience Office". The biography says that was the first time "User Experience" was used in a job title.

Norman and Nielsen explain the difference with a film review site. The interface for finding films can be flawless. But if the database only holds films from the big studios, the experience is bad for someone looking for a small independent film. The screen asked the right question; the product couldn't answer it.

The same article makes another distinction. Usability is a quality attribute of the interface: whether the system is easy to learn and efficient and pleasant to use. User experience is wider than that. I cover usability on its own glossary page.

UI vs UX, under five headings

A table shows the difference fastest. Each row puts the two jobs side by side under the same heading. On mobile the table turns into stacked cards.

The split in the table isn't a hard wall. NN/g's 2026 UX disciplines glossary defines UI design as a combination of interaction design and visual design. That's why what a button does when pressed is a UI decision too.

According to the same glossary, UX design is designing products and services so they are usable, useful and fit for purpose. A UX designer may do interaction design, information architecture, prototyping and some research. The scope depends on the organisation.

Most of the outputs in the right-hand column are separate terms in the glossary. Information architecture is how content is organised; a wireframe is the rough skeleton of a screen. None of these outputs contains colour, but all of them decide how the final screen will work.

An example: a money transfer screen

Picture the transfer screen in a bank's mobile app. The UI questions are concrete. How many characters does the account number field show, does the amount field open a numeric keyboard, is the "Send" button where the thumb can reach it?

The UX questions go beyond the screen. Does the user pick the recipient from a saved list or type the account number every time? Are they told when money sent outside business hours will arrive? Where does the receipt go when the transfer is done, and does the recipient get a notification?

Both sets of questions are answered on the same screen. The difference is where the question comes from. UI questions come up when you look at the screen; UX questions come up when you look at what the user is trying to get done that day.

In this example one mistake touches both sides. When the user types the wrong amount, the screen should catch it before the money is sent. Nielsen's fifth heuristic calls this error prevention. How the error is shown is a UI decision; how the flow is built so it never happens is a UX decision.

The same screen, two states

A quick way to see the difference is to put two screens that do the same job side by side. In the example below the job is the same: booking a cardiology appointment at a hospital. The first state looks nicer; the second one gets the job done better.

The same screen, two states

State 1: beautiful UI, bad UX

Your health is our priority.

1

Three icons with no labels.2

Your patient ID number3

dd/mm/yyyy

Submit4

1. The headline and decoration take up the top half of the screen. The booking fields get pushed down and aren't visible at first glance on a phone.
2. The icons have no labels. The user has to guess which one is appointments and which one is test results.
3. The field's name sits inside the field. It disappears when you start typing, so the user can forget what they were entering.
4. "Submit" doesn't say what is being submitted. The chosen day and time appear nowhere on the screen.

State 2: plain UI, good UX

Book an appointment

Step 2 of 3

1

Cardiology clinic. Change

2

Date and time

12 November, 10:30 (selected)12 November, 14:003

Confirm appointment: 12 November, 10:304

1. The heading names the task. "Step 2 of 3" shows the user where they are.
2. The clinic chosen on the previous step stays at the top. If it's wrong, one tap changes it.
3. The field's name sits above it and doesn't disappear. The options are written out and the selected one is marked.
4. The button repeats the date and time, so the user can check one last time before tapping.

A made-up hospital booking screen, not taken from a real organisation. Pick one of the two buttons above: the screen and the numbered notes beside it change together. Without JavaScript both states show one under the other.

None of the problems in the first state are about colour. Unlabelled icons go against Nielsen's sixth heuristic, "recognition rather than recall". The "Submit" button doesn't show the choice, which goes against the first heuristic, visibility of system status. I cover all the heuristics with examples on the Nielsen's 10 heuristics page.

The second state isn't ugly either. It just doesn't put decoration before the task. Nielsen's eighth heuristic calls this "aesthetic and minimalist design": an interface shouldn't contain information that is irrelevant or rarely needed.

Why a beautiful screen scores well even in testing

The first state may even be liked in a user test. There's a name for that: the aesthetic-usability effect. NN/g's Kate Moran describes it as people's tendency to perceive attractive products as more usable.

The effect comes from a 1995 study at the Hitachi Design Center. Masaaki Kurosu and Kaori Kashimura tested 26 versions of an ATM interface with 252 participants. Participants' beauty ratings matched how easy they thought the screen was more than how easy it actually was.

The warning in Moran's article matters more to me. Attractive design makes people forgive small problems, not big ones. In a test you should look at what the user does, not what they say.

What this example doesn't show

The two states in the demo compare a single screen. The real experience continues before and after it. If no reminder text arrives after the user books, the second state is part of a bad experience too.

The reverse is also true. If the front desk sends you to the right floor when you arrive at the hospital, a small flaw on the screen won't stick in your mind. That's why, when I measure UX, I look at every step from the start of the task to the end, not at a single screen.

How it relates to product design

Job ads show a third title too: product designer. According to the NN/g glossary, product design in software means designing a digital product end to end. A product designer thinks about business goals, product strategy and users together.

The same glossary says the title "product designer" is often used for work similar to UX design. The difference is the focus on a single product. At some companies a product designer is responsible for more than the interface or works more closely with the product manager.

I think of the three concepts as nested boxes. The drawing below isn't a standard; it's the map in my head.

User experience (UX). The whole of a person's relationship with a product, service or organisation.

Product design. Designing a digital product end to end, together with its business goals, product strategy and users.

Interface design (UI). The components on screen and how they behave.

Interaction design: what you press, and how the system responds.

Visual design: line, shape, colour, grid, space.

Product design also gets confused with product management. The glossary separates them: product management decides what to build and why. Product design designs how it will work for the user.

Who decides what

In a small team these decisions are made in the same meeting. Still, knowing whose decision is whose shortens the debate. The split I use on projects is roughly this:

• Product manager: which problem are we solving this quarter, and why that one?
• Product or UX designer: in what steps will the user finish this task, and what information will they need at which moment?
• UI designer: with which components, in what layout and with which states will these steps appear on screen?
• Developer: how long will this take to build, and within what technical limits?

If a role is missing, its question doesn't get asked. In a team without a UI designer, for example, empty and error states are often added last, in a rush. If nobody asks the UX question, the screen is drawn nicely but sits in the wrong place in the flow.

If the product is still new, most of these decisions are made on an MVP. At that stage, seeing whether the core flow works gets you more than polishing the interface.

What a UI/UX designer does

"UI/UX designer" is the name of a role where the same person does both jobs. They work out how the user will finish the task and also draw the final screens. I see this title most in ads from small teams.

The title has no single definition. The NN/g glossary says titles in the field aren't standard and the same title can mean different things in different places. In NN/g's UX careers survey, respondents reported 134 different UX-related job titles.

In my experience a UI/UX designer's week is roughly made of these:

• Understanding the problem. What does the team want to solve, and where do users get stuck? They look at analytics, read support tickets and talk to users if needed.
• Drawing the flow. They list the steps a user takes to finish a task and drop the unnecessary ones here.
• Building the skeleton. They prepare wireframes and a clickable prototype. There's no colour at this stage, only layout and content.
• Designing the interface. They place components, colour and type according to the design system, and don't forget the empty, loading and error states.
• Testing. They give the prototype to a few users and watch where they hesitate, then fix what they found in the next round.
• Working with developers. They check that the design makes it into the code correctly and solve the edge cases together.

At large companies each item on this list can be a separate specialism. The NN/g glossary also says plainly that one person may do the work of several disciplines. In a small team, "UI/UX" means all of this gets finished at the same desk.

Ads that lean UI, ads that lean UX

Two ads with the same title can ask for very different work. When reading one, the list of duties tells you more than the title.

If the duties mention "design system", "components", "icons" or "marketing visuals", the ad leans towards UI. If they mention "user interviews", "flows", "testing" or "metrics", it leans towards UX. If both are balanced, it's a real UI/UX role.

There's good news for people coming from screen design. The summary of NN/g's Rachel Krause's 2019 video says someone who draws strong screens comes to UX with a good start. It adds that succeeding in the wider role takes more than that. In my view what's usually missing is research and thinking in flows.

Common mistakes

These are the mistakes I hear most often in audits and first calls.

"UX is just a cooler name for UI." It isn't. UI is the screen itself; UX covers the email, the text messages, the call centre and the delivery as well as the screen. Kaplan's article separates them clearly too.

"If we repaint the screen, the problem is solved." If users get stuck at checkout, the cause is usually in the flow. In the $300 million button story the problem wasn't the button's colour either; it was the sign-in and register screen that came before payment.

"I designed a website, so I'm a UX designer." Kaplan's article is clear on this: designing a single product such as a website doesn't always make someone a UX designer. UX is work that focuses on people more than on technology.

"Users liked it, so it's usable." The aesthetic-usability effect describes exactly this mistake. Liking and success are measured separately.

"UX gets added at the end." Looking at UX after the screens are drawn is like questioning the foundations once the building is finished. Flow and content decisions come before colour. That approach is called user-centred design.

"UI doesn't matter any more, AI draws it." NN/g's 2026 report says something more balanced. UI still matters, but it will be less and less of a differentiator. According to the report, as AI design tools improve, anyone will be able to make an interface that looks decent, at least from a distance.

"If we have a design system, we don't need a UX designer." A design system says how a button looks, not which screen it should be on. NN/g's 2026 report also says someone who only lines up components from a design system is already replaceable by AI.

"UX is only for mobile apps." User experience exists wherever there's a screen. A council website's application form and the ticket machine in a bank branch both create an experience.

My note

Most of the work that comes to me starts with "let's refresh the screen". I ask the first question: where do users give up? The answer is usually not in how the screen looks but in the order of things.

That said, I don't look down on UI. Button text nobody can read, or an error message in the wrong place, breaks the experience directly. A good flow gets lost on a badly drawn screen too.

That's why I don't like splitting the two jobs between teams. When the person who does the research also draws the screen, nothing gets lost between the finding and the screen. That's how I work.

If you want to know which of these two states your product is in, the shortest way is to look at a flow from the outside. I explain how, step by step, in the UX audit guide.