
Comparing UX design proposals by price alone can make very different services look interchangeable. One proposal may include research with customers, while another covers a visual refresh of existing screens. Before comparing fees, put the problem, scope and acceptance criteria into a shared brief.
This guide is for product leaders, founders and teams buying design services. The aim is to commission work that supports useful decisions and implementation, rather than select the longest list of deliverables.
Describe the target user, the task that matters and the problem you currently observe. In a hypothetical B2B product, “understand where new customers struggle to create their first report” is a more useful starting point than “make the dashboard look modern.” Share access constraints, the state of your analytics and relevant technical dependencies.
If research is needed, state what you need to learn. The GOV.UK research planning guide recommends identifying research questions and relevant user groups before choosing methods.[1] This helps turn a vague promise of “user research” into a discussion about an actual investigation.
| Criterion | Look for | Ask if unclear |
|---|---|---|
| Research | Questions, methods and participant profile | Who recruits participants and analyses findings |
| Scope | Journeys, roles, platforms and states | Are mobile layouts and error states included |
| Deliverables | Files, prototype and annotations | What will developers receive |
| Revisions | Feedback and approval process | How is a correction distinguished from new scope |
| Implementation | Handoff and development support | Will the implementation be reviewed |
Screen count is an incomplete measure of scope. A single screen may need decisions about empty data, permissions, loading and failure. Not every project needs every state, but a proposal should explain which ones are included. Otherwise, two identical screen counts may represent very different amounts of work.
“A Figma file will be delivered” identifies an output, not whether the output is ready to use. For a payment journey, acceptance might require the standard path, failed transactions, retries and confirmation states to be documented. A prototype should explain what it is intended to test and which parts are only visual representations.
Identify who approves each stage. If product, engineering and marketing provide conflicting feedback, agree who resolves it. Good delivery depends on the buying team's decisions as well as the agency's process. Include these responsibilities in the proposal discussion.
Compare assumptions before interpreting a higher fee as higher quality. Is the content ready? Can an existing design system be reused? Does the client provide research participants? Is support during development included? Request a clear list of exclusions, third party costs and the process for pricing changes.
In the final discussion, ask each candidate how they would approach the same example journey. You do not need speculative design work for free. You need to understand what they would investigate, which risks they would address and how they would decide what to do next.
Not necessarily. Useful coverage of critical tasks and relevant states matters more than the number of screens. Extra screens do not automatically create customer value.
No. Research can reveal needs that were not visible at the start. Agree how changes and reprioritisation will be handled alongside the initial scope.
Reassess proposals using one shared brief and comparison table. Explore VOYA UI UX design services to discuss a clearer scope. For broader questions about agency fit, see the guide to choosing a UX agency.
Do you have a clear vision regarding the ideas, goals, requirements, and desired outcomes for your project? Let's take the first step together by setting up a meeting to bring all of these to life.