Guide · Design & UX

UI/UX design process: from research to interface

Most design work goes wrong in the order it was done, not in the work itself. This is how a UI/UX process typically runs — from the first conversation about goals through to the interface a developer builds — and why each stage exists before the next one.

What is the UI/UX design process?

The UI/UX design process is the sequence of decisions that turns an objective into a working interface. It begins with what the project has to achieve and who it is for, moves through structure and behaviour, and ends with a visual design detailed enough to be built. Each stage narrows the number of open questions so that the next one can be decided on evidence rather than opinion.

It is a sequence, not a rigid template. The stages below describe a full process; real projects merge, shorten, or repeat them depending on scope, and it is normal to return to an earlier stage when something later reveals a structural problem.

UX vs UI: how they work together

UX is the part you cannot see directly: what content exists, how it is grouped, the route someone takes through it, and what the interface does at each step. UI is the visible expression of that — typography, colour, spacing, imagery, and the styling of every component and state.

They are usually described as two disciplines, but in practice they are two views of the same decision. A hierarchy is a UX judgement about what matters and a UI judgement about size and weight at the same time. This is why the process runs structure first and surface second: a beautiful layout applied to a confused structure inherits the confusion, while a clear structure gives visual design something definite to express.

For a fuller account of the qualities the finished result should have, see what makes a good user experience.

The UI/UX design process

1Discovery and goals

The first stage is agreeing what the project is for. That means naming the outcome in plain language — explain a service, generate enquiries, sell a product, replace an ageing site — and identifying the constraints around it: existing content, technical platform, brand assets, internal approvals, and anything that cannot change. Without this, later decisions get argued on taste, because there is no shared measure to argue them against.

2User and business context

Next comes understanding who the interface is for and what the organisation needs from it. This can range from a short conversation with the people who speak to customers, to reviewing existing analytics, support questions, and search behaviour. The output is not a document for its own sake — it is a short list of the audiences that matter, the questions they arrive with, and the business priorities the interface has to serve at the same time.

3Information architecture

Architecture is the structure beneath the design: what content exists, how it groups, what sits at the top level, and what each page is responsible for. It is worked out before layout because it determines navigation labels, URL structure, and how many pages there need to be. Content and structure are decided together — designing a layout for content that does not exist yet is the most common cause of rework.

4User flows

A flow is the route someone takes to complete a task: arrive, understand, compare, decide, act. Mapping the main flows shows where a step is missing, where two paths compete, and where a decision is being asked for before the information needed to make it has been given. Flows are cheap to change at this point and expensive to change once they are built.

5Wireframes

Wireframes settle layout, hierarchy, and content order without the distraction of colour and imagery. Their purpose is to answer structural questions — what appears first, what the primary action is, what can be deferred — while they are still quick to revise. Reviewing wireframes with real headings and real copy, rather than placeholder text, is what makes the feedback useful.

6Interaction design

Interaction design covers how the interface behaves: what is clickable and how it signals that, what happens on hover and focus, how navigation opens, how loading and empty states appear, and how errors are communicated. Motion belongs here too, and its job is to explain a change of state rather than to decorate it. Behaviour defined at this stage is what keeps an interface predictable once it is built.

7Visual UI design

Visual design applies typography, colour, spacing, imagery, and tone to the structure already agreed. Done as a system — type scale, spacing scale, colour roles, component states — rather than as a set of individual screens, it stays consistent as the project grows and gives developers unambiguous rules to build against. This stage is where brand and interface meet, and where a page starts to feel like it belongs to a specific organisation.

8Responsive design

Each significant breakpoint is designed rather than inherited. Content order often needs to change on a small screen, tap targets need room, navigation usually becomes a different component, and anything relying on hover needs a touch equivalent. Because most visitors arrive on a phone, the small screen is generally worth resolving first and expanding outward.

9Prototyping and review

A clickable prototype turns static screens into something that can be walked through. It exposes problems that flat comps hide — a step that feels longer than expected, a label that is misread, a form that asks too much too early. Reviews can be internal walkthroughs or observation of people attempting a task; the value comes from watching where hesitation occurs rather than from asking whether people like it.

10Refinement and handoff

Findings are prioritised — anything blocking a task first, preference-level notes last — and the design is revised accordingly. Handoff then covers what implementation needs: component states, spacing rules, type and colour tokens, breakpoint behaviour, accessibility requirements, and the assets themselves. Design work usually continues through build, because questions surface that no static file anticipated.

How these stages are shaped into an engagement is described on the UI/UX design services page, and finished interfaces are collected in the selected work, including the RAGHADD case study.

How long does UI/UX design take?

There is no standard duration, and any figure quoted before the scope is known is a guess. The honest answer is that timing depends on a handful of variables, and the same page count can take very different amounts of time depending on how they fall.

Scope — how many distinct page types and flows genuinely need designing, rather than how many URLs exist.
Complexity — a marketing site and a product interface with accounts, states, and permissions are different problems.
Content readiness — whether copy, imagery, and brand assets exist, or need to be produced alongside the design.
Feedback cycles — how quickly reviews happen and how clearly decisions are made is often the largest single factor.
Implementation requirements — the platform, integrations, and who is building it all shape how much detail handoff needs.

A realistic estimate comes after discovery, once the scope is written down. Anything earlier is a range at best.

How to prepare for a UI/UX design project

Preparation shortens a project more reliably than anything a designer does. Before the first working session, it helps to have the following settled:

Write down the single outcome the project has to achieve, and how you would recognise it.
Decide who the primary audience is, and what question they most often arrive with.
Gather existing material — copy, imagery, brand files, analytics, support questions.
Identify the technical constraints early: platform, integrations, who will build it.
Agree who gives feedback and who makes the final decision, before the first review.
Be honest about what content still needs writing, since content is usually the slowest part.

If an existing site is being replaced, reviewing it first is worth the effort — the UI/UX design audit checklist covers what to examine, and often shows which parts are worth keeping.

Frequently Asked Questions

What is the difference between UX and UI?

UX is concerned with structure and behaviour — what the interface contains, how it is organised, and what happens at each step. UI is the visible surface: typography, colour, spacing, imagery, and component styling. They are separate concerns but not separate projects; the interface expresses the structure, and a change to one usually affects the other.

Do all projects follow every stage?

No. The sequence above describes a full process, and real projects compress it. A small marketing site may fold architecture and wireframes into a single step, while a complex product may spend considerable effort on flows alone. The stages are a checklist of decisions that have to be made somewhere, not a fixed schedule.

Should content be ready before design starts?

Not necessarily finished, but the shape of it should be known. Designing around real headings and real messages produces a layout that fits what you actually need to say; designing around placeholder text tends to produce a layout the content later has to be squeezed into.

Where does testing fit in?

Wherever there is something to react to. Structure can be reviewed at the wireframe stage, behaviour at the prototype stage, and the built interface once it is live. Earlier review is cheaper, because a change to a flow costs far less than a change to a built page.

Is a redesign always the right answer?

Often it is not. When the underlying structure is sound, clarity, hierarchy, labels, and forms can usually be improved on the existing build. A structured review is the way to find out which situation you are in before committing to a rebuild.

About the author

Written by Anas Essam, a technology consultant and creative director working on AI systems, web design, branding, and digital growth. Based in Egypt, working with teams worldwide.

Structure first, surface second

A process is only useful when it fits the project in front of it. If you are planning a new site, a product, or a redesign, describing the goal is the right place to start. More writing lives in Insights.

Start a conversation