Questions to ask an UI UX design services vendor before you sign

Ask one question first: show me a screen you designed that is live today, and tell me what changed between the design file and production. Everything else follows from the answer. Then ask about research access, who builds the front end, accessibility conformance, design system ownership, change pricing, and what you keep if you leave.

This article groups the questions worth asking a UI UX design services vendor, says what a good answer sounds like against what a rehearsed one sounds like, and covers the commercial terms that matter more than the portfolio.

Why reviewing a portfolio is not due diligence

A portfolio shows what a studio can render. It does not show what survived engineering, what the accessibility auditor sent back, what the legal team made them change, or which of those beautiful screens was quietly replaced six weeks after launch. Design work is judged in production, and production is where portfolios stop.

The opening question is diagnostic precisely because it is uncomfortable. A studio that has shipped will answer it fluently: the table became a card list on small screens, the multi-step form collapsed to two steps after testing, the empty state was rewritten by legal. A studio that has only produced concepts will change the subject to process.

Everything below assumes you are buying a working interface, not a set of images. If you genuinely only want images, most of these questions do not apply, and you should pay accordingly.

Questions about evidence

Start with proof that the work reached users, and that the vendor knows what happened to it afterwards.

• Which of these screens is live now, and where can I use it? A live URL or a store listing beats a case-study PDF.
• What changed between the final design and what shipped? The answer reveals whether they were still involved at that point.
• What did you get wrong on that project, and how did you find out? Studios with a measurement habit answer immediately.
• Who from your team actually did the work, and are they available for mine? Pitch teams and delivery teams are frequently different people.
• Can I speak to the engineer who built from your designs? The most honest review of a design vendor comes from the developer who consumed the handover.

Questions about research and access to users

Design without contact with users is decoration with opinions. Ask how the vendor plans to get that contact, and who is responsible for arranging it.

The important detail is recruitment. Most design projects that skip research skip it because nobody arranged access to users, not because anyone decided research was unnecessary. Ask explicitly who recruits participants, who pays incentives, and what happens to the plan if your customers are unavailable for three weeks. A vendor who has a fallback, such as sessions with front-line staff who speak to those customers daily, has done this before.

Ask how many sessions they consider sufficient and why. Small, frequent rounds of testing beat one large study, and a vendor who proposes a single sixty-participant study at the end of the project is buying reassurance rather than information.

Questions about what is actually in scope

Most disputes on design projects come from a vague deliverable, not from bad design. Force precision before signature.

• Is the deliverable screens, a design system, a front end, or all three? Each is a different price and a different skill.
• How many states per screen? Ask for empty, loading, error, permission-denied and success states to be counted, not assumed.
• Which breakpoints and which platforms? A web design does not become a mobile application by resizing.
• Who writes the interface copy? If the answer is you, add a writer to your own plan now.
• How many revision rounds, and what counts as a round? Define whether a change of direction after approval is a revision or new work.
• What is the change-request rate? A published day rate turns a mid-project change into arithmetic rather than a negotiation.

Questions about accessibility and platform conventions

Ask for a conformance target in writing, usually WCAG 2.2 level AA, and ask who verifies it. A vendor who says accessibility is built into their process without naming a level or a verification method is describing an intention.

Platform conventions matter for anything shipping to an app store. Apple publishes the Human Interface Guidelines covering navigation, gestures, permission prompts and platform-native components, and Android publishes its own equivalents. A design that ignores both produces an application that reviewers question and users find slightly wrong without being able to say why. Ask how the vendor handles the two platforms differing, because a single shared design for both is a decision, not a default.

One more question is worth asking about both platforms and the web: what is your position on dense screens? Consumer patterns do not transfer to an operations console where a trained user needs forty rows visible and keyboard shortcuts. A vendor whose whole portfolio is spacious marketing-led interfaces may struggle with an internal tool, and it is better to find that out in the meeting.

What a good answer sounds like

Questions about handover, ownership and exit

Ask what you receive on the last day, in file formats and in rights. You should own the source design files, the component code, the documentation and the research recordings. Our standard is that clients own the code, prompts, infrastructure and documentation outright, and the reasoning behind that is set out in who owns the code and contract terms that matter.

Ask what happens if the relationship ends mid-programme, because this is the question that most often goes unasked and most often hurts. A fair answer is that anything delivered and paid for is yours, in usable form, with no licence conditions attached to your own product's interface.

Finally, ask who maintains the design after the engagement. If a design system is the deliverable it needs an owner, and if that owner is not on your payroll it should be on a support agreement. Our Care Plans start at $1,000 or ₹68,000 a month for ten hours of work, with Standard at $2,500 or ₹1,60,000 and Enterprise at $5,250 or ₹3,40,000 a month including a named engineer.

Questions about money

Ask for the price as a range with the drivers named, not as a single number. Our UI/UX design and development engagements run from $5,500 or ₹3,60,000 to $28,000 or ₹18,40,000, and the drivers are the number of surfaces, the number of states, whether a governed design system is included and whether we also build the front end. Every starting figure is on the pricing page.

Ask whether the engagement is fixed price or time and materials, and what triggers a change order in each. Both models work; the comparison in fixed price versus time and materials applies equally to design work. What does not work is a fixed price against an undefined deliverable, which converts every discovery into an argument.

When this list is the wrong tool

Do not run a fifteen-question interrogation for a two-week engagement worth five thousand dollars. The diligence should be proportionate to the commitment, and a small first project is itself the cheapest possible due diligence: you learn more from three weeks of working together than from any answer given in a pitch.

This list is also the wrong tool if you cannot yet describe the problem. A vendor cannot answer scope questions about a product you have not defined, and their vague answers will be a reflection of your vague brief rather than of their capability. Write the brief first; what to put in a UI UX design services RFP covers the structure.

A worked example of the questions paying off

On an in-app copilot for a field-service SaaS product, the questions that mattered were not about visual style. They were about which states the interface had to show while an answer was still being produced, how a user would know where an answer came from, and what happened when the system could not help. The in-app copilot case study describes the result, and the design detail behind those states is covered in designing copilot UX. A vendor who cannot discuss states in that much detail at pitch stage will discover them during your build.

Ask, finally, how they will tell you that you are wrong. Every useful design engagement includes at least one moment where the client request and the evidence disagree. A vendor who has never described such a moment has either never had one, which is unlikely, or gives clients what they ask for, which is worse.

Related reading

Five ways UI UX design projects fail covers the failure modes these questions are designed to detect, and the hidden costs of UI UX design services lists the lines that rarely appear in a quote. If you want straight answers to all of the above from us, start with a short conversation.

The vendor worth signing is the one whose answers get more specific the harder you push.