UX (user experience) is the path a person takes to reach their goal: which steps they go through, where they hesitate and what stops them. UI (user interface) is how that path looks: buttons, fonts, colours, spacing. UX answers “does it work?”, UI answers “is it clear and pleasant to use?” — which is why a product needs both: a beautiful screen without a thought-through flow doesn’t sell, and a good flow in a confusing wrapper never gets completed.
After this you will be able to
- Explain the difference between UX and UI using your own site or app as an example
- Name the five stages of the work — research, flows, prototype, visual design, testing — and what each one delivers
- Use a six-point checklist to verify that your project had a UX stage
Contents
What UX is
Nielsen Norman Group — one of the most widely cited research firms in interface design — defines user experience broadly: it covers every aspect of a person’s interaction with a company, its services and its products. The first requirement of a good experience is meeting the customer’s exact needs without fuss or bother. Beauty and delight come next, not instead.
In practice, UX work on a website or app means answering simple but uncomfortable questions. Who comes to the site, and with what task? What do they need to see first so they don’t leave? How many steps does it take to get from the home page to a booking, and which of them is unnecessary? What happens if someone mistypes their phone number or loses connection halfway through a payment?
- Research: customer interviews, reviewing enquiries and calls, competitor analysis, analytics data
- User flows: the step-by-step path to the goal, including branches and errors
- Information architecture: which sections exist, what they’re called and how they nest
- Prototypes: unstyled screen layouts you can “walk through” as a user
- Validation: showing the prototype to real people and fixing issues before development starts
What UI is
UI is the visible layer: how elements on the screen look and behave. Typography, colour, grid, spacing, icons, buttons and fields, and their states on hover, press and error. Good UI isn’t just colouring in a finished wireframe. It solves problems too: it shows what’s clickable and what’s just text, highlights the main action, and makes a long page readable.
UX is responsible for
- What the person does and in what order
- Which screens and sections are needed at all
- What data we ask for, and why
- What happens on an error, an empty list or a dropped connection
- Whether the person knows where they are and what comes next
UI is responsible for
- How buttons, fields and cards look
- Fonts, sizes, colours and contrast
- Grid, spacing and alignment
- Icons, illustrations, micro-animations
- A consistent style across every screen
How the work flows: from research to final design
Research
We gather what’s already known: who the customers are, what they ask sales staff, at which step they abandon an enquiry, what competitors do. For a small website this may be a couple of conversations with the owner and the sales team; for a service, user interviews.
User flows
We describe the path step by step: “saw an ad → opened the service page → checked prices → picked a time → confirmed”. Separately, we cover what happens if the person changes their mind, makes a mistake or comes back later.
Prototype (wireframe)
Screen layouts made of grey blocks: where the heading goes, where the button goes, where the form sits. Colours and fonts are deliberately left out so the discussion stays on logic, not on the shade of blue.
Visual design
The approved layout gets its style: fonts, palette, icons, photography, element states. Repeating elements are collected into a UI kit — a library of components.
Testing
We show a clickable prototype to a few people from the target audience and ask them to complete a task. Anything they stumble on gets fixed before handover to development.
Who does what on the team
In large companies, UX and UI are handled by different people. In studios and small teams, a product designer often combines the roles. What matters isn’t headcount but that every task in the table below is owned by someone.
UX researcher
- What they do
- Interviews, tests, user behaviour analysis
- What they deliver
- Findings: who the users are and what gets in their way
UX designer
- What they do
- User flows, section structure, prototypes
- What they deliver
- A flow map and screen wireframes
UI designer
- What they do
- Visual style, components, states
- What they deliver
- Mockups and a UI kit
Product designer
- What they do
- Combines UX and UI, keeps the link to business goals
- What they deliver
- All of the above in one loop
Front-end developer
- What they do
- Turns mockups into code, checks feasibility
- What they deliver
- A working interface
What breaks when a business skips UX
The most common request at kick-off is “make it look nice, like our competitor’s”. A visual style can certainly be a reference, but a competitor’s flow is built around their customers, their range and their processes. When the UX stage is skipped, the same problems tend to surface on projects:
- The menu mirrors the company structure (“About”, “Divisions”, “Departments”) instead of customer tasks (“Book”, “Prices”, “How to get here”)
- The enquiry form asks for everything a sales manager might ever need — and people abandon it halfway
- The main action is hidden: the booking button only lives in the header or at the very bottom of the page
- States aren’t designed: what the person sees while something loads, when a list is empty, or when the server doesn’t respond
- The mobile version is left for “later”, even though many customers first open a site on their phone from a link in a messenger or social feed
How a client can check that UX was thought through
A business owner doesn’t need to understand a designer’s tools. It’s enough to ask the vendor the right questions and see whether the project materials answer them.
- There’s a description of who your users are and what tasks they come with
- Key flows are written out step by step — including errors and drop-offs halfway
- You were shown and approved screen wireframes before visual design
- The mobile version was designed alongside desktop, not after it
- Every important screen has a designed loading, empty and error state
- The prototype was tested at least once on people who weren’t involved in the project
UI decides whether someone wants to stay. UX decides whether they can do what they came for.
