What Is Included in a UX Design Project?

When a UX design proposal lands on your desk, the price is the easy part to read. The hard part is knowing what you will actually receive for it. Two proposals with the same fee can contain very different work: one might deliver a tested prototype, annotated specifications and support through build, while the other delivers a set of polished screens and a link to a design file. This guide explains UX design project deliverables in practical terms: what a complete project contains, what each deliverable is for, what good looks like, and what is most often left out.

It is written for product managers, founders, marketing leads and in-house design teams who are commissioning UX work from an agency or freelancer, and for practitioners who want a checklist to scope their own projects. The same deliverables apply whether you are redesigning a checkout flow, building a new onboarding experience or creating a design system, although the depth of each changes with the size of the project.

No studio rate is quoted in this article. Where cost comes up, the figures are typical US market ranges, and the goal is to help you understand what moves a project from one end of a range to the other, so you can compare proposals on substance rather than on the headline number.

The short answer: what a complete UX design project contains

A complete UX design project turns a business problem into a design that engineers can build and that has been checked with real users. That journey produces deliverables in seven groups: research and discovery, flows and information architecture, wireframes, visual design and components, prototypes and testing, accessibility, and handoff with build support. A smaller project compresses each group, and an expert review sits at the lightest end, but a proposal that skips a group entirely should say why.

The rest of this guide takes each group in turn. For each one, you will find what it is, why it matters, what good looks like and what is often missing, so you can hold a proposal against it line by line.

Research and discovery deliverables

What it is

Discovery is the work that establishes what problem the design must solve, for whom, and under which constraints. Its deliverables typically include a stakeholder alignment summary, a review of existing analytics and support data, a research plan, interview or observation notes, and a synthesis document. Depending on scope, the synthesis might take the form of personas, jobs-to-be-done statements, a journey map or simply a prioritized list of findings. An expert review, where a practitioner walks through your product against known usability heuristics and produces prioritized findings, is the lightest form of discovery and is often sold as a standalone deliverable.

Why it matters

Every later decision depends on this stage. Without it, the team designs to the loudest stakeholder's opinion, and the testing round at the end becomes the first moment anyone learns whether the direction is right, which is the most expensive time to learn it. Research depth is also one of the main drivers of cost: an expert review is a few days, while moderated testing with recruitment takes weeks and has a participant budget.

What good looks like

• A research plan that names the questions to be answered, the method for each, the participant criteria and the number of sessions, written before any sessions happen.
• Findings that point to evidence: a quote, a recording timestamp, an analytics chart or a support ticket category, so that stakeholders can check them.
• A clear line from findings to design decisions, so you can see why a flow looks the way it does.
• A short list of success measures agreed at the end of discovery, such as task completion, time on task or a drop in a specific support ticket category.

What is often missing

The most common gap is synthesis. Proposals promise "user interviews" but not the analysis that turns them into decisions, so you receive recordings and no conclusions. The second gap is a written problem statement. If discovery ends without one that stakeholders have signed off, the project will drift. Workshops are a good way to reach that agreement quickly; our guide to facilitating design workshops covers how to run them so they produce decisions rather than sticky notes. For realistic time frames for each research method, see how long UX research takes.

User flows and information architecture

What it is

User flows are diagrams showing each step a person takes to complete a task, including decision points, branches, errors and exits. Information architecture (IA) covers how content and features are organized and named: the navigation structure, the hierarchy of pages or screens, and the labels people see. Together they define the skeleton of the product before anyone draws a screen.

Why it matters

Flows are where most of the design effort and most of the cost sit. A useful rule from pricing UX work is that screens are cheap and flows are expensive: count decisions, not artboards. A settings page with forty fields might be one flow with few decisions, while a three-screen checkout could contain a dozen branches for payment failures, address validation, promo codes and guest versus account purchase. The number of unique flows is the first thing to check when comparing proposals, because it tells you how much design thinking is included.

What good looks like

