The UI/UX Design Process, Step by Step

A working UI/UX design process for a web or mobile app has seven steps: research, requirements and flows, information architecture, wireframes, prototypes and usability testing, visual design with a design system, and handoff to development. Each step produces a specific deliverable that the next step depends on, and the order matters because fixing a flow on a whiteboard costs minutes while fixing it after launch costs a release. The process scales: a founder with one screen to get right and a product team inside a large company run the same steps, with different depth at each one.

Why process matters more than talent

Most failed app designs were not drawn by bad designers. They were drawn before anyone agreed who the users were, what they were trying to do, or which of the forty requested features mattered. Talent produces attractive screens; process makes sure they are the right screens, in the right order, for the right people.

A process also makes design reviewable. When each step ends in a written or drawn deliverable, stakeholders can approve a flow before pixels exist and developers can estimate from wireframes rather than from a conversation. That is the difference between a design process and a sequence of opinions.

The seven UI/UX design process steps and their deliverables

The table lists each step, the question it answers and what you should have in hand when it ends. UX deliverables are listed by name so you can ask for them.

Step	Question it answers	Deliverables
1. Research	Who uses this, for what, and what gets in their way today?	Interview notes, a short set of user profiles, a list of top tasks, a review of the current product or competitors
2. Requirements and user flows	What must a user be able to do, and in what sequence?	Prioritized task list, user flow diagrams for each top task, edge cases written down
3. Information architecture	How is the product organized and named?	Sitemap or screen map, navigation model, naming conventions
4. Wireframes	What goes on each screen and where?	Low-fidelity screens for every state (empty, loading, error, success), annotated
5. Prototype and usability test	Can real users complete the top tasks?	Clickable prototype, test script, findings and the changes made
6. Visual design and design system	What does it look like, consistently?	Styled screens, component library, tokens for color, type and spacing, accessibility checks
7. Handoff and support	Can developers build it without guessing?	Specs, assets, interaction notes, a design QA pass on the build

1. Research

Talk to the people who will use the product, not only the people paying for it. Five to eight interviews per user type usually surface the recurring tasks and frustrations. If the app replaces something, watch someone use the old tool. Write down the top tasks in the users’ words; they become the test script in step 5.

2. Requirements and user flows

Turn the research into a prioritized list of what the first version must do, and draw a flow for each top task: every screen the user passes through, every decision point, and what happens when something goes wrong. Flows are where most arguments about scope should happen, because they are cheap to change.

3. Information architecture

Decide how the product is organized: the sections, the navigation, the names. A card sort with a handful of users settles naming disputes faster than a meeting. For a mobile app design process this step also fixes the navigation pattern (tabs, drawer, stack) that the platform guidelines expect.

4. Wireframes

Draw every screen in grey boxes, including the states people forget: empty lists, loading, validation errors, permissions denied, offline. Annotate what each element does. Wireframes are the first deliverable developers can estimate from, so keep them complete rather than pretty.

5. Prototype and usability testing

Link the wireframes into a clickable prototype and put it in front of users with the task list from step 1. Fix what fails and test again. Section below covers how to do this without a lab.

6. Visual design and the design system

Apply typography, color, spacing, iconography and motion, and capture them as reusable components and tokens. Check color contrast and touch target sizes against accessibility guidelines before the screens are called done.

7. Handoff and design QA

Give developers specs, assets and interaction notes in the design tool, then review the built screens against the design before release. The second half is the part most teams skip, and it is where the small gaps appear.

Design systems

A design system is the set of reusable components (buttons, inputs, cards, dialogs), the tokens they are built from (colors, type scale, spacing, radii) and the rules for using them. For a single small app it can be a one-page style sheet and a dozen components. For a product line it becomes a shared library in the design tool and a matching component library in code.

The payoff is consistency and speed: a new screen is assembled from known parts, developers build each component once, and accessibility fixes apply everywhere. Start the system in step 6 with the components the first version actually uses, and grow it from real screens rather than designing a library in the abstract. If the app is built in React, Angular, Flutter or React Native, map each design component to a code component by name so the two stay aligned.

