Estimate UI/UX design from the decisions and deliverables the product needs: research, task flows, interface states, prototypes, evaluation and engineering handover. A screen count can help describe the output, but it does not capture the full design scope. Ask each supplier to explain the included work, evidence, revisions and acceptance criteria before comparing total prices.
Let’s estimate your UI/UX design budget.
Talk through your requirements with Drema. We’ll help you clarify the scope, explore the trade-offs and plan the next steps for your project.
Identify the engagement you need
An audit diagnoses an existing product. A new-product design engagement develops the proposed workflow and interface. A redesign must also understand current behaviour, constraints and migration from existing patterns. Those starting points require different work.
Describe the decision you need to make. You may need to understand why users abandon setup, validate a workflow before development or prepare a consistent interface for implementation. Avoid buying a large set of polished screens when the unresolved problem is whether the task makes sense.
Build a deliverables-based scope
| Workstream | Output to agree | Acceptance question |
|---|---|---|
| Discovery | Audience, tasks, constraints and open questions | Is the team solving the agreed problem? |
| Research | Method, participants or evidence and findings | Can recommendations be traced to the work performed? |
| Workflow | Main path and relevant exceptions | Can the intended task be completed? |
| Interface | Components and meaningful states | Are loading, error, empty and permission states covered? |
| Prototype | Agreed interactions and limitations | What can the prototype demonstrate? |
| Evaluation | Findings and resulting design decisions | What was tested and what remains a hypothesis? |
| Handover | Files, behaviour, assets and implementation notes | Can engineering implement without guessing key rules? |
Research and evaluation are not interchangeable labels. Ask which methods are included and who will participate. A stakeholder review is useful for alignment, but it is not evidence that representative users completed the task.
Use effort and rate transparently
A budgeting worksheet can record each deliverable, estimated effort, dependencies and the agreed commercial basis. If the supplier prices a fixed engagement, ask how its scope and revision process are bounded. If the work is time-based, agree how progress and decisions will be reviewed.
Design budget = agreed workstreams + explicit research costs + agreed evaluation and revision work + handover support.
The formula is a scope structure, not a market-price estimate. Participant recruitment, specialist review, travel or translation may be relevant in a particular engagement. Record whether those costs are included or separate rather than assuming they apply to every project.
An illustrative scope comparison
Imagine two proposals for an approval dashboard. Proposal A includes a main dashboard, request details and a visual style. Proposal B also includes role-based views, returned requests, empty queues, failed submissions and handover notes.
These are hypothetical proposals. Their screen counts might look similar, while their implementation readiness differs. The useful question is whether the deliverables cover the required task and states, not which supplier produced the largest screen total.
Ask both suppliers to demonstrate one request moving from creation to decision, including a correction. Record what the prototype supports and what is only described. Identify any behaviour left for engineering to invent.
Include accessibility responsibilities early
Agree which accessibility considerations and reviews are part of the design work, and which require implementation verification. A design file alone cannot prove the behaviour of the finished interface.
W3C WAI's planning resources provide guidance on incorporating accessibility activities and responsibilities into projects. Use the applicable requirements to define the review scope with the responsible team, rather than treating a generic accessibility badge as an acceptance result.
Define revision and handover boundaries
Clarify what happens when feedback reveals a new requirement. Distinguish correcting a missed agreed state from adding a new user role or workflow. Ask how decisions and unresolved questions will be recorded.
For handover, request editable source files, component behaviour, responsive expectations, assets and important edge cases. Agree whether the designer reviews the implemented result and how implementation differences are handled.
Link the design engagement to its development context. A mobile application, an internal enterprise console and a public content site can need different interaction and delivery decisions.
Questions buyers ask
Is a cheaper per-screen quote better value?
Only if the included scope meets your needs. Compare research, states, evaluation, ownership and handover on the same basis. A low screen price does not explain omitted work.
Do we need a full design system for an MVP?
Define the consistency and reuse needed for the first release. A small documented component set may be sufficient; broader governance can be a separate decision. Avoid buying or building an artifact without a clear use.
Can a UX audit quote include implementation?
It can, if explicitly scoped. Confirm whether the engagement diagnoses issues, designs fixes, implements them or verifies the result. Those are different responsibilities.
Prepare comparable requests
Bring the audience, workflows, existing product and decisions you need help making. Request a deliverables table and a review plan through Drema's UI/UX design service. For an existing-product diagnosis, start with the website and app audit.