UX vs UI: the method to stop mixing them up on a real project
Florent Dabernat
February 19, 2026
3 min read
In this article
Understanding the difference between UX and UI in theory is one thing. Making it real within a team working together on an actual project is another. Here's the two-step method I use when kicking off a project.
A shared glossary before anything else
Before touching a single screen, I always have the team build a shared glossary: UX, UI, IxD, CX, each with a one-sentence definition and an example pulled from the product at hand. It sounds basic, but it's what prevents meetings where two people are defending the same idea in different words, or the reverse.
This glossary doesn't need to be exhaustive. A one-page sheet, shared and read in ten minutes, is enough to align a team for the rest of the project.
The before/after audit
Once the vocabulary is set, the most effective exercise is a mini "before/after" audit of an existing screen. List the positives and negatives, then classify each point: is it a UX problem (the journey, the logic) or a UI problem (the form, the readability)?
A point classified as "UX" is fixed by reworking the journey or the content. A point classified as "UI" is fixed by reworking the layout. Mixing the two wastes precious time on iterations that never address the real cause.
In practice, on a sign-up screen, here's the kind of split you end up with:
- On the UX side: reduce sign-up anxiety with a social-proof message, a clear summary of benefits and a visible link to the privacy policy.
- On the UI side: improve readability with an 8pt grid, AA-compliant contrast, persistent labels and a properly prioritized primary button.
This classification happens as a group, out loud, in front of a projected screen. It takes no more than thirty minutes and saves weeks of poorly framed debate later in the project.
A concrete difference
A sign-up page stays a UI matter as long as you're adjusting its grid, colors and components. It becomes a UX matter the moment you rephrase the promise, cut the number of fields, or clarify the social proof to remove doubt. Same screen, two different kinds of problem.
The UX-vs-UI reflex, day to day
Once this method is embedded, the reflex becomes natural: for every client note or user test, the first question becomes "does this get fixed by changing the journey, or by changing the form?" It's often the fastest question to ask, and the one most often skipped.
To go further on the topic, I recommend two reference reads: The Design of Everyday Things by Don Norman, and Don't Make Me Think by Steve Krug, two classics that laid the groundwork for this distinction long before it became a branding talking point.
Frequently asked questions
-
How long does a before/after audit take?
- For a single screen, budget thirty minutes to an hour as a group. What matters isn't exhaustiveness but clearly classifying each point as "UX" or "UI".
-
Does this glossary need to be redone for every project?
- Yes, even quickly. Every product has its own vocabulary and edge cases; a generic glossary loses its teaching value if it isn't grounded in the team's actual product.
-
Does this method work solo, without a team?
- Yes, the exercise works very well alone: the UX/UI classification remains the most useful part, even without the group discussion that enriches it in a team setting.