User experience (UX) is a person's perceptions and responses that come from using, or expecting to use, a product, system, or service, as framed in ISO 9241-210:2019. It spans before, during, and after use, from expectations and emotions to what the person actually gets done.
The standard itself sits behind a paywall, so the wording here follows how academic sources cite it (REPORTED). Its value is simple. It treats experience as something the person has, not something a screen displays. That shift matters, because most teams judge UX by what their systems record: a task finished, an order placed, a score that turned green. Each of those records proves less than it seems.
Read closely, the ISO framing does two things. It ties UX to the use, actual or anticipated, of something specific. And it stretches the time window well past the moment someone taps a button.
Experience starts before the first click. A person arrives with expectations shaped by an ad, a recommendation, a past visit, or the search intent behind the query they typed. If the landing page answers a different question, the experience has already gone wrong, even though nothing on the page is broken.
During use, the questions get practical. Can the person find what they came for, understand the choices in front of them, operate the controls, notice an error, and recover from it? After use, the experience keeps going. A confirmation email that contradicts the checkout page, a receipt with a different total, or a guarantee nobody can locate all belong to the same experience, because they come from the same use of the same service.
The ISO anchor also sets a practical boundary. UX stays attached to the use of a particular product, system, or service. Questions about the wider relationship between a customer and a brand, across every channel and over years, belong to customer experience rather than UX.
People mix these three terms up all the time, so this table compares them by the question each one answers, how much it covers, and how you measure it.
| Term | Question it answers | Scope | How to measure | Label / source |
|---|---|---|---|---|
| User interface (UI) | What is the layer the person actually touches? | Screens, labels, buttons, and feedback. | The entry gives no UI-only measure. A polished visual refresh changes the UI, but the task gets no easier if the flow still asks for the same information twice or hides the shipping cost until the final step. | Glossary analysis (no external source cited) |
| Usability | Can a specific person get a specific task done with this interface, in a specific situation? | One task, one person, one context. Usability can be strong while UX is weak: people can finish a form quickly and still not know what they agreed to. | Usability benchmarking records, for each task, whether the person completed it, how long it took, whether they gave up, and whether they thought they had finished when they had not. Participants also rate how difficult each task felt. | GOV.UK Service Manual, usability benchmarking (VERIFIED) |
| User experience (UX) | How did the person perceive the whole use, before, during, and after? | Perceptions and responses from using, or expecting to use, a particular product, system, or service. This covers expectations going in, whether the result matched them, and what the person thinks afterward. The wider relationship with a brand belongs to customer experience. | Watch actual and potential users try real tasks, then ask three questions. Did they finish? Did they finish what they meant to do? Would they say it went well? Analytics answers only the first. Test again after each change. | ISO 9241-210:2019 (REPORTED); GOV.UK Service Standard point 4 (VERIFIED) |
These three terms get swapped constantly, and the swap causes real mistakes. The user interface (UI) is the layer of screens, labels, buttons, and feedback a person touches. Usability asks whether a specific person can get a specific task done with that interface, in a specific situation. UX is the widest of the three. It includes how the person felt going in, whether the result matched what they expected, and what they think of it afterward.
The distinction has teeth. A polished visual refresh changes the UI, but if the flow still asks for the same information twice, or hides the shipping cost until the final step, the task is no easier. Usability can be strong while UX is weak, too. A form people complete quickly can still leave them unsure what they agreed to. Treat the three as one thing and teams end up fixing the layer they can see instead of the layer that failed.
Most UX failures are not dramatic. They are small barriers that some people get past and others cannot, and two of them show up on almost every site: accessibility and performance.
If a person cannot read the text, reach a button with a keyboard, or tell which form field needs what, they do not have a slightly worse experience. They have no experience of the task at all. Accessibility is UX for the people a design forgot to plan for.
Automated data shows how wide the gap is. WebAIM's 2026 analysis of one million home pages found detectable WCAG failures on 95.9% of them, an average of 56.1 errors per page, and low-contrast text on 83.9% (WebAIM Million 2026, global home page sample, automated testing, VERIFIED). Within the same dataset, the 15,161 pages written in Indonesian averaged 72.5 errors, 29.2% above the overall average (WebAIM Million 2026, Indonesian-language page subset, VERIFIED). That is a finding about pages in one language, not about any country's users.
Those numbers come with a limit that WebAIM states plainly. Automated tools catch only some failures, and a page with zero detected errors has not been shown to be accessible or WCAG conformant. A clean automated report is a floor, not a finish line. The same principle has reached a regulator. An accessibility overlay vendor was barred from claiming that its automated product could make any website WCAG compliant without evidence to back the claim (U.S. Federal Trade Commission final order, April 2025, REPORTED).
Speed is part of experience in a very direct way. A page that renders slowly, ignores a tap, or shifts its layout as an image loads makes the person wait, mis-tap, or start over. Core Web Vitals turn three of those moments into field metrics: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability.
Measurement coverage changed recently. According to web.dev, LCP and INP became measurable in all major browsers once Safari 26.2 shipped on December 12, 2025, while CLS was still not supported outside Chromium-based browsers (web.dev announcement, December 17, 2025, VERIFIED). The same announcement notes that the Chrome User Experience Report draws only on eligible Chrome users and will keep doing so, and it points to real user monitoring for data from other browsers. A site with a large share of Safari visitors should not read Chrome field data as the whole picture.
Internal opinion is the cheapest UX research method and the least reliable one. The people who built a site know where everything is. They cannot unlearn it.
The UK government's Service Standard asks teams to test for usability frequently with actual and potential users, and to design so that people succeed the first time (GOV.UK Service Manual, VERIFIED). The operative word is test. Asking people whether they like a design produces preference data. Watching them try to complete a real task produces evidence about whether the design works.
Picture the gap in a single study. In an interview, a participant says the navigation feels fine. In a task session, the same participant opens three wrong menus before finding the returns policy. Only the second observation tells the team something useful, and the fix it points to is often not visual at all. It may be a clearer label, a page placed where people expect it, or better internal linking between pages that answer related questions.
GOV.UK's guidance on usability benchmarking turns observation into something repeatable. For each task, it records whether the person completed it successfully, how long it took, and whether they abandoned it or believed they had finished when they had not (GOV.UK Service Manual, usability benchmarking, VERIFIED). Participants also rate how difficult each task felt.
The method is a loop. Benchmark the important tasks, change what the results point to, then run the same tasks again in a later round to see whether the change helped. The guidance advises repeating the process periodically rather than once. One round is a snapshot. A series shows whether the service is actually getting better.
That third measure, people who think they succeeded but did not, is the one most analytics setups never capture. It leads straight to the central argument of this entry.
Problems reported by people in the EU who had already completed at least one online purchase in the previous three months, from Eurostat's 2025 survey.
| Problem reported | Share of respondents | Who was surveyed | Source / label |
|---|---|---|---|
| Website was difficult to use or did not work satisfactorily | 11.5% | People aged 16 to 74 in the EU who bought online in the previous three months | Eurostat, EU, 2025 survey (VERIFIED) |
| Difficulty finding information about guarantees or other legal rights | 8% | People aged 16 to 74 in the EU who bought online in the previous three months | Eurostat, EU, 2025 survey (VERIFIED) |
| Difficulty with complaints or redress | 6% | People aged 16 to 74 in the EU who bought online in the previous three months | Eurostat, EU, 2025 survey (VERIFIED) |
| Faced costs higher than those indicated | 5% | People aged 16 to 74 in the EU who bought online in the previous three months | Eurostat, EU, 2025 survey (VERIFIED) |
| How to read these figures | Do not add them up | One shopper can report several problems, and none of the four figures is a conversion metric. Every respondent still completed at least one purchase. | Glossary analysis |
Completion is the metric teams trust most, because it is easy to count. The evidence suggests it hides a good deal.
Eurostat surveyed people aged 16 to 74 across the EU who had bought something online in the previous three months. These are people who did buy. Even so, 11.5% said a website had been difficult to use or had not worked satisfactorily (Eurostat, EU, 2025 survey, VERIFIED). In the same survey, 8% reported difficulty finding information about guarantees or other legal rights, 6% reported difficulty with complaints or redress, and 5% said they faced costs higher than those indicated (Eurostat, EU, 2025 survey, VERIFIED).
None of these four figures is a conversion metric, and they should not be added together, since one shopper can report several problems. Now read them against an order log. Behind each of those answers is a person who still completed at least one purchase in the period. The record says success. The shopper's account says something else.
A conversion rate counts events. It cannot tell whether the person understood what they agreed to, found the information they needed, or paid what they expected. GOV.UK's benchmarking guidance names the gap directly by treating people who believe they completed a task when they did not as a failure, alongside those who give up.
So a useful UX review asks three questions about any completed task. Did the person finish? Did they finish what they meant to do? And would they say it went well? Analytics can answer the first. Only research with real users answers the other two. A rising completion rate that arrives together with more support contacts, refunds, or repeat attempts is a signal to investigate, not a win to report.
UX and SEO overlap, but not in the way many audits imply. Google's page experience documentation is specific about what it does and does not claim.
Google says there is no single page experience signal. Its ranking systems use Core Web Vitals, while other page experience aspects do not directly help a page rank higher (Google Search Central, page experience documentation, VERIFIED).
That makes the honest link between UX and search fairly narrow. Better performance can matter for ranking. A better experience in the broad ISO sense is not something Google says it measures directly. Where good UX clearly pays off is after the click, in whether the person finds the answer, trusts it, and acts on it.
Google also states that good Core Web Vitals results do not guarantee good rankings. Once a page is in good shape, chasing a perfect performance score for SEO is a weak use of time. For UX the bigger problem is scope. A green score describes loading, responsiveness, and stability. It says nothing about whether the navigation makes sense, the price is clear, or the form works with a keyboard. A passing score, like a completed task, is a narrow record of a broad experience.
UX is a person's perceptions and responses from using, or expecting to use, a product, system, or service. It covers the time before, during, and after use, which is how ISO 9241-210:2019 frames it.
UI is the interface itself: screens, controls, labels, and feedback. UX is the person's experience of using the product through that interface, including expectations and what happens afterward. A better-looking UI does not fix a confusing task flow.
No, though they overlap. Usability is about whether a person can complete a specific task in a specific context. UX is broader and includes how the person perceived the whole use, before, during, and after.
Observe actual or likely users attempting important tasks. Record whether they succeed, how long it takes, whether they give up, and whether they think they finished when they did not, as GOV.UK's benchmarking guidance describes. Then retest after each change.
Start with the tasks that matter most, watch people attempt them, fix the barriers you see, and test again. Include accessibility checks throughout, and keep in mind that automated accessibility tools catch only some problems.
Partly. Google uses Core Web Vitals in its ranking systems, but it says there is no single page experience signal, other page experience aspects do not directly raise rankings, and good scores do not guarantee top positions.
We use cookies to ensure the website runs optimally and to help us understand how you use our services. You can choose which categories to allow. Read our Privacy Policy.
Required for basic website functionality. Cannot be disabled.
Help us understand how visitors interact with the website. Data used anonymously.
Used to display relevant ads and measure campaign effectiveness.
Enables live chat, social media integrations, and language preferences.