UI Design Process: From Brief to Final Approval

Picture this. You've signed off on how your store's pages look, and halfway through development a developer asks, “What does the user see if a product is out of stock?” One missed path like that can kick off an endless round of revisions. To prevent it, run the UI design process in order: brief, goals and scope, research and user flows, structure, visual design, testing and written approval. Every stage needs a clear output and an approver who has the authority to decide.

What are the stages of the UI design process, from kickoff to final approval?

Work starts with the brief, a short description of what the project needs, and with defining goals, users and scope. Once that's agreed, the UI design process moves on to research, user flows, information structure and rough layouts. After the structure is approved, the team designs the look of the pages and their interactive states, then tests a clickable prototype. Then it logs the feedback and hands the final version to the development team along with implementation specs.

It helps to pin down two terms so everyone uses the same words. User interface (UI) is the part of the product people see and work with: buttons, forms, text and layout. User experience (UX) is the quality of getting the job done, meaning how easily and how error-free users reach their goal. If the line between the two feels blurry, read What Is UI Design and How Is It Different from UX?

That said, the UI/UX design process isn't linear. Sometimes a finding in testing sends you back to the structure stage. That's fine, as long as the step back is deliberate and written down rather than accidental.

The input to this roadmap is the initial business problem. The output is agreement on how the work will proceed. So the project manager needs to align that agreement with the client's decision-making representative: the person with the authority to say “let's move to the next stage.”

What information does a UI design brief need before you start?

A UI design brief is a short document that spells out the problem, the expectations and the constraints of the project. Length doesn't help. Precision does. At the start, I usually ask the client for:

• Brand assets: logo, colors, fonts and any existing visual identity guidelines

• The current product: the live version, available data and recurring user complaints

• Existing content: copy, product photos, and shipping and return policies

• Technical constraints: the current platform, the payment gateway and the systems you need to integrate with

• Decision-makers: who gives feedback and who signs off

At this stage, the initial need and the business information are the inputs. The output is a completed brief that also lists the open questions honestly. The product owner or an authorized client representative should approve it. Every stage of the UI design process builds on this document, so take the time to get it clear.

For example, the brief for a hypothetical store with 200 products can be this short:

Sample decision log: “Brief v1 is the basis for review. Shipping rules are not yet approved; the operations manager is responsible for completing them.”

Don't treat unknowns as settled facts, though. For every open question, write down who owns the answer and the agreed deadline. An unowned question usually resurfaces during visual design, where fixing it costs more.

How are goals, users and project scope defined?

“A modern design” isn't a goal. It's a matter of taste. Turn the goal into something you can watch happen: finding a product, understanding the amount due, or placing an order without calling support. And don't promise higher sales without measuring them. Design removes obstacles, but sales depend on many other factors.

• Input: the completed brief and the constraints

• Output: a list of priority flows, user roles, pages, screen sizes and out-of-scope items

• Approver: the product owner, in consultation with the technical lead

Also write an acceptance criterion for each flow: a sentence that says when the design is acceptable. For the hypothetical store, that might be: “A guest user can see the product price and the shipping cost separately before entering the payment gateway.” Both designer and client can check this condition, so the discussion moves away from personal taste.

Sample decision log: “Guest checkout is in scope. Installment payments have moved to the next release.”

One distinction often slips through estimates. A page is not the same as a page state. Checkout is one page, but it also has loading, error and success states. If the scope counts only pages, a big chunk of the work in the UI design process stays invisible.

Where do research and core user flows begin?

Start with the flow that is used most often or carries the most risk. A store's checkout flow usually does both. Research in the UI design process doesn't have to be a big project. A few short conversations with users, a review of support requests and reliable product data are often enough to get going.

• Input: target users, research questions and whatever access the client permits

• Output: findings, remaining assumptions and a map of the task flow

• Approver of priorities: the product owner, with an explanation from the UX designer

A user flow is the sequence of actions a user takes to reach their goal. In the hypothetical store, for instance, map the flow from product search to payment. Put a product going out of stock midway and an address change at the last step on the same map. A flow isn't just the set of pages where everything goes right.

If you don't have access to real users, label each assumption clearly as an “assumption” and note its risk. The client's opinion is valuable, but it doesn't replace watching how users actually behave. The client knows the product well, which is exactly why they may miss the difficulties a newcomer runs into.

