UX Design That Fixes Structure Before Styling

What is the difference between UX and UI design?

UX decides what the product does and in what order. UI decides what it looks like. Both are design, they use different skills, and confusing them is why a lot of projects end up with a beautiful interface that nobody can complete a task in.

UX work produces flows, structure, wireframes and research findings. UI work produces the visual system — type, color, spacing, components, states — that turns that structure into something usable and on-brand.

They are frequently sold together, and for most projects that is right. But they are separable purchases: plenty of companies buy UX research and structure, then apply their existing design system themselves.

Do we need UX design if we already have a designer?

It depends what your designer does. Many talented visual designers do not do research, information architecture or usability testing — not from any lack of skill, but because those are different activities with different training.

A useful test: when a layout decision is disputed, what settles it? If the answer is seniority or preference, there is a gap that UX work fills. If the answer is "we tested it and here is what happened", you probably have the capability already.

The other common gap is structural. A designer working screen by screen can produce excellent individual screens and a product whose overall navigation makes no sense, because nobody owned the structure above the screens.

How much user research does a project need?

Enough to be confident about the problem, and rarely more than that. Research with no decision attached produces a thorough document that changes nothing.

For most commercial projects that means a handful of user interviews, a review of what analytics already show, and usability testing on the prototype before build. That is weeks, not months, and it reliably changes the plan.

Larger research programs make sense when the audience is genuinely unfamiliar, the domain is specialized, or the investment is large enough that being wrong is expensive. Outside those cases, more research mostly buys confidence you already had.

When should UX happen in a project timeline?

Before visual design and well before development. Every stage after UX inherits its decisions, so problems found late are the expensive kind.

The common failure is running UX in parallel with visual design to save time. What happens instead is that visual work gets built on a structure that then changes, and the visual work is done twice.

The other failure is treating UX as a phase that ends. Structure needs revisiting when the product changes materially — a new feature area added to navigation designed for a smaller product is how information architecture degrades without anyone deciding to degrade it.

What is information architecture and why does it decide everything?

Information architecture is how content is organized, labelled and related — the structure underneath the navigation rather than the navigation itself. It decides everything because every other decision is made inside it.

The most common failure is organizing around the business rather than around the user. Menus that mirror an org chart are instantly recognizable and consistently unhelpful, because customers do not know or care which department owns what they need.

The second failure is labelling. Internal vocabulary leaks into navigation constantly — a section named after a product line nobody outside the company recognizes, or an industry term used where a plain one would do. People do not click things they do not understand; they leave.

Card sorting is the cheap way to settle it. Give representative people the content and ask them to group and name it. What emerges is usually different from what the team assumed, and it is evidence rather than another opinion in the room.

How much research does a project actually need?

Enough to stop guessing about the decisions that matter, which is usually less than research advocates suggest and considerably more than nothing.

The useful framing is to ask what you would do differently depending on the answer. If a finding would not change any decision, that research is interesting rather than valuable, and the budget is better spent elsewhere.

For most business projects the high-value questions are few: how do people currently solve this, what vocabulary do they use, where does the current thing fail them, and what do they need before they will act. Those can often be answered with a handful of conversations and a review of your own support inbox.

The support inbox in particular is underused. It is a free, continuously updated record of what confuses your customers, written in their words. Reading a few months of it before designing anything is the cheapest research available.

Where does UX end and UI begin?

UX decides what the screens are, what order they come in and what each one has to accomplish. UI decides what they look like. In practice they overlap, and the boundary matters less than making sure neither is skipped.

The skipped one is almost always UX, because UI is visible and UX is not. A project can produce beautiful screens for a flow that was never questioned, and the result looks like a success until people try to use it.

The tell is when design feedback is entirely about appearance. If nobody in the review is asking why this step exists, whether it could be merged with the next one, or what happens when the person does not have the information being requested, then the structural questions are not being asked at all.

On smaller projects one person does both, which is fine. What is not fine is doing only the visible half and calling the project finished.

How do you design for people who will not read?

By accepting it as the baseline rather than treating it as a failure on their part. People scan, act on the first plausible option, and read only when something goes wrong.

That has direct design consequences. The most important information cannot be in the middle of a paragraph. Instructions that must be followed cannot be above a form people will start filling before reaching them. And anything genuinely critical needs to be where the action is, not where the explanation is.

Labels do more work than help text. A field labelled clearly enough needs no explanation underneath it, and a field that needs a paragraph of explanation is usually asking the wrong question.

This is also why error messages matter disproportionately. The error message is the one piece of text a person will definitely read, because at that moment they need it. Writing those carefully — what went wrong, what to do — is among the highest-value writing on any product.

What does UX work hand over?

Decisions with the reasoning attached, in a form that survives the people who made them leaving.

The artefacts vary — flows, wireframes, a content model, an annotated prototype — but the useful part is consistent: what was chosen, what was rejected, and what evidence pointed that way. A wireframe with no reasoning is a picture someone will redraw in the first argument.

It should also record what is still unknown. Every project has open questions, and writing them down as open is more honest and more useful than quietly resolving them with a guess that later reads as a decision.

And it has to be buildable. UX output that cannot be implemented within the project's actual constraints is a design exercise. The constraints — platform, budget, who maintains it — belong in the process rather than being discovered at handover.

How do you prioritize what to fix first?

By impact against effort, with impact judged on how many people hit the problem and how badly it blocks them.

A flat list of findings does not survive contact with a roadmap. Everything looks worth doing, nothing gets scheduled, and the work quietly stops — which is the most common fate of a UX report.

Severity has two components that need separating. A problem that completely blocks the primary task for a few people is different from one that mildly irritates everyone, and both are different from a cosmetic issue somebody mentioned once.

Effort belongs in the same table, because it changes the order. A minor problem fixable in an hour should usually be done before a major one requiring a quarter, if only to demonstrate that the work produces changes.

And the list needs an owner and dates. Findings assigned to nobody are findings that do not get fixed, however clearly they were presented.