• One flow diagram per task in scope, listed by name in the proposal so both sides agree what is covered.
• Error states, empty states, loading states and permission states drawn into the flow, not left for engineers to invent.
• Navigation labels tested or at least checked against the words users used in research.
• For products on more than one platform, flows that note where web, iOS and Android differ. These platforms have different conventions, and pretending otherwise produces something that feels wrong on all three.

What is often missing

Edge cases. A proposal that lists "checkout flow" without saying whether it includes failed payments, saved cards, address errors and order editing has left the scope open, and the gaps tend to surface during build as change requests. Ask for the list of flows and the states each will cover, in writing.

Wireframes and interaction notes

What it is

Wireframes are low-fidelity layouts of key screens that show structure, content priority and interaction without visual styling. They are often accompanied by interaction notes explaining what happens on tap, hover, validation or submission. In a typical project, wireframing takes 1–3 weeks.

Why it matters

Wireframes are where stakeholders can argue about the right things. When a screen has no color, typography or imagery, the conversation stays on content order, hierarchy and behavior, which are the decisions that shape usability. Changes at this stage cost hours; the same changes after visual design cost days.

What good looks like

• Wireframes for every key screen in each in-scope flow, linked so they can be walked through in sequence.
• Real or realistic content rather than placeholder text, so length and hierarchy problems appear early.
• Annotations that explain behavior and rules, such as "show saved addresses first; if none, open the new address form."
• A documented review with named approvers before visual design begins.

What is often missing

A formal review point. Many projects slide from wireframes into visual design without an explicit sign-off, and structural objections then arrive when the screens look finished. Build a review into the plan, and structure it well; our practical guide to design critique and review explains how to keep feedback focused on the goals rather than on taste.

Visual design, components and the design system question

What it is

Visual design applies your brand to the wireframes: typography, color, spacing, iconography, imagery and motion. The deliverables are high-fidelity screens for each state in scope, plus the reusable components used to build them. In a typical project, visual design takes 2–5 weeks. At the larger end, the work becomes a design system: a library of components, design tokens (named values for color, spacing, type and so on), documentation and the governance to keep it alive.

Why it matters

This is the layer users see and the layer engineers build from. Components matter as much as screens, because they decide whether the next feature can be designed and built quickly or must start from scratch. Designing components once and documenting them costs more up front and less in every subsequent feature.

What good looks like

• Screens for every meaningful state: default, loading, empty, error, success, disabled, and responsive breakpoints for web.
• Components built with variants and properties in your design tool, so a button is one component with states rather than twelve loose copies.
• Design tokens named for purpose (for example, a token for primary text color) rather than raw values, so theming and dark mode are possible later.
• Where you already have a component library, designs that use it faithfully and a list of any new or changed components the project needs.

What is often missing

States and constraints. Designs often show only the ideal case with short names, perfect photos and full data. The other gap is honesty about existing constraints: designing inside a legacy system or a fixed component library is faster to build and slower to design well, and a proposal should say which situation it assumes. If your project is really a design system, scope and price it as one; our breakdown of how much a design system costs explains what drives that range.

Prototypes and usability testing

What it is

A prototype is a clickable or interactive version of the design that people can use as if it were real, built in a design tool or in code. Usability testing puts that prototype in front of representative users with realistic tasks, observes where they succeed and struggle, and turns the observations into design changes. A typical testing round takes 1–2 weeks including recruitment.

Why it matters

Testing is the only deliverable that checks the design against reality rather than against the opinions of the people in the room. Even one round with a small number of participants tends to reveal problems that nobody on the team could see, because everyone on the team already knows how the product is supposed to work.

What good looks like

• A test plan with tasks, participant criteria, number of sessions and what counts as success for each task.
• A recruitment approach and a participant incentive budget that is stated in the proposal, not discovered later.
• A findings report ranked by severity, with evidence for each finding.
• A second version of the design showing what changed as a result, which is the actual deliverable; the report alone is only half of it.

What is often missing

Time to act on the results, and clarity about who recruits participants. Testing is also sometimes confused with A/B testing after launch. Both are useful, but they answer different questions: usability testing explains why people struggle before you build, while live experiments measure which variant performs better with real traffic. Use usability testing to shape the design before build, and keep live experiments for choosing between well-made variants once real traffic is available; a small product with little traffic may not be able to run meaningful experiments at all.