Sample decision log: “The guest checkout flow was chosen for design. The assumption about choosing a shipping method must be checked during evaluation.”

When are information architecture and wireframes approved?

Approve the structure after the flows are clear and before you get into color and imagery. Information architecture is how categories and menus are organized and how people find each piece of information. A wireframe is a simple layout of the page: gray, with no visual polish.

The input here is the approved flows and sample content. The output is the page structure and the layouts for the core flows. The product owner approves it, and the technical lead checks whether it can be built. Since visual details aren't on the table yet, focus on these questions when you review wireframes:

• Where does key information, like price and shipping cost, sit on the page?

• In what order do actions appear, and which one is primary?

• How does the user go back a step without losing their data?

• What copy is needed, and who writes it?

For example, the unclear shipping cost in the hypothetical store is a structural problem. If the shipping amount isn't visible at the right point in the flow, changing the color of the pay button won't help. That's why, in the UI design process, we review structure before visuals.

An approved look doesn't fix a broken flow. It just makes fixing it more expensive.

Sample decision log: “Checkout layout v2 is approved. Placement of the shipping cost is final; the helper text is still open.”

Approving the structure doesn't lock it, though. If later testing turns up something new, revise the structure. Just make its impact on visual design and the schedule clear before you apply the change.

How are visual design and page states designed?

First pick a representative flow, one that contains the product's common components. Design its look, agree on the visual direction, and only then extend it to the rest of the pages. If you design every page too early, each change of taste gets repeated across dozens of screens. That's one of the most common reasons the UI design process falls behind schedule.

• Input: the approved structure, the visual identity and near-real content

• Output: pages, reusable components and their usage rules

• Visual approver: the client representative, after review by the designer and a developer

From this point on, document reusable components such as buttons, input fields and product cards, along with their usage rules. This collection is the core of a design system: shared components and rules that make the product easier to build and maintain. For each page, also design the states beyond the normal view:

I'd also include samples for long text and incomplete content. A product name that wraps onto two lines, or a product with no photo, exposes weaknesses in the layout early.

In responsive design, the layout adapts to the screen size. But shrinking the desktop version isn't enough. On mobile, you sometimes need to change the order of the information as well.

Accessibility means everyone can use the product, including people with low vision and people who use only a keyboard. Put sufficient contrast between text and background into the specs. Define a logical order for moving between elements, and a focus indicator: the visual marker that shows which element is currently active.

The Web Content Accessibility Guidelines are a reliable reference for these criteria. Even so, approving a design mockup doesn't mean the built version is accessible. Test it again after development.

Sample decision log: “The visual direction for the checkout flow is accepted. The payment error state must be completed before this stage is approved.”

What do prototypes and usability testing reveal?

A clickable mockup, or prototype, simulates interaction. Testing it tells you whether users can finish a task without confusion. Usability is the ability to get things done without getting lost or making repeated mistakes. In the UI design process, this test shows the gap between “it looks clear” and “the flow makes sense.”

• Input: designed pages and test scenarios

• Output: an interactive prototype, observations and a prioritized list of issues

• Approver of fixes: the product owner, on the UX designer's recommendation

In the evaluation session, don't ask “Is the design good?” Give a real task instead: “Order a product to a new address.” Then stay quiet and watch. The urge to step in early is strong, but once you help, you can no longer see how the user behaves on their own.

Afterwards, sort the observations into three groups:

• Task blocker: the user can't complete the order.

• Recoverable error: they make a mistake but find the way back themselves.

• Visual preference: “I don't like this color.”

In other words, each issue's impact on the flow sets its priority, not how loudly someone raises it. In the UI design process, this separation keeps debates about taste from crowding out the removal of real blockers.

Sample decision log: “The unclear shipping method blocks acceptance of the flow. After the fix, re-test the same scenario.”

A clickable prototype does have a limit. It doesn't prove how the real gateway behaves, how fast pages load, or how server-side logic (the processing behind the page) works. The team has to test those on the built version.

How are feedback and revision rounds recorded for website design approval?

Collect comments against a specific version, and ask one final client representative to deliver them. Scattered messages from different people never add up to clear design instructions. The output of this stage is a list of decisions, fixes and change requests. When it comes to approving the website design, that same representative signs off, not everyone who had an opinion.

A suggested format for logging each piece of feedback includes:

