The difference between UI and UX design is the difference between a screen and a task. UI (user interface) design decides what is on each screen: the layout, the buttons, the colours, the wording of the labels. UX (user experience) design decides whether a person can get their work done: which screens exist at all, what order the steps come in, what the system does when something goes wrong. A system can have a handsome interface and still be slow and frustrating to work with, because the interface was designed and the experience was not.
If you are commissioning an internal business application or a customer portal, the distinction matters because the two are briefed and checked differently, and because most of the money lost to poor design is lost on the UX side.
UI and UX design side by side
| UI design | UX design | |
|---|---|---|
| The question it answers | What does this screen look like, and how do its controls behave? | Can this person finish this task quickly and without mistakes? |
| What it works on | Layout, colour, type, icons, buttons, form fields | Tasks, the order of steps, what information is needed when, error handling |
| Typical outputs | Mock-ups, a style guide, a library of reusable components | Notes from watching users, task flows, wireframes, test findings |
| How you judge it | Consistent, legible, works on the screen sizes in use | Time to complete a task, error rate, how much training is needed |
| When it goes wrong | The system looks dated or inconsistent | Staff keep a spreadsheet on the side because the system is too awkward |
The outputs overlap. Wireframes sit between the two, and our article on the differences between a wireframe, a mock-up and a prototype explains which is which.
An example: a job-scheduling screen
Take a screen where a dispatcher assigns jobs to engineers.
UI design settles the screen itself. It decides whether the week is shown as a grid or a list, how an urgent job is marked, whether the text can be read on the large display on the office wall, and whether a button that deletes something looks different from one that saves.
UX design starts before the screen exists. It asks what the dispatcher is trying to do forty times a day and what they need to see in order to do it: where each engineer is, what they are qualified to do, which parts are on the van. It asks how many steps it takes to move an appointment when a customer rings, and whether that can be done while the customer is still on the phone. It asks what happens when two dispatchers move the same job at the same moment, and what the engineer then sees on their phone.
You could answer every UI question well and still build a screen that takes nine clicks to move an appointment. You could also get the flow right and present it so poorly that nobody finds the button. Good software needs both, and the order matters: settle what the screen is for before deciding what it looks like.
Why UX matters more in business systems than buyers expect
With a consumer app, poor design shows quickly, because people stop using it. Staff do not have that choice. They have to use the system they are given, so poor UX shows up indirectly:
- re-keying, because the screen does not show what is needed and people copy it in from somewhere else;
- spreadsheets and paper kept alongside the system;
- mistakes that have to be found and corrected later;
- new starters who take weeks to become useful;
- on a customer portal, phone calls and emails about things the portal was meant to handle.
None of these appear in a demonstration. A demonstration shows that a feature exists, not that it is quick to use on a busy Monday morning. This is how a system can pass every line of its specification and still disappoint the people who work with it.
UI still earns its place. A consistent interface is quicker to learn, because a control that works one way on one screen works the same way on the next. On a customer portal the interface is also part of how your customers judge your business.
Who does the work
Large product companies employ separate specialists: UX researchers, UX designers, UI designers, content designers. A business system for a company of fifty or two hundred people rarely has the budget for four roles, and does not need them. The work is usually shared between a designer and the developers, often using an established component library, which is a ready-made and tested set of buttons, tables and form controls. That gives a consistent interface without drawing every element from scratch.
What matters is that the UX work happens, whoever does it. The warning sign is a supplier who goes straight from your list of requirements to coloured mock-ups. That is UI design without UX design, and it tends to produce screens that mirror the database tables instead of the job.
Questions worth asking a supplier:
- Who will watch our staff doing the work before anything is designed?
- Which tasks will you design around, and how did you choose them?
- Will we see something we can click through before development starts?
- Will real users try it, and what happens to what you learn?
- Which accessibility standard do you work to?
Accessibility belongs to both
Accessibility means the system can be used by people with impaired sight, hearing, movement or cognition. Some of it is UI work, such as colour contrast, text size and a visible marker showing which control is selected when someone moves around by keyboard. Some of it is UX work, such as clear error messages and not asking people to remember information from one step to the next.
The usual benchmark is the Web Content Accessibility Guidelines (WCAG). Version 2.2, published by the W3C in October 2023, is the current one, and UK public sector bodies are required by regulation to meet its AA level. A private business commissioning an internal system is in a different position, but the Equality Act 2010 places duties on employers and service providers, so check what applies to you and take advice if you are unsure. Building to the standard from the start costs far less than retrofitting it.
How to brief and check each one
For UX, the brief is a list of the people who will use the system and the tasks they do most often. A short description of each kind of user, called a persona, helps here, and we cover the method in how to use personas to build a great user experience. The check is to put something clickable in front of a few real users and watch them attempt those tasks without help. Jakob Nielsen of the Nielsen Norman Group argued in his article “Why You Only Need to Test with 5 Users” that five people are enough to expose most usability problems, and that several small rounds of testing are worth more than one large one.
For UI, the brief is your brand guidelines if you have them, the devices and screen sizes your people use, and any existing system the new one should resemble. The check is consistency: the same action looks and behaves the same way everywhere.
Both belong in the scope before a price is agreed. This matters most when you are buying bespoke software at a fixed price, because a count of screens says nothing about whether the result will be usable, while a list of tasks and the people who do them does. Sections 2 and 4 of our software project planning worksheet are the place to write those down.
Before you speak to any supplier, there is one check you can make yourself. Sit beside a member of staff for half an hour while they do their most common task in the system you have now. Count the steps. Note every time they leave the system to look something up, type the same thing twice or work around a screen. That list is the UX brief for the replacement, and it is worth more than any description of how the new system should look.