UI is what people see and use on screen; UX is what they go through to get something done. How to tell them apart, and test what users understood.
UI/UX joins two disciplines that work on the same digital product. The user interface (UI) is what a person sees and operates on screen: buttons, words, the order of information, and how each element responds. User experience (UX) is what the person goes through while trying to get something done with a product or service, before, during and after the screen. The interface answers one question: what is in front of them, and what can they do? The experience answers another: did they achieve what they came for, and do they know what happened? The split is close to the one in NN/g’s glossary of UX disciplines.
Imagine an applicant taps “Submit application” in a banking app to open an account. The form disappears and a green check mark takes its place. Can they use the account now, or has the application gone to a team for review? The screen tells them something happened and leaves them to guess what. The example is hypothetical, but it shows the difference: the submit button and the confirmation message are interface decisions, while knowing the status and finding the application again tomorrow is a question about the experience.
What is the difference between UI and UX?
Both disciplines work on the same product, but each starts from a different question. The difference shows when you follow one button from the moment it appears to what happens after the tap.
UI starts with what the person needs to read and do
Consider the review screen just before submission. The applicant sees their name and mobile number, an option to edit the details, and a primary button to send them. The interface designer decides which information comes first, how clearly editing differs from submitting, and what appears while the system waits for a response. Colour is one decision among several. The words on the button and what happens after a tap matter as much.
Suppose the button says “Continue.” That fits a step the applicant can review and leave, but it could come as a surprise if the tap submits the application at once. If the next screen lets them check their information, “Review application” describes the destination. If this is the final step, “Submit application” sets a more accurate expectation. The content designer and the developer need the same understanding of what the button does, a point our article on messages in the customer experience covers in more detail.
You can test the decision while the screen is still a rough sketch. Hide what comes after the button and ask a colleague who hasn’t worked on the design to say what will happen if they tap it. One answer can’t speak for every user, but it can spare the team another round of polishing a button whose wording leaves the action unclear.
Where does the user experience begin and end?
From the system’s side, the operation might end when it stores the application and issues a reference number. From the applicant’s side, a new task begins. Is anything else required? Where will the reply appear? How do they get back to the application after closing the app? If starting a new application is the only way to find the status of the first, the problem goes beyond the wording of the message to the way the service is organised.
That is why it helps to define the end of the task before drawing the screens. Is the goal to let someone send their details, or also to check progress on a later visit? For submission alone, a clear receipt may be enough. A return visit needs a known place to find the application, and a status name that makes sense on the application page and in a phone notification alike.
The task can also extend outside the app. When the message says “We’ll contact you,” the applicant may stay on the screen, expecting the reply there. The designer can name the channel if the team knows it. If the teams haven’t agreed who sends the reply or what updates the status, that is a service decision for the product owner to take to operations, and a more precise promise won’t make it possible to keep. At this point user experience meets customer experience across the whole journey.
The interface ends at the edge of the screen. The experience continues until the person has done what they came to do.
Decide where the user’s task ends before you draw the screens.
How do you read an app screen before approving it?
A review of the interface shows what is on the screen. On its own, it can’t prove what the user understood. Each decision below raises two questions: what can we see, and what needs real use to find out?
What does this number tell me?
On a Saudi credit data platform that AZM X redesigned, the credit score leads the home screen, with a word that explains it and the date the data was last updated. The team could have made the number large and decided the most important information had its due. Yet the description and the date answer two questions the number leaves open: what does this score mean, and when was it true?
From the interface side, a reviewer can see which details sit together and what draws the eye first. They can also see where someone would look for more. From the experience side, the team needs to know whether people read the score, understand how recent it is, and know their next step. Two people can see the same number and leave with different readings if only one notices the date.
To review a similar screen, show two dates on a prototype: the date of the visit and the date the data was updated. Then ask a participant which one describes the number in front of them. If they pick the wrong one, start with the wording, then check where the date sits and how close it is to the number. This is an exercise we suggest for learning, not a result attributed to that project.
Read two states in a row, not one screen
Back to the account application. In the first state, the applicant sees their details and “Submit application.” In the second, they see “Application received” and a reference number. A reviewer can establish that a number appeared and that the message mentions receipt. Whether the applicant understood that the account is not yet active is a hypothesis to test.
Now make the question harder. If the applicant closes the app and comes back that evening, do they find a button to register again, or a link called “Track my application”? A confirmation message can be excellent and still lose its use as soon as the person leaves the screen. That is the difference between reviewing a screen and reviewing a flow: the first shows whether the words are clear, the second whether they stay true and useful after the person moves on.
Waiting brings another decision. If the system hasn’t responded yet, what does the person see? Showing the submit button again could prompt a second attempt; hiding it without explanation leaves them with no signal. It works better when the designer and the developer agree on the states the system really has, such as sending, confirmed receipt and an outcome that can’t be verified, and then write a message for each that matches what the system knows at the time. “Received” should appear only once receipt is confirmed.
Then comes recovery from an error. If the application fails to send, did the form keep the details? Is there a field to correct, or should the person wait and try again? The answers shape both the text and the next action. W3C’s guidance on form notifications explains how to tell people about success or errors and help them correct them, though the details differ between websites and native apps.
What changes in an Arabic interface?
On a phone in Arabic, one line can hold an Arabic name, a reference in Latin characters and a date. Right alignment settles only part of it. Is it clear which value belongs to which label? Does a screen reader present the information in the intended order? Does the reference keep its character order when copied? W3C explains how base direction works and how to handle text that runs in a different direction inside a line, and the actual behaviour still needs checking on every platform. We cover these decisions in our guide to Arabic UI design.
Put the reference line into the real form with punctuation around it, then narrow the space. The order can look right on the designer’s large screen and come apart from its label when the line wraps on a phone. Ask a participant to read the reference or use it to find the application, because reading a single element in the design file won’t show what happens when space runs short.
Look closely at the status word too. “Awaiting review” tells the state even to someone who can’t tell the badge colours apart. If a field needs completing, name the field and explain what it needs next to it, because a red dot at the top of the form leaves the person to find the problem and work it out alone. WCAG’s use of colour criterion says colour must not be the only way information is conveyed.
How do you know whether the user experience improved?
Measurement starts with a clear task, and with a team that agrees before the test on what counts as success.
How do UI and UX work come together on one decision?
At a review of the account application, a product lead might say the aim is fewer calls about application status. A researcher starts from why customers say they called. An interface designer tries a more visible place for the link to earlier applications. A content designer asks whether “Complete” refers to the details entered or to the account itself. Development and operations specify the states the system actually sends. Job titles vary between companies, so it helps to organise the work around the decision each person can inform, not around who owns the screen.
The difference between disciplines shows most when the first fix falls short. The team adds the link, then finds in testing that the applicant saw it and didn’t open it, because they took “Previous applications” to mean closed ones. Several fixes are now reasonable: rename the link, bring the active application onto the home screen, or explain how to track it after submission. The choice depends on what participants did and what the service can support.
Test one task, and define success first
Choose a short task you can observe. Give a participant a prototype and made-up details, ask them to submit the application and then find out what happened to it, and let them use the interface as they understand it. If you tell them to tap “Track my application,” you have handed them part of the answer you wanted to test. NN/g’s introduction to usability testing explains how watching people carry out realistic tasks shows where they struggle.
In this example, three events can be recorded separately: submitting the application once, finding it after returning, and describing its status correctly. A participant can manage the first two and still believe the account is ready. A team that only counts submissions misses the most important observation, and one that relies on opinions of how the interface looks can’t tell which step needs work.
Record the first action before offering any help, then ask what the participant expected when they chose it. Separate people who know the old version from those seeing it for the first time: the first may look for a link where they remember it, the second relies on today’s wording and layout. Keep what you saw apart from how you read it.
When you test a revision, change only what answers your question. To learn whether a label is understood, keep the action in place and compare the wording. To learn whether people can find the action, keep the wording and move it. A full redesign suits a broader question, but it makes it hard to tell which change made the difference.
Timings and observations can also disagree. The new version may cut the time to submit while some participants still leave believing the account is active. The shorter time doesn’t settle the launch decision. The question goes back to the moment of confusion: what information was missing at submission? The text might need a small edit, or the system might need to show a status it couldn’t show before.
What should leave the design review?
Take the screen that caused the most disagreement in your team and write three lines beneath it. First, what appears: “The app shows a reference number after submission.” Second, the expectation: “The applicant will understand that the application arrived and activation is pending.” Third, the evidence: “They return to the application and explain its status without help.” You now have an interface decision and an experience question, with a way to check the second.
Then name the missing information that is holding up the decision. If people disagree about what the system does, ask development for a precise account of its states. If they disagree about what customers understand, watch people use the prototype. For teams that need to take this work from one screen to a whole service, AZM X describes its UI and UX design services and what can be tested with users in its UX Lab.
When the team shows you the green check mark again, ask one question: what can the person do now? If the answers differ, you have found a design decision worth the time before choosing the shape or the colour of the mark.