Usability testing without a lab

You do not need a facility, a mirror or a budget line to test a design. You need five users per round, a prototype, a task list and an hour.

1. Recruit from your own users or prospects. Five people who match a user profile find most of the serious problems; a second round of five after fixes catches the rest. Offer a small thank-you.
2. Write tasks, not questions. “Find last month’s invoice and download it” rather than “Do you like the invoices page?”
3. Run it over video. Share the prototype link, ask the user to share their screen and think aloud, and stay quiet. Record with permission.
4. Log every stumble. Where they hesitated, what they clicked instead, what they said. Count how many of the five hit each problem.
5. Fix the problems that stopped a task, then retest. Cosmetic feedback can wait; a blocked task cannot.

Two rounds of this, done between wireframes and visual design, prevent most of the rework that otherwise appears after launch. The same method works later on the built product, which is how a website redesign finds out what the old site got right before it is replaced.

How design hands off to development

A clean handoff has four parts. First, final screens for every state live in the design tool with inspectable measurements, colors and assets exported at the sizes each platform needs. Second, interaction notes explain what cannot be seen in a static screen: transitions, validation timing, what happens on slow networks. Third, the component list maps design components to code components, so developers build the library first and the screens second. Fourth, a design QA step is on the project plan, where the designer reviews each built screen and logs differences as tickets.

Handoff goes better when developers were in the room from step 2. They catch flows that are expensive to build, suggest cheaper equivalents, and estimate from wireframes rather than from finished art. In a well-run project, design runs one or two steps ahead of development rather than finishing entirely first; the web application development process and the mobile app build process both assume that overlap.

Where PS3G fits

PS3G runs this UI/UX design process as part of the web applications, websites and mobile apps we build, and as a standalone engagement when a client’s own developers will build the result. Our UI/UX design service covers research through handoff and design QA, with a design system sized to the product. Our web design service applies the same steps to marketing sites and content-driven websites. We work with organizations of every size: a founder who needs the first ten screens right, a company replacing an internal tool that staff dislike, or a product team inside a larger organization that needs design capacity for a release. Because our designers and developers work together, the handoff is a conversation, not a document thrown over a wall.

Related reading

• How to Build a Mobile App for Your Business: From Idea to App Store
• Web Application Development Process: 8 Stages Explained
• Website Redesign Checklist: 40 Steps That Protect Your Rankings
• UI/UX design services

Frequently asked questions

What is the difference between UX design and UI design?

UX (user experience) design decides what the product does, how it is organized and how a user moves through it: research, flows, architecture, wireframes and testing. UI (user interface) design decides how each screen looks and behaves: layout, typography, color, components and motion. In the process above, steps 1 to 5 are mostly UX and step 6 is mostly UI, with the same people often doing both.

How long does the design process take for an app?

It depends on the number of distinct screens and user types, how much research exists already, and how quickly stakeholders review. A small app with one user type and a dozen screens moves through the steps in a few weeks; a product with several roles and integrations takes longer, and design usually continues alongside development rather than finishing first. Ask for a plan with the deliverables above and dates for each.

What UX deliverables should I expect from a designer or agency?

Research notes and user profiles, a prioritized task list, user flow diagrams, a sitemap or screen map, annotated wireframes for every state, a clickable prototype, usability test findings, styled screens, a design system or component library, and handoff specs. If a proposal jumps straight to styled screens, ask where the flows and wireframes are.

Can we skip usability testing to save time?

You can, and the testing then happens after launch, with real customers and at release cost. Two rounds with five users each, run over video between wireframes and visual design, take a few days and catch the problems that block tasks. For a small internal tool, even a single round with three colleagues who were not involved in the design is worth running.

Do we need a design system for a small app?

A small one, yes. Even a dozen screens share buttons, inputs, lists and dialogs, and defining them once keeps the app consistent and makes the code reusable. Start with the components the first version uses and a short set of tokens for color, type and spacing. Grow it only when new screens need new parts.