UI is short for user interface and names the screen that gets drawn, while UX is short for user experience and names what the person in front of it goes through, above all whether they can finish the job they came for. A quote that folds both into a single design line never says which of the two it priced. Only the list of outputs behind that line answers it.
Nobody reads that as a problem, because both halves get filed under design. One of them is a surface, though, and the other is the order in which somebody gets something done. A line that hands over drawn screens alone leaves the second half unsettled, and whoever writes the code ends up settling it by looking at the pictures.
UI is the drawn screen, UX is whether the job gets done on it
What separates the two is what each one measures. UI measures a surface: layout, buttons, type, colour, icons. Everything a person sees and touches sits under that name.
UX measures what happens around that surface. Somebody arrives with a job in mind, and whether they get through it is the core of what UX covers: which steps exist, what order they come in, what has to be in their hands already, and what happens while something is still missing. Hold the two measures side by side and the practical difference shows: a screen can be drawn carefully and still leave somebody stuck halfway, while a sequence can be sound and the screen it produced unreadable. Neither failure substitutes for the other, because they are failures of different things.
Here is where UI and UX get confused. UX gets taken for looking good, and looking good belongs to UI. Liking a demo is no measure of UX; what measures it is what somebody in front of the screen goes through, starting with whether the job gets finished. The cost of mixing the two up lands while a quote is being read, because a handsome demo gives the impression that both jobs were done. What a demo shows is that the drawing is finished. Whether the sequence holds is not visible on the same screen.
Naming the two apart also helps when something breaks, because it points you to the right place to look. Somebody who cannot read a screen has a surface problem; somebody who reads it and still walks away has a sequence problem. The same fix does not close both, since one asks for a redraw and the other asks for the flow to change.
The distinction does not earn its keep everywhere. A single screen with a single step has no order to get wrong, and what is left there is layout. The split starts paying off where a job takes more than one step to finish.
Where the two pieces of work meet
The output most often missing from a quote is the list of states. What sits between the two names is a handover point, and that point is the flow plus the states each of its steps can hold: the steps get written down, each step gets its possible states, and the drawing is made from that list rather than from somebody’s memory of a demo. The full version of a step always gets drawn, because the person drawing and the person buying both picture the screen with something in it. The version where nothing has been entered yet, the version waiting on an answer, the version where one thing is still missing: none of those gets drawn unless the list says they exist.
A state left off the list is paid for once the product is in use. It surfaces as a gap: the person in front of the screen cannot tell what happened, and nothing on the screen explains it. Design that feels finished and incomplete at once usually traces back to exactly that gap. The handover also runs one way: the list feeds the drawing, and the drawing does not produce the list. Lists do get built the other way round, by pointing at a finished screen and asking what else could happen there, and a list built that way comes out short in the same place every time, because nobody pictures the state where somebody is stuck and that state is not on the screen to be noticed.
Where there is only one state, this output needs no document of its own. A screen with nothing to switch between produces no separate handover, and the list and the screen are then the same thing.
The UX decision is made before a screen is drawn
The expensive moment is the one where an approved screen has to be opened again. By then there is a picture in the room with expectations attached to it, and changing the order in which somebody gets a job done stops being design work; it turns into the undoing of work already signed off. Put the same question before anything is drawn and the bill is a meeting. The gap between those bills comes from the flow deciding which screens exist at all, while the drawing only settles what those screens look like, and that is why UX comes before UI.
The same reasoning puts a limit on redrawing. A redraw moves the surface and leaves the job behind it where it was, and once the flow moves, the set of screens moves with it, which leaves nothing to patch and a drawing to make from the beginning.
The order gets inverted every time the screens go first and the flow comes later. The trouble is that drawn screens have already settled which job gets finished. Every screen carries decisions of that kind: which piece of information appears on it, which step follows which, what somebody sees and when. Those get settled while the drawing happens, usually without anybody saying so out loud, and an unwritten decision is not an open one. It is a decision nobody can find.
None of it reaches the quote, because the line prices the drawing rather than the decisions taken quietly inside it. Where the flow is a single step there is no such decision waiting, so starting from the drawing costs nothing at all.
What the two pieces of work hand over in a quote
The name on a line does not say what is being priced. The list of outputs does. The rows below name the outputs design work is known to produce, with what each one hands over and the question it answers. They are general knowledge rather than a claim of ours: a glossary, not a piece of evidence.
| Line item | What is handed over | The question it answers |
|---|---|---|
| User flow | The steps and their order, written down, with each move from one step to the next | How does somebody get the job done |
| Wireframes | The layout of each screen, with colour, type and imagery still undecided | Which piece of information sits on which screen, and where |
| Prototype | A clickable version, so the order can be tried on a real device | Does the order hold in use and not only on paper |
| Usability test | A real person walking the flow, with a record of where they hesitated | Does somebody actually finish the job as described |
| Visual design | The finished screens: colour, type, icons, spacing | What does the screen look like and what reads first |
| Design system | Reusable components and the rules for using them | Will a screen added later speak the same language |
What the table leaves you to do is check which rows are written beside the line in your own quote. The flow row and the usability test row measure the UX side; visual design and the design system measure the UI side. Wireframes and the prototype sit between them, because that is where a flow turns into a drawing.
Row names move from one studio to the next, and the name is not the thing to read: if a quote says something other than wireframes, the question stays the same, which is whether the line hands over the layout of the screens or their finished state. Nor is every row needed in every job. Where the surface is small, the flow and its states fit on one page and a separate prototype step is not needed. What matters is not the whole list but whether the rows this particular line carries are written down anywhere.
One output never appears in a list like this, and it is the scope sentence. Which screens are not part of the job is a decision too, and it does not live inside the name of a line. The sections that follow show what that decision looked like in work that is already live.
When the question is a comparison, the screen’s unit is not a list
Somebody arrives at a screen with a question, and the shape of the question sets the unit the screen has to work in. Where the question is about one item, a list does the job. Where it is about a difference, a list does not, because reading a difference requires the things being compared to sit on the same surface at once.
The KGM SsangYong showroom kiosk, a touchscreen standing on the shop floor carries that kind of question. Its project record names the condition: at a busy hour nobody is spare to talk a visitor through the differences between trim packages, and the app sets those differences side by side on one screen. Which condition of use that interface was built for is a separate subject, opened in the article on replacing printed catalogues and menus with software. The decision that matters here was taken earlier: is the unit of the screen one vehicle, or the difference between vehicles. A beautifully drawn catalogue list does not answer a question about a difference.
Industrial machinery throws up the same shape of question. On the Plastik ve Makina platform the buyer’s question is a comparison, so new and used stock share one list with condition opening and closing as a filter. Why that is not a display preference is unpacked in the article on which half of an application answers a filter.
One question falls outside this article. The kiosk sits on a touchscreen the dealership owns, and which device an app opens on, along with who runs that device, belongs to mobile app work, where device ownership is settled before any code is written rather than to a design line.
Where the question is about one item and not a difference, a comparison surface is dead weight. On the Çatalca Merkez Kasap menu a code printed at the table opens the section it belongs to, and the choice gets made there within seconds.
When the screen has to stand in for something
In some work what the screen has to carry is not a picture but a substitute for a sense the person cannot use. That decision comes before layout, because it settles what goes on the screen at all.
Kokudankokuya, a fragrance store where one scent stays a single product record, has that condition in its project record: the product is bought unsmelled, which leaves a written account of the scent as the only thing able to carry the decision.
Under a condition like that, a photograph can only do so much. What somebody needs is a description they can compare, and the axis such a description runs along is covered in the article on modelling product variants. The question here comes before that one: what information does the screen have to carry. The same question arrives from the other side in automotive. On the KGM SsangYong online sales channel the buyer builds the car on screen through trim and colour, and what is sold is that configuration; the screen’s job is not to display a product that exists but to let one be put together that does not exist yet.
Which screens exist follows from reading the job that way. How an assembled result carries into payment is a separate subject, covered in the article on turning a configuration into a priced quote. The drawing does not change that decision. It changes how an assembled result looks once it is on screen.
What these examples share is a screen closing a gap. In one, the product cannot be touched; in the other, the product does not exist yet. In each case, what decides the information the screen carries is not a layout preference but the condition the person is in at that moment. Where a product can be picked up and tried, the screen has nothing to stand in for: the descriptive load drops away and the screen’s job narrows to making the product findable.
Sometimes the interface’s job is to add no step
A quote counts what was added, and that is why part of the design work never shows up in one at all. Say design decision and what comes to mind is something added: a screen, a step, a button. Some of those decisions are made by adding nothing.
We run AlgoKlima ourselves; the system is in service and we are still building on top of it. Because the field app does not need a connection to keep going, a service job gets written up in a boiler room or lift shaft, past the edge of coverage, and what gets designed on the interface side is the absence of a screen. An absence leaves no screen to name, so no line carries it. Where a record sits while there is no connection, and what happens once connectivity returns, is covered in the article on field apps that keep working with no signal.
Scope behaves the same way, and the clearest case of a layer taken out sits in the Çatalca Merkez Kasap QR menu, where every section carries its own address. Its project record draws the boundary without hedging: ordering, payment and stock all stay outside. Why the scope was kept that narrow is unpacked in the article on which layer stays out when a printed menu moves into software.
Added screens get written down and removed ones do not, so a layer deliberately left outside never becomes a line of its own. The sentence saying this layer is not part of this job still describes the content of the line, and it is what makes the scope readable. Narrowing is itself a design act: settling which screen will not be made sharpens which job the remaining screens have to finish. That does not make every removal a gain, since a step that was producing a record takes the record with it, and the measure of that loss is a separate calculation.
One boundary has to be drawn. Most accessibility decisions already live inside this line: contrast, a focus ring that can be seen and a target big enough to hit arrive with the visual design output and the design system. What sits outside is only the question of when the obligation bites, which is covered in the article on when web accessibility becomes a legal requirement.
How to read the design line in your quote
One question carries everything above it: does this line hand over a flow and a list of states, or drawn screens alone? If the flow and the states are part of the handover, the UX side sits inside the price. If drawn screens are all that comes out, the line has priced the UI side and left the order in which somebody finishes a job for someone else to settle. That someone else is usually whoever writes the code, working from the screens already on the table.
Then read the scope sentence next to the line, because it describes the content better than the name does: it also says what stayed outside. The KGM SsangYong showroom kiosk was kept deliberately narrow, built as a screen for looking through the range rather than a channel that takes a sale, and the project record says the boundary was drawn at the start. Order deserves the same attention. Where the flow and the drawing sit inside one line, look for a sentence saying which of them comes first; without one, the work tends to start from the drawing. Why the work definition behind a line never gets written into the quote is a separate matter, opened in the article on why quotes for the same job come out different.
That leaves one test: are the things this line will hand over written down anywhere. Taking it into a meeting needs one thing from you, which is the question your own user arrives with. Put that into words and we can write down which outputs the design line has to deliver; in web development work, where the flow is mapped before the screens, that is the order the work runs in.
