|
Non-Negotiable
|
What to Ask
|
Red Flag
|
|
Documented design process
|
"Walk me through what you produce in the first two weeks, day by day."
|
"We'll start with discovery and see what happens"
|
|
Direct access to the working team
|
"Who, by name, works on my project after this call?"
|
Deflection to "our team" with no names
|
|
Design system & component discipline
|
"Do you use design tokens? What's your file architecture on a real project?"
|
"Every project is different", no system
|
|
Proven handoff practices
|
"Show me a real handoff file from a completed project."
|
"We hand over the Figma file and they take it from there"
|
|
Transparent pricing tied to scope
|
"Where's the scope boundary, and what triggers a change order?"
|
Pricing that requires trust, not documentation
|
|
References that speak to problems solved
|
"Connect me with a client whose project hit a complication, and one who left."
|
Every departure was "just a budget decision"
|
|
Clear IP & offboarding terms
|
"Who owns the files, tokens, and docs? What's the offboarding process?"
|
Answers that lean on trust, not contract language
|
Process & Fit
Can they show you exactly what happens before you sign?
A product design agency's process is the mechanism by which your brief becomes a shippable product. If that mechanism is vague, if the agency can't hand you a document describing exactly what happens in week one, what deliverables emerge at each phase, and what your role as decision-maker looks like at each checkpoint, then what you're buying is a black box.
Don't settle for verbal reassurance here: ask for the actual artifacts: a sample discovery deliverable, a wireframe from a previous engagement, a component handoff file.
Agencies with a real process produce these as a matter of course; the ones without tend to show Dribbble shots instead, which look polished but tell you nothing about how they perform under actual project conditions.
Without a clearly defined process, every new request can turn into a discussion about whether it is included in the original scope. That is how scope creep starts.
If an agency cannot explain what will happen from the first week through delivery, unexpected costs and change orders are likely to appear later, when the project is already underway and changing partners would be difficult and expensive.
What to ask: "Walk me through what you produce in the first two weeks, day by day."
|
✅ What you want to hear
|
🚩 What should worry you
|
|
Specific deliverables, dates, and decision points, a real onboarding process.
|
"We'll start with a discovery session and see what happens." An agency that hasn't thought past the sale.
|
Constraint to watch: Documented process doesn't mean an inflexible, "hard-coded" framework. An agency that can't adapt when user research produces unexpected findings is just as problematic as one with no process at all.
Who's really doing the work?
This is the industry's most common structural failure, and it has a name: the senior pitch, junior execution swap.
The creative director and head of strategy pitch the engagement, juniors execute it, and the client ends up signing based on a portfolio built by people they'll never work with.
The account-manager layer compounds the problem. Most agency communication models route client input through account managers, whose job is project coordination rather than creative thinking, so a client's nuanced brief gets distilled by the account manager and reinterpreted again by the designer.
This criterion fits early in the hiring workflow, since it requires a direct conversation before any contract is signed.
Ask to meet the specific people who'll be touching your files once the sales call ends, ask for their individual portfolios, and ask what percentage of their time will go to your project and who backs them up if something urgent comes up.
What to ask: "Who, by name, works on my project after this call?"
|
✅ What you want to hear
|
🚩 What should worry you
|
|
Specific names, individual portfolio links, and clarity on seniority.
|
Hesitation, deflection to "our team," or an assurance that "our senior team will be involved" without specifics.
|
Constraint to watch: Agencies with a dedicated point of contact in the delivery team – someone with strategic oversight rather than a pure account manager – can make direct-ish access work. What breaks down is any model where the person answering your questions can't make design decisions or speak to the technical rationale behind them.
Technical Fluency
Will their design system survive contact with your codebase?
Mature agencies treat every design decision as a named variable shared between the design file and the codebase: a color, a spacing value, a type size.
When those variables are defined once and connected to the engineering environment, a change made in the design file can flow into the codebase without a developer manually hunting down every instance.
That is the practical difference between a design system built for engineering handoff and one built for a portfolio screenshot. Ask whether the agency uses design tokens, and whether those tokens are structured to match your engineering team's naming conventions.
This check exists to avoid the "we can't build this" silence: the gorgeous, unbuildable design that comes from an agency optimizing for visual output without considering the engineering stack.
What to ask: "Show me your component and design system approach. Do you use design tokens? What does your file architecture look like on a real project?"
|
✅ What you want to hear
|
🚩 What should worry you
|
|
Reusable components, a documented token hierarchy, evidence of dev-facing structure.
|
"Every project is different," with no system behind it.
|
Constraint to watch: Design system depth scales with project complexity and budget. For a focused MVP engagement, a lightweight component library is appropriate. The risk is an agency that can't describe any systematic approach at all.
Is handoff a real process?
Design-to-development handoff is where an agency's work either turns into a buildable product or creates more work for the engineering team.
Simply sending a Figma link is not a complete handoff. Developers also need the details required to reproduce the intended experience, including:
- component states such as loading, empty, error, hover, and disabled;
- edge cases such as unusual data lengths, user permissions, and mobile breakpoints;
- interaction specifications such as transitions, animations, and focus order;
- accessibility guidance such as reading order and page structure.
New Figma features are making this collaboration easier. Code layers allow developers to bring working code into the design canvas and synchronize design and code states, while Figma Motion can export animations to formats such as CSS, JSON, and React.
However, these tools do not replace a proper handoff process. Dev Mode and code synchronization provide a useful foundation, but engineers still need documented states, annotated prototypes, clear edge cases, and access to the design team during development.
The strongest agencies stay involved after the files are delivered. They answer implementation questions, review the built product, and resolve gaps before they lead to inconsistent behavior or costly rework.
What to ask: "Walk me through what developer handoffs include. Can you show me a real handoff file from a completed project?"
|
✅ What you want to hear
|
🚩 What should worry you
|
|
Documented components, every state and edge case covered, a direct developer communication channel.
|
"We hand over the Figma file and they take it from there."
|
Constraint to watch: Handoff quality is stack-dependent. Ask whether the agency has worked with your engineering team's specific stack before and whether their component naming conventions will create friction with an existing codebase.
A beautiful handoff built on different naming conventions than your system still generates rework.
Accountability & Risk: Will They Be Honest When It Gets Hard?
Can they show you exactly where scope ends and cost begins?
You should understand what you are paying for, what is included, and what will increase the cost.
A price without a clear list of deliverables creates room for disputes later. The agency may consider a request outside scope even when your team believed it was part of the original engagement.
Each pricing model carries a different type of risk.
A fixed-scope model offers more cost certainty, but changes to the brief may lead to additional fees. Time-and-materials offers flexibility, but the total cost can grow if reporting and priorities are not tightly managed.
A retainer can work well for continuous product development, but it becomes difficult to evaluate when monthly outputs are unclear.
The model itself is less important than the level of transparency around it.
Before signing, the contract should define:
- the expected deliverables,
- the number of revision rounds,
- the responsibilities of both teams,
- what is excluded,
- and what triggers a change order.
This prevents a low initial quote from turning into a much more expensive project once normal changes begin.
What to ask: "Walk me through your pricing model and show me where the scope boundary is. What triggers a change order, and what is your change-order process?"
|
✅ What you want to hear
|
🚩 What should worry you
|
|
An explicit deliverables list, a defined number of revision rounds, a clear written process for scope changes.
|
A pricing narrative that requires trust rather than documentation.
|
Constraint to watch: The hybrid model: time-and-materials for discovery, fixed-scope for design and build, is often the most honest structure for complex engagements where requirements can't be fully defined before discovery.
An agency that insists on fixed-scope before any discovery has happened is either optimistically scoping or protecting their margin.
Will they connect you with a client who had a bad month?
Most agencies will introduce you to their happiest clients. Those conversations may confirm that the agency can deliver good work, but they reveal little about how it behaves when delivery becomes difficult.
The most useful references are clients whose projects experienced a real problem: a delayed timeline, a scope disagreement, a technical obstacle, or a change in direction.
These conversations help you understand whether the agency communicated early, took responsibility, proposed solutions, and protected the client from unnecessary cost.
Ask for recent clients rather than only a curated list. You can also request a conversation with a client who ended the relationship. How an agency manages an offboarding process can be just as important as how it handles a successful project.
What to ask: "Can you connect us with a client whose project faced a significant complication, and with a client who ended the engagement?"
|
✅ What you want to hear
|
🚩 What should worry you
|
|
A confident agency makes the connection, no hesitation.
|
An agency explains why every departure was "just a budget decision."
|
Constraint to watch: It's easy to hear what you want to hear on these calls. You tend to dig deeper when the first answer sounds good, and let a bad answer slide. Write your questions down before you dial, and ask them the same way every time.
What happens to your files if you walk away mid-project?
The contract should clearly state who owns the work and what the agency must provide when the engagement ends.
Design files, user research, prototypes, component libraries, documentation, and design tokens all have operational value. If ownership is unclear, you may discover that your team cannot freely edit or reuse work it has already paid for.
The contract should clearly cover three areas:
- Ownership of project work It should state which deliverables become yours after payment, including editable source files.
- Use of the agency's existing assets If the agency uses its own templates, frameworks, or component libraries, the contract should explain what you are allowed to use and whether that right continues after the engagement ends.
- Offboarding It should define what happens to unfinished work, when files and documentation will be transferred, and how access to tools, accounts, and systems will be handed back or removed.
Without those terms, changing agencies can become even more expensive. Your team may already be dealing with delays and onboarding a replacement provider, only to discover that key files are inaccessible or cannot legally be modified.
What to ask: "Who owns the Figma files, design tokens, research documentation, and component libraries produced during this engagement? What is your offboarding process if we terminate mid-project? What pre-existing assets will you use that we would not own outright?"
|
✅ What you want to hear
|
🚩 What should worry you
|
|
Specific answers backed by contract language on ownership, offboarding timelines, and license terms.
|
Any answer that asks you to rely on trust rather than the contract.
|
Constraint to watch: IP assignment clauses need to be specific about format and access. "Ownership" that comes in the form of flat PNG exports rather than editable source files isn't functionally useful. Make sure the contract specifies delivery of source files in their original format, along with all associated documentation.
How to Make the Partnership Work After Signing
A strong agency cannot compensate for unresolved problems inside the client's organization. Several conditions need to be in place before the project begins.
Align Internal Stakeholders
Product, engineering, and leadership should agree on the project's priorities, success measures, and decision-making authority.
When stakeholders disagree after the work begins, the agency may receive conflicting feedback or be asked to solve internal disputes. This creates revisions, delays approvals, and increases the cost of work that was completed against an earlier brief.
Before the agency starts, define who can approve decisions and how disagreements will be resolved.
Define Data and Compliance Requirements
Tell the agency in advance what systems and data it will access.
If the team will work with analytics tools, production environments, personal data, or sensitive user research, the contract should define the relevant security and compliance requirements. Required agreements, access controls, and data-processing responsibilities should be resolved before access is granted.
Leaving these questions until after kickoff can delay the project or create unnecessary legal and security risk.
Confirm That the Team Can Scale
The agency may be able to staff the original scope but struggle if the project grows.
Ask how quickly it can add people, what level of seniority those people will have, and whether the original leads will remain involved. Otherwise, an expansion in scope may result in delays or a sudden drop in quality.
Prepare Your Internal Team for External Collaboration
Internal teams need to know how and when they are expected to participate.
The agency will require access to stakeholders, product context, technical information, and timely decisions. If key people are unavailable or become involved only during final reviews, the team may reject work based on requirements that were never shared.
Define the review process, decision owners, and expected response times before kickoff.
Make Sure the Budget Matches the Scope
A good hiring process cannot solve a structurally insufficient budget.
When the available budget cannot support the requested research, design quality, team seniority, and delivery timeline, something will eventually be reduced. The agency may assign junior staff, shorten discovery, limit revisions, reduce the scope, or add fees later.
A transparent agency will raise this problem before signing. A less reliable one may accept the project and manage the shortfall after the client has become dependent on the engagement.
Key Takeaways
- Procurement criteria should weigh process transparency over portfolio polish
- Pricing ambiguity is itself a risk signal; an agency that can't define scope boundaries in writing has structured the engagement to resolve ambiguities at its own discretion.
- Direct access to the working team is a structural requirement for quality output; the account-manager-as-translator model doesn't work for nuanced product work.
- IP and offboarding terms should be resolved before signature; the cost of a mid-project switch is already high enough without adding a contract dispute on top of it.
- Reference checks only produce useful signals when they include at least one client who experienced a project complication and one who ended the engagement; a curated reference list only proves the agency has satisfied customers.
The Engagement You Are Signing
Choosing a product design agency means choosing a temporary extension of your product team. The agency will take part in product decisions, work with user research, collaborate with engineers, and produce the designs your team will build.
That makes the relationship closer to hiring a senior team member than buying a one-off creative service.
Over time, the agency also builds valuable context. It learns how your users behave, how your product works, who makes decisions internally, and why earlier choices were made. This knowledge helps the team work faster and make better decisions on future projects.
That is also why switching agencies can be so expensive. The biggest cost is often not onboarding a new team, but losing the knowledge the previous agency accumulated. Files and documentation can be transferred, but much of the product context has to be rebuilt.
The seven criteria in this checklist cannot guarantee a successful engagement. They can, however, help you identify the most common risks before signing, when they are still easier and cheaper to address.
FAQ
How long should it take to vet a product design agency?
Usually three to four weeks, enough time to compare agencies, speak with references, and review the contract properly. Anything shorter than two weeks tends to skip the checks most likely to catch problems.
What are the main red flags during the first call?
Watch for an agency that skips questions about your users and goals, pitches solutions before understanding the problem, agrees to everything without pushback, can't name who'll do the work, or quotes a price before discussing scope. A good agency asks detailed questions and explains trade-offs.
Should you choose fixed-scope or time-and-materials pricing?
Fixed-scope works best when requirements are clear and unlikely to change; time-and-materials suits discovery and ongoing work where scope may evolve. For complex projects, a hybrid model works best: time-and-materials for discovery, then fixed-scope once requirements are clear.
How should you check references?
Ask every reference the same questions, including at least one whose project faced delays or technical problems, and lead with "Would you hire them again, and why?" Then compare their account against the agency's own case study.
What happens to design files and IP if you switch agencies?
It depends on the contract: without clear terms, you may get finished exports but not editable files, documentation, or full ownership. Before signing, confirm who owns the work, which source files you'll receive, and how access transfers if you leave.