• Page or state ID, e.g. “Checkout / Error”

• The problem, described in terms of user behavior

• Reason or evidence

• Priority

• Suggested solution (optional)

• Owner

• Status: open, in progress or closed

More important than the format is separating two kinds of request. Fixing a mismatch means the design doesn't match what was agreed. Adding a new requirement means the scope has changed. For example, adding a missing error message is a fix. Installment payments, on the other hand, are a new requirement, and you need to assess their impact on scope.

That's why you should agree on the number of revision rounds, the scope of each round and how feedback will be delivered before work starts. Without that agreement, the UI design process can turn into an endless loop of revisions.

Sample decision log: “Feedback on v3 is consolidated. Installment payments won't enter design until their impact on time and cost is determined.”

An approval only counts when both the decision-maker and the design version are clearly identified.

The table below puts responsibilities side by side: who prepares the output, who provides input and who gives final approval.

Here's a rule I don't bend on: never treat client silence as approval. If no answer comes, mark the status as “awaiting decision” and follow up.

Which decisions drive the UI design timeline?

Scope, access to users and how quickly both sides respond have the biggest effect on the UI design timeline. So the output of this discussion should be a phased plan with checkpoints and dependencies. The project manager and the client representative approve it together.

In practice, design effort and the calendar time from start to delivery aren't the same thing. Designing one flow may not take long, but waiting for content, a technical decision or feedback pushes delivery back. Whenever one stage of the UI design process is waiting on a decision, every stage that depends on it slips too. So instead of a single fixed number, ask the vendor to explain what drives their estimate:

• The number of unique flows, not just the number of pages

• The number of states per page

• The screen sizes that must be covered

• Whether ready-made components and a design system already exist

• The depth of research and the number of evaluation sessions

Sample decision log: “Design of the shipping flow depends on its rules being finalized. If the answer is delayed, this flow's schedule will be revisited.”

Running low-dependency sections in parallel, like the Contact Us page, is fine. But rolling the visual design out on top of an unresolved structure almost always creates rework. To see how these same factors affect your budget, read Factors That Affect UI Design Cost.

What goes into the final approval record and developer handoff?

The final approval document has to state which version has been accepted for development, with what scope and what exceptions. Its input is the revised design and the status of open issues. At this point, the UI/UX design deliverables include an accessible file, pages and states, components, image assets and notes on behavior.

This document actually needs two signatures. The client representative approves the product, and the development lead confirms that what's been handed over is enough to build from. This record marks the end of the UI design process and the start of development. Feel free to copy the template below:

1. Project name and meeting date

2. Version number and a permanent link to the design file

3. Accepted scope

4. Exceptions and out-of-scope items

5. Open items, the owner of each and the agreed deadline

6. Names and roles of the approvers

7. How to request changes after approval

For instance, a hypothetical record might read: “Version 4 of the guest checkout flow is accepted for development. Installment payments are out of scope. The client will complete the shipping helper text by the agreed deadline.”

Conditional approval is fine, but write down the conditions and how they affect the start of development. Trouble begins when the words “final approval” hide an open item that blocks implementation.

In the handoff meeting, go through these with the development lead:

• Every team member's access to the design file, for example a link to Figma (the team's shared design tool), with the right permission level

• Licenses for fonts, icons and images

• How pages behave at different screen sizes

• Descriptions of error states and the wording of messages

Don't confuse design approval with software acceptance. Checking the built version against the design is a separate review after development. If your product is an app, see where this stage fits in App Development Roadmap: From Idea to Launch.

What agreement should you prepare before the kickoff meeting?

Prepare a one-page agreement sheet that summarizes every stage of the UI design process. Include these rows:

• The problem the project must solve

• Scope, and what falls outside it

• The output of each stage

• The decision-maker at each stage

• Feedback method and format

• Acceptance criteria

Then ask the vendor to show what they'd deliver for one sample flow. Ask who gives the go-ahead to move to the next stage. The answer to that question tells you more about how a team works than a polished portfolio does.

If the answer to one of the rows isn't clear yet, there's no need to close it with a rushed decision. Log the open question and assign someone to follow it up.

At Niasa, our approach to UI/UX design: design that's approved before code rests on this same foundation. Every stage has a defined output and approver before anything reaches code. If you have a brief ready, we can go through it together and find the gaps before work starts.