The UX and UI Design Process for a Web or Mobile App: What Happens and What You Should Receive

Many late arguments in a software project are about something nobody drew before it was built. Design is the stage where those decisions are cheap to change: moving a box on a wireframe takes minutes, while moving it in a finished app means rework in code, testing and release.

This guide explains what a UX and UI design process looks like for a web or mobile app, what you should receive at each stage, and what you are actually approving when a designer sends you a link.

UX and UI Are Different Jobs

UX (user experience) design decides what the product does and how people move through it: which screens exist, in what order, what each one asks for, and what happens when something goes wrong. UI (user interface) design decides how those screens look and respond: layout, type, color, spacing, icons and the states of every button and field.

The distinction matters commercially because the two are approved at different times. If you sign off on attractive screens before the flow underneath them is agreed, you pay for visual polish on screens that may later be removed or restructured. One person can do both jobs. The order of the work matters more than the job titles.

Research, User Flows and Wireframes

Research

For most business apps this is short: conversations with you, a few real users or front-line staff, and a review of the system or spreadsheet being replaced. You should receive a brief summary of who the users are, the tasks they need to complete, and the constraints. You are approving that the user groups and their priorities are right.

User flows

A user flow is a diagram of the steps for one task, including the branches: what if payment fails, what if the user is not logged in. Treat this as your scope check. Every role and every task should appear here, because a flow missing at this stage becomes a missing feature later.

Wireframes

Wireframes are plain grayscale layouts that show what is on each screen without any styling. You are approving content and structure: what information appears, in what order, and which actions are available. Comments about color or fonts do not belong here yet.

Visual Design and the Design System

The designer normally styles two or three key screens first to set a direction. Approve that direction before it is rolled out across every screen, because changing your mind afterward multiplies the work.

Alongside the screens you should receive a design system: a shared library of reusable parts (colors, type styles, spacing, buttons, form fields, cards) with rules for using them. It saves money later because each component is designed once, built once in code and then reused. New screens are assembled from existing parts, and a change to the button style is made in one place instead of on forty screens. A small app needs only a light version; a heavily documented system is excessive for a first release. Reuse of this kind is one of the factors covered in our guide to custom software cost drivers.

Prototype and Usability Testing

A clickable prototype links the designed screens together so the app can be tapped through in the design tool, with no code written. It is the first time the product feels real, and the last cheap moment to find out that it confuses people.

In usability testing, a small number of people from the target audience are given tasks and observed without help. You should receive a list of findings ranked by severity and the design changes proposed for each. Your decision is which problems are fixed now and which wait. For a small internal tool, even watching two colleagues attempt the main task is far better than no test at all.

Accessibility Is a Design Decision

The reference standard is the Web Content Accessibility Guidelines (WCAG) from the W3C. WCAG 2.2 was published on 5 October 2023, is organized around four principles (perceivable, operable, understandable, robust) and has three conformance levels: A, AA and AAA. WCAG 3 is described by the W3C as an incomplete draft, so current projects should work to 2.2.

Several requirements are decided by the designer, not the developer. At Level AA, normal-size text needs a contrast ratio of at least 4.5:1 against its background, and pointer targets should be at least 24 by 24 CSS pixels, with some exceptions. At Level A, color must not be the only way information is conveyed, so an error marked only in red fails. Fixing these after launch can mean changing brand colors and layouts, which is why the level you are designing to should be agreed at the start. WCAG is written for web content, and its principles are commonly applied to native mobile apps as well.

Accessibility law in the United States and the United Kingdom varies by sector and type of organization. This is not legal advice; ask your own counsel what applies to you.

Handoff to Developers

Handoff is a package, not a folder of screenshots. Expect to receive:

• Final screens for each supported screen size, with spacing, sizes and colors that developers can inspect
• Every state of each component: default, focused, disabled, loading, error and empty
• Exported icons and images, plus the design system file
• Notes on behavior a picture cannot show, such as validation rules, transitions and what happens on a slow connection

Confirm in the contract that you receive and own the editable source files. Design work should also continue during the build: the designer reviews the coded screens against the designs, because small differences accumulate quickly.

How to Give Useful Feedback

Describe the problem, not the fix. "I cannot tell which plan I am on" gives a designer something to solve; "make the label bigger" may not solve it. Tie each comment to a user and a task instead of personal taste, and mark which points are must-fix and which are preferences.

Collect feedback from all stakeholders into one list, with one person who resolves contradictions before it is sent. Comment on what the current stage is asking you to decide, and agree the number of revision rounds in advance so both sides know when a stage is closed.

Common Mistakes

The most expensive one is designing only the ideal case: a screen with tidy data, short names and a perfect connection. Real use includes the first-time user with nothing to show, a search with no results, a 60-character company name, a list of 300 items, a declined card and no signal. If these states are not designed, developers improvise them under deadline. Ask to see them.

Other frequent problems:

• Skipping wireframes to see the "real" design sooner
• Designing for one phone size, or for desktop only
• Using placeholder text instead of real content, which hides layout problems
• Ignoring iOS and Android conventions, so the app feels foreign on one platform
• Reopening approved stages without accepting the effect on time and cost

What to Do Next

Before you brief a design team, write down the user roles, the three to five tasks that matter most, and a few apps you like with the reason for each. Gather real content: product names, sample records, actual form fields.

Then ask the team which stages they follow, what you receive at each, how many revision rounds are included, who the design will be tested with, which WCAG level they design to, and who owns the files.

Conclusion

A sound design process moves from structure to appearance: research and flows fix what the product does, wireframes fix what is on each screen, visual design and a design system fix how it looks, and a tested prototype shows whether people can use it. Each approval narrows what can change cheaply, so it pays to review each stage for what it is actually deciding.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you would like a design and build plan scoped around your users and tasks, you can request a quote.