Accessibility deliverables

What it is

Accessibility deliverables make sure the design can be used by people with visual, motor, hearing and cognitive disabilities. They include color contrast checks, focus order and keyboard behavior annotations, labels and alternative text guidance, touch target sizes, heading structure, and notes for screen reader behavior on custom components. The usual target in proposals is WCAG 2.1 AA; WCAG 2.2 is the latest version of the guidelines and adds further success criteria, so it is worth agreeing which version your project will design to.

Why it matters

Accessibility is far cheaper to design in than to retrofit. Designing to WCAG 2.1 AA from the start adds a little. Auditing and retrofitting adds a lot, because contrast, focus order and component structure affect almost every screen and component.

What good looks like

• The target standard and level written into the proposal and the acceptance criteria.
• Contrast checked for every text and interface color pairing in the palette, including states such as disabled and error.
• Annotations on the designs for focus order, accessible names, and behavior of custom controls such as carousels, tabs and date pickers.
• Where budget allows, testing with at least some participants who use assistive technology.

What is often missing

Annotations. Many designers check contrast but leave keyboard behavior and screen reader naming entirely to engineers, which means the accessible experience is designed by default rather than by intent.

Handoff and build support

What it is

Handoff is the transfer of the design to the engineers who will build it. Its deliverables include inspectable design files, specifications for spacing and typography, exported assets, interaction and animation notes, token definitions, and a walkthrough session. Build support is the designer's continued involvement while the product is being built: answering questions, adjusting designs to technical constraints, and running design QA to check the implementation against the design. In a well-run project, handoff and support continue through the build rather than stopping on a date.

Why it matters

This is where good designs most often lose quality. Engineers fill gaps with their own decisions, often sensibly, but the sum of those decisions can drift a long way from the tested design. A modest amount of designer time during build protects everything that came before.

What good looks like

• Files organized by flow, with a clear "ready for development" status for each screen.
• Tokens exported in a format engineering can use, and components mapped to their code equivalents where a library exists.
• A defined channel and response time for questions during build.
• At least one design QA pass on a staging build, with issues logged by severity; our article on design QA before release covers how to run it.

What is often missing

Build support is often absent from fixed-fee proposals, or limited to a single handoff meeting. Ask how many hours of support are included, over what period, and what happens if the build runs later than planned.

How scope differs by project size and price tier

Most UX work falls into one of three tiers. The ranges below are typical US market ranges, not our rates, and they are wide because the cost drivers in the next paragraphs vary so much between projects.

What moves a project within its range

• Number of unique flows. Screens are cheap; flows are expensive. Count decisions, not artboards.
• Research depth. An expert review is a few days. Moderated testing with recruitment takes weeks and has a participant budget.
• Design system scope. Designing components once and documenting them costs more up front and less in every subsequent feature.
• Existing constraints. Designing inside a legacy system or a fixed component library is faster to build and slower to design well.
• Accessibility. Designing to WCAG 2.1 AA from the start adds a little. Auditing and retrofitting adds a lot.
• Number of platforms. Web, iOS and Android each have their own conventions, and each adds design and review effort.

Worked example: sizing a flow design project

The following example is illustrative, not a client project or a quote. Imagine a software company that wants to redesign its trial sign-up and onboarding. Listing the tasks rather than the screens gives five flows: create an account, verify email, invite teammates, connect a data source and complete a first setup checklist. Counting decision points inside those flows gives, say, 23: email already in use, verification link expired, invitation to someone already on another account, connection failure with three possible causes, skipping a step and returning later, and so on. The screen count might be around 30, but the 23 decisions and 5 flows are what drive effort.

Now apply the drivers. The product is web only (one platform), it already has a component library the team must use (faster to build, slower to design well), research needs one round of moderated testing with recruitment (adds weeks and a participant budget), and the company wants WCAG 2.1 AA from the start (adds a little). That profile sits within the feature or flow design range of $5,000 – $30,000. Five flows with this many decisions and a moderated testing round would place it in the middle or upper part of that range rather than at the bottom; adding native iOS and Android versions would push it toward the top or beyond it, because each platform multiplies flows to design and review.

Phases often overlap, and the schedule depends on how quickly your team reviews work, so treat each duration on its own rather than adding them together. For a full discussion of schedules, see how long a UX design project takes.

What the final handover should include

Handoff to engineering happens during the project; the final handover happens at the end and transfers everything you need to own and continue the work without the supplier. It is easy to forget, and expensive to reconstruct later.

• Source files in your own workspace or account in the design tool, not the supplier's, with edit rights for your team.
• Research assets: the research plan, anonymized notes, the synthesis, consent records handled according to your privacy obligations, and recordings where participants agreed to share them.
• Prototype links that will keep working after the engagement ends.
• Component and token documentation, including usage rules and the reasoning behind non-obvious decisions.
• A decision log recording what was decided, when, by whom and why, so later teams do not reopen settled questions.
• Font and asset licenses transferred or confirmed as licensed to you, including any stock imagery or icon sets.
• Open issues: a list of known gaps, deferred items and design QA issues not yet fixed, which is the start of your design debt register. Our guide on getting design debt right explains how to manage that list.

Contract terms to check before you sign

Deliverables only protect you if the contract describes them. Read the statement of work with the checklist at the top of this guide beside it, and look closely at the following terms.

Scope definition

The scope should list flows by name and the states each will cover, the platforms, the number of research and testing sessions, and the accessibility standard. "Redesign of the onboarding experience" is not a scope; "five named flows on web, including error and empty states, designed to WCAG 2.1 AA" is.

Revision rounds and change control

Check how many rounds of revision are included at each stage, what counts as a revision versus a change in scope, and how changes are priced and approved. A clear change process protects both sides and prevents arguments about whether a new edge case is "included."

Intellectual property and ownership

Confirm that ownership of the final designs, and of the research you paid for, transfers to you on payment. Check whether the supplier keeps the right to show the work in their portfolio and whether that needs your approval, especially for unreleased products.

Confidentiality and tool accounts

If the project involves unreleased features, customer data or internal analytics, the contract should include confidentiality terms and say how access is granted and removed. Agree at the start whose design tool account holds the files. Working in your workspace from day one removes a transfer step at the end and means your team can watch progress, comment and keep the files if the engagement ends early for any reason.

Research logistics

Who recruits participants, who pays incentives and who holds participant data? The contract should say, and the data handling should match your privacy obligations.

Build support terms

Confirm the hours or duration of build support, the response time, and what happens if your engineering start date slips. A support window that closes before build begins is worth nothing.

Acceptance and payment milestones

Tie payments to deliverables that you can check (signed-off wireframes, test findings plus revised designs, a complete handover) rather than to dates alone. For questions to raise in the conversations before contracting, see questions to ask before hiring a UX design agency.

How to compare UX proposals side by side

Proposals are written to look complete, and they rarely use the same structure. To compare them fairly, rebuild each one against the same list of deliverables.

1. Map each proposal to the checklist. For each deliverable group, note whether it is included, partly included or missing. A gap is not necessarily wrong, but it should be deliberate and explained.
2. Count flows, not screens. Ask each supplier to list the flows and decision points they have scoped. Different counts usually explain most of the difference in price.
3. Compare research depth. An expert review, a handful of interviews and moderated testing with recruitment are different products. Make sure you are comparing like with like.
4. Check what happens after testing. Time for revisions after the test is the sign of a supplier who expects to learn something.
5. Check build support and handover. Look for hours, duration and a named handover list.
6. Look at the team. Ask who will do the work day to day and how they will collaborate with your team; our guide to working with external design teams covers what a healthy arrangement looks like.
7. Only then compare price. Place each proposal within the market ranges above and ask whether its position is explained by the cost drivers.

A proposal at the low end of the feature or flow design range that includes testing, build support and a full handover may be better value than one at the upper end that includes none of them, and the opposite can also be true. The checklist makes the difference visible. If you would like to see how we structure this kind of work, our UI and UX design services page sets out the approach.