Why does screen count fail to explain the design cost?
Within an interface design process, a simple login screen is different from an administrative screen with several roles and bulk actions. The main appearance may also need empty, loading, error, successful and unauthorised states. “Twenty screens” is not a comparable quantity until those states are defined.
Flows, decision points, device coverage, content length and integration behaviour also matter. The same page can need a different arrangement on mobile. A visual refresh and a new information architecture have different responsibilities even when both are labelled UI/UX.
The buying team should share the main user tasks as well as an initial screen list. Explain what needs to change, the existing problem and how acceptance will be checked. You do not have to know every screen in advance; an uncertain area may require discovery before a reliable delivery estimate.
This avoids comparing an attractive but narrow proposal with a broader product engagement as though the higher price only reflects the supplier's preference.
How should research and expert review be budgeted?
Research into the audience and product need produces different deliverables from visual design. Reviewing existing data, conducting an expert assessment, interviewing users and observing task performance answer different questions. Expert judgement is not the same evidence as observed user behaviour.
A proposal should identify who recruits participants, which profile is required, how sessions are organised and how findings are documented. Recruitment, suitability checks and team coordination are real work even though they do not appear as screens in the design file.
If no user research is conducted, identify the assumptions honestly. One interview round does not validate an entire market either. Ask what the existing evidence supports and which decisions remain uncertain.
The phrase “research included” should therefore lead to a method, participant arrangement and output, rather than remaining a broad label. The appropriate depth depends on the question and risk being addressed.
Expert assessment
Professional review of problems in the current journey. It should not be presented as a user test.
Interview
Discussion of the participant's problem, context and existing behaviour, with a plan and documented findings.
Task observation
Watching a specified action in a prototype or product, with defined participants, tasks and interpretation.
FROM READING TO A NEXT STEP
Compare UI/UX proposals using a clear scope
Share the product summary, main user tasks and existing proposals. We can map research, design and handoff differences in one comparison.
How do you define design-system and responsive scope?
In a product design and delivery plan, a colour-and-button file is different from a maintained component system. States, variations, interaction rules and examples need definition. The person using the system should understand which component fits the situation.
If an existing system will be reused, check whether it supports the product's tasks, defines responsive behaviour and contains obsolete elements. Adopting a file, filling its gaps and maintaining it can be separate commitments.
Specify accessibility and language coverage as well. Longer translations, keyboard use, focus, contrast and error explanations influence the interface. “Mobile design included” is ambiguous without the relevant screens, states and widths.
A comprehensive system is not mandatory for every small project. Select an appropriate level of reusable components and documentation, with someone responsible for changes. Otherwise an expensive library can remain unused or an apparently cheap one can leave essential rules undefined.
What should the design file and developer handoff include?
For a web application being developed, the source file, prototype, interaction notes, assets and responses to engineering questions are separate deliverables. Screen images alone do not describe every behaviour. Opening, closing, failed requests and absent data can need explicit treatment.
File organisation, naming, component relationships and the location of the current version matter. A joint design-and-engineering review can expose impractical or unclear details early. Define the capacity or sessions available for that collaboration in the proposal.
Checking the implemented interface requires additional time. Is a post-implementation review included? Will the designer report differences, and will corrections be rechecked? Design and software development are different services even when one team supplies both.
Acceptance should make that boundary visible. A completed design file does not establish that the implemented product behaves correctly, while a functioning build can still differ from the agreed interaction and visual requirements.
How do you compare pricing models, revisions and timelines?
When purchasing design for an MVP scope, send the same brief to each provider. Include user roles, main tasks, devices, current content, research needs, prototype expectations and delivery requirements. Request explicit exclusions as well as inclusions.
Fixed deliverables, hourly work and ongoing capacity each handle uncertainty differently. A clear scope can support a fixed comparison. If discovery is still under way, separating the research or scoping phase may be more useful than assuming the entire product can be priced accurately now.
There is no universal project rate or pricing model that wins in every situation. Imported marketplace averages and another provider's starting price are not an estimate for your product or a Prix quotation.
Define what a revision round means and who approves decisions. “Unlimited revisions” may leave the timetable and scope unclear. Adding a new flow is different from correcting the appearance of an approved flow. Participant recruitment, feedback and approvals can also be dependencies in the schedule.
| Item | Question for the proposal | Acceptance evidence |
|---|---|---|
| Research | Are method, participants and reporting included? | Findings linked to observations |
| Design | Which flows, states, devices and components? | Current source and explained behaviour |
| Revisions | How are rounds, approvals and changes handled? | Approved version and change record |
| Handoff | Are engineering support and implementation review included? | Notes, assets and review findings |
How do you distinguish a lower price from missing scope?
A technical leadership review can compare the design proposal with implementation needs. A lower fee is not automatically poor quality, and a higher one does not prove a better outcome. Consider the work and coordination another team must perform if a deliverable is excluded.
For example, a proposal delivering only visual screens differs from one including research, task testing and engineering collaboration. If your own team already owns those other tasks, the narrower proposal may be appropriate. If nobody owns them, missing scope can become a new discussion during delivery.
Before selection, document assumptions, exclusions, acceptance, file ownership and maintenance responsibility. When examining a reference, ask which problem was addressed and how, rather than judging appearance alone.
The purpose of a cost guide is to make the purchased work understandable. A transparent comparison can reveal the right engagement without pretending there is one price suitable for every interface project.
BEFORE YOU DECIDE
Frequently asked questions
Is a Figma file enough as the final deliverable?
Its contents matter: organisation, components, states, interaction notes and the current version. The file extension alone does not establish a usable engineering handoff.
Are unlimited revisions better?
Not by themselves. Approval ownership, feedback rounds and scope changes should be clear. Undefined unlimited work can obscure timing and responsibility.
Why do identical screen counts receive different prices?
Complexity, user roles, states, research, device coverage and delivery support may differ. Establish equivalent scope before comparing the fee.
Can research be removed to reduce the budget?
Select a method according to existing evidence and project risk. Decisions without user research should be labelled assumptions rather than verified behaviour.
Does every project need a full design system?
Choose the level according to reuse and team needs. A small project may use basic components; a larger system needs creation and maintenance ownership.
Does the design price include software development?
Not automatically. Design, implementation, release and post-implementation review should be listed separately, even when one team provides them.
LET’S DEFINE THE SCOPE
Compare UI/UX proposals using a clear scope
Share the product summary, main user tasks and existing proposals. We can map research, design and handoff differences in one comparison.
Review my design scope