You might receive one proposal for thirty screens and another for eighteen screens at a higher price. The count cannot settle the comparison. The first supplier may count every small dialog separately, while the second includes research, usability testing, error states and a development handoff. Compare the work that moves your project from an idea to understandable, buildable behavior, then consider the price.
This guide turns a UI/UX proposal into a set of deliverables you can review. Not every project needs every deliverable, but you should understand what has been excluded, what that means and who will complete the missing work. A small project needs a smaller, clear scope rather than a large document nobody uses.
Start with the task the user needs to complete
Before requesting screens, describe the people using the product and their goals. Consider a fictional maintenance portal. A customer submits and tracks a request, an employee classifies and assigns it, and a supervisor reviews overdue cases. These are three tasks with different data and permissions, even when their lists look similar.
Ask the design company to connect each flow to those tasks. “Does the quote include a dashboard?” is less precise than “How does the supervisor open an overdue request, understand the delay and see who can change it?” The answer reveals screens, interactions and states that a gallery of images cannot show.
What should you compare in the proposal?
The Nielsen Norman Group glossary distinguishes static deliverables, such as visual mockups, from prototypes used to explore interaction. For purchasing purposes, do not assume a polished image or presentation link proves an entire experience. Request a description of what you can review or test at each stage.
| Proposal item | Evidence to request |
|---|---|
| User and problem understanding | Research questions, intended audience, findings and the decisions those findings informed. |
| Task flows | Steps, roles and decision points, including returning, editing and cancelling. |
| Visual design | Screens with realistic content, plus loading, empty, error and success states. |
| Interactive prototype | Named journeys you can try, with simulated or nonfunctional parts clearly identified. |
| Development handoff | Editable files, components, states, behavior notes and the assets used. |
Do not use this table to impose every item on every supplier. Changing a single form inside an established system may call for limited research and a review of that flow. A new application serving several user groups needs broader understanding before its interface is fixed.
A screen count needs an agreed counting rule
Agree on what counts as a screen and how variants are handled. Is the mobile version another screen? Is a confirmation dialog counted? What about a user who sees an approval button and another who does not? A screen and flow register is more useful than a number disconnected from actual use.
Separate content changes from functional changes. Renaming a field differs from introducing a new approval that needs a screen, a permission and a notification. Ask how proposed changes will be assessed before work begins. Clarify whether included review rounds cover corrections to the agreed design or changes to the scope itself.
Discuss missing states before they reach development
Return to the fictional maintenance portal. What does a customer see before submitting the first request? How do they know an attachment failed to upload? Does entered information survive a lost connection? What happens when an employee opens a request they cannot access? These states affect everyday work; they are not decoration.
Request one complete sample journey before applying the pattern across the product. Keep missing items in a review log with the problem, decision and owner. This is easier to follow than scattered messages that become difficult to reconstruct later.
Arabic and English are early design decisions
If the product serves Arabic and English users, review both languages in the main flows. Customer names, request numbers and email addresses may share a line while running in different directions. Text lengths also vary. A short Arabic sample cannot demonstrate that real content will fit.
W3C guidance explains that text direction needs structural handling in HTML. As a buyer, ask the designer and developer to explain their responsibilities for RTL and mixed content. Test realistic Arabic and English names and numbers using fictional data. Mirroring element positions is only part of the review.
Usability testing has a scope of its own
The Nielsen Norman Group introduction describes usability testing through participants attempting tasks while a researcher observes. If testing is included in a quote, ask who will participate, why they represent the intended audience, which tasks they will attempt and what you will receive afterwards.
A company owner watching a prototype is not automatically equivalent to testing it with the intended users. Equally, a small study cannot prove success for everyone. Useful findings identify observed difficulties, proposed changes and areas not tested. The proposal should state whether another round of testing is included.
Before accepting the handoff
- Try the central task from beginning to end and ask about every unclear transition.
- Review missing states and the agreed screen sizes and languages.
- Open the editable files and check access to components and assets.
- Clarify font, image and icon licenses, including anything requiring a separate purchase.
- Hold a joint development review to record behavior, data and prototype limitations.
Your decision becomes clearer when you can point to a deliverable and explain what it demonstrates. Use this checklist when discussing UI/UX design services, and consult the software company selection guide for the wider working relationship. You do not need the proposal with the most terminology. You need an understandable agreement your team can review and use.
Sources and preparation
The UX deliverables glossary supports the distinction between deliverable types, the usability testing introduction supports observing task performance, and W3C text-direction guidance supports the direction discussion. Sources were checked on 3 November 2026. The table and maintenance example are an original proposed working framework, not a client story or certification standard. This text was prepared with AI assistance and review of its content and sources.
