Ask five design agencies what a UI/UX redesign costs and you'll get five different numbers, often for the same brief. That's not because agencies are cagey about pricing — it's because UI UX design cost isn't really a function of "how many screens," the way most quote requests imply. It's a function of six variables that rarely get named out loud: how much discovery work happens before anyone opens a design tool, how many distinct flows and states need designing, whether you're building a design system or reusing one, how polished the prototype needs to be, how many revision rounds are built into the process, and how much hand-holding the design team does during development. Get a handle on those six levers and you can scope — and sanity-check — almost any quote that lands in your inbox.
Why "cost per screen" is the wrong mental model
Most first-time buyers of design services ask an agency to price a redesign the way they'd price a print job: count the pages, multiply by a rate. Screens are the visible output of UI/UX work, but they're rarely where the hours go. A ten-screen dashboard with three user roles, three permission states, and edge cases like empty data and error handling can take longer than a thirty-screen marketing site where every page follows the same three-column template. The number that actually predicts effort is the number of unique decisions a design team has to make — and that number is driven by the six factors below.
The six variables that actually move the price
Every UI/UX engagement, from a marketing site refresh to a full SaaS design system rebuild, prices out along the same axes. Understanding them lets you have a much more precise conversation with whoever quotes your project.
1. Research and discovery depth
Some projects start with an existing product, a defined user base, and clear complaints, like a checkout that abandons at step three. Others start with a hypothesis and nothing else. The gap between auditing the current flow and interviewing a handful of existing users versus running generative research to figure out who the users even are is often the single biggest swing factor in a quote. Discovery can be a two-day exercise or a three-week one, and every hour of it compounds into the design decisions that follow.
2. Number of user flows and screen states
A flow isn't a screen — it's a path a real person takes to accomplish something, including every branch: success, error, empty, loading, permission-denied, edge case. A "simple" settings page can hide five or six states once you account for validation errors and role-based visibility. Pricing scales with flows and states far more reliably than with screen count, which is why two projects with an identical page count can carry wildly different quotes.
3. Design system creation vs. reuse
Building a design system — tokens, components, documented states, accessibility rules — from scratch is a project in itself, often a large share of total effort on a first engagement. If a mature system already exists and the work is applying it to new flows, that cost mostly disappears. This is one of the most common reasons two agencies quote the same brief differently: one assumed system-building, the other assumed reuse, and nobody said so out loud.
4. Prototyping fidelity
Static wireframes are fast to produce. Clickable, high-fidelity prototypes with real transitions, conditional logic, and content that mimics production data take meaningfully longer to build — and they're worth it when a design needs stakeholder buy-in, investor review, or usability testing before a single line of code gets written. Low-stakes internal tools rarely need that level of polish; customer-facing products usually do.
5. Revision rounds
Two rounds of feedback baked into a quote is normal. "Unlimited revisions" sounds generous until you realize it removes any incentive to converge, and projects can drift for months without a clear finish line. The healthiest engagements define a fixed number of structured review rounds per phase, with anything beyond that scoped as a change order. Ask about this explicitly — it's one of the most common sources of budget overrun and scope creep on design projects.
6. Handoff and developer-collaboration overhead
Design that ends at a set of static files is cheaper than design that ends with a shipped product. Specs, redlines, component documentation, and ongoing designer availability during a build all add cost — but they also cut development rework dramatically. If the same team is handling both UI/UX design and web development, this overhead often shrinks, because there's no interpretation gap between what was designed and what gets built.
Lightweight redesign vs. full design-system build
Most quotes fall somewhere between two poles. Neither is inherently the right call — they solve different problems.
| Lightweight redesign | Full design-system build | |
|---|---|---|
| Typical trigger | Product looks dated, conversion is soft, no major new features planned | Multiple products or teams, inconsistent UI, planned scale-up or rebrand |
| Discovery | Heuristic audit, light user feedback review | Structured research, stakeholder workshops, competitive teardown |
| Output | Refreshed screens using existing patterns | Documented tokens, components, states, and usage guidelines |
| Reusability | Low — largely one-off work | High — every future screen gets faster and cheaper |
| Best fit | Single product, tight timeline, modest budget | Multi-product roadmap, in-house team needs a shared system |
A lightweight redesign is the right call when the goal is to make a product feel current and fix obvious friction without touching the underlying architecture. A full design-system build makes sense the moment you're designing for more than one surface — web plus a mobile app, or a product with the kind of dense, multi-state dashboards similar to what we built for the InsightIQ analytics dashboard. The system costs more upfront and pays that back on the second, third, and tenth screen it touches.
A mental model for scoping your own project
Before requesting quotes, answer these questions honestly — they'll tell you more about likely cost than any screen count would:
- Do we already understand our users' problems, or does someone need to go find that out first?
- How many distinct flows exist, counting every error, empty, and permission state, not just the happy path?
- Do we have a design system today, even an informal one, or is this greenfield?
- Who needs to sign off, and do they need a clickable prototype to do it, or will static mockups do?
- How many review cycles does our internal process realistically require before something ships?
- Will the design team stay involved through development, or is this a clean handoff to an internal or separate engineering team?
Write down honest answers to those six questions and you'll be able to tell, before a single proposal arrives, roughly whether a lightweight refresh or a full system build is the realistic range for your project — and you'll be equipped to push back when a quote doesn't match the scope you actually described.
Get a scope, not just a number
The most useful thing you can ask a design partner for isn't a price — it's a scoped breakdown showing which of these six variables they've assumed and which they haven't. That single document prevents most of the disputes that derail design engagements later. If you're weighing a redesign and want a straight answer on where your project falls on this spectrum, request a quote or get in touch and we'll walk through the scope with you before any number gets attached to it.
Need this built, not just explained?
We do this work for clients every week. Send us your situation and we'll come back with a scope and a price range within one business day.
Get articles like this monthly
Engineering and AI notes from real client work. One email a month, unsubscribe anytime.