How to Choose a SaaS Product Design Partner

Choose a SaaS product design partner by comparing how well each candidate understands your product problem, demonstrates relevant work and defines the work your team will receive. Use the same brief for every proposal, then evaluate scope, team involvement, feedback, handoff and ownership before comparing the price.

A portfolio can help you assess visual quality. It cannot tell you, on its own, whether a team can untangle your permissions model, work with your engineers or design the states that sit between the polished screens.

This guide is for founders and product leaders choosing an external studio, agency or independent designer. Here, “design partner” means a provider of product design services, rather than an early customer helping validate a new SaaS product.

Define the product problem before reviewing portfolios

Start with one workflow and the people who need to complete it. “We need a better dashboard” leaves candidates to interpret both the problem and the scope. A more useful starting point names the task, the observed difficulty and the constraints around changing it.

For example:

Our workspace administrators need to invite teammates and assign access. Support conversations suggest that the difference between roles is unclear. We want to review this workflow using our existing component library. Our engineering team will implement the changes.

This is an illustrative brief, not a Gestures client example. It separates an observation from a conclusion: unclear roles may be a design problem, but the team still needs to examine the workflow before deciding what to change.

If you need a structured starting point, use our SaaS UX audit checklist to review the workflow before expanding the scope.

Write down five things before you approach candidates:

1. User and task: Who needs to do what?
2. Available evidence: What have you observed through support, research, analytics or direct use?
3. Decision required: Do you need diagnosis, a new workflow, visual refinement or a broader redesign?
4. Constraints: What must stay, including components, platform behavior, release dependencies and engineering capacity?
5. Expected output: What should your team be able to review, test or build when the engagement ends?

If the cause of the problem remains uncertain, ask candidates to separate investigation from solution design. A bounded diagnostic phase may be more appropriate than committing immediately to a full redesign. Ask what that phase would establish, what it would deliver and how its findings would affect the next scope.

Evaluate relevant work and the actual project team

Look for similarity in the product’s demands. A different industry may still involve the same design challenges: permissions, long tables, recurring workflows, configuration or information that changes with user roles.

Ask a candidate to walk through one relevant project. Focus on the starting problem, their specific contribution, the constraints and the decisions behind the final interface.

Useful questions include:

• What was difficult for users before this work started?
• Which parts of the project did your team actually own?
• What changed between the first direction and the final design?
• How did the design account for loading, empty, error and permission states?
• What evidence supported the decision, and what remained an assumption?
• Which parts were implemented, and what can you show publicly?

A finished screen shows an outcome of design work. A walkthrough helps you understand the reasoning behind it. Treat a polished presentation and evidence of usability as different things. If a candidate reports a business improvement, ask what was measured, over what period and what else changed.

Confidentiality may limit what a studio can share. An anonymized walkthrough or a permitted sample can still help. Ask for enough evidence to assess the work without requesting another client’s private files.

Confirm who will do the work

Clarify the people involved after the proposal stage. Who leads product decisions? Who designs the interface? Who reviews the work? Who communicates with your engineers?

Also ask about availability and continuity. A named senior designer may be advising at a few checkpoints rather than working on the project each day. Either arrangement can be workable when it matches your needs and is described clearly.

If the work is attributed to an individual’s previous role, establish what that person contributed and whether they will participate in your project. Do not assume every portfolio item represents the current studio’s full delivery team.

Compare scope, feedback, handoff and ownership

Give shortlisted candidates the same brief and ask each to identify assumptions, inclusions and exclusions. Without that shared basis, two proposals may describe different projects under the same label.

Scope the workflow beyond its main screens

A screen count does not fully define a product workflow. An invitation flow might include role selection, a pending invitation, an expired link, a duplicate address, missing permissions and a failed request.

Ask how the proposal accounts for these states, responsive behavior and existing components. If research or usability testing is mentioned, clarify its method, participants, recruitment responsibilities and outputs. Internal critique and testing with intended users answer different questions.

Agree how feedback becomes a decision

Specify who provides feedback, who consolidates it and who makes the final decision. Ask how reviews are scheduled and what happens when feedback changes the original scope.

“Revisions included” needs a working definition. It might mean refinement within an agreed direction, a fixed number of review rounds or something else. Similarly, a target delivery date should be considered alongside the inputs and approvals your team must provide.

Define what engineering receives

Ask to see a permitted handoff example. Depending on your project, useful outputs may include editable design files, component usage, interaction notes, responsive rules, state coverage and a prototype of the agreed workflow.

Clarify whether the proposal includes design reviews during implementation, how questions are handled and when support ends. A design file and production code are separate deliverables. If development is required, it needs an explicit scope.

Put file access and usage rights in writing

Confirm when your team receives source files, where the files will live and what usage or ownership terms apply. Ask about third-party fonts, icons and other licensed assets that your product may need.

Use the proposal to identify these questions, then have the appropriate person on your team review the contractual terms. Do not infer rights or access arrangements from a general promise that a project is “yours.”

Compare two proposals against the same brief

Consider the administrator invitation workflow above. The table below shows two fictional proposals. Neither represents Gestures’ pricing, terms or a real client engagement.

Proposal A could fit a tightly defined visual task when your internal team already owns workflow design, specifications and implementation support. Proposal B could fit a team that needs those decisions addressed within the engagement.

Before comparing their totals, ask both candidates to quote against the same required scope. Otherwise, a lower fee may simply cover less work, while a broader proposal may include work you do not need.

Use a partner selection scorecard

Use a scorecard to make your reasoning visible to colleagues. The following weights are a practical comparison aid, not a predictor of project success. Adjust them before reviewing proposals so they reflect your project.

Score each criterion from 1 to 5:

• 1: Little relevant evidence or major unanswered questions.
• 3: Suitable evidence, with manageable gaps that are clearly recorded.
• 5: Strong evidence closely matched to the project and its constraints.

Calculate the weighted result as sum(weight × score ÷ 5), using the percentage weights as whole numbers. The maximum is 100. For example, scores of 4, 4, 3, 5, 4 and 3 produce 78 out of 100. Record a short evidence note beside every score.

Keep unresolved information marked “not assessed” rather than treating missing evidence as an average score. Do not finalize a total until those gaps have been addressed.

Set non-negotiables before scoring

Some requirements should remain separate from the total. These might include access to editable files, compatibility with your engineering team, acceptable confidentiality terms or availability for a necessary release window.

A high overall score should not override an unmet requirement. Treat budget as a feasibility check alongside the scorecard: can the proposal deliver the required scope within the amount you can commit? The low weight for commercial clarity does not mean price is unimportant.

Ask these questions before making the final choice

Use the final conversation to close specific gaps:

1. What would you need to understand before recommending a design direction?
2. Who will work on this project, and how will their involvement change across it?
3. Which workflows and states are included in this proposal?
4. What do you need from our team, and when?
5. What will our engineers receive, and which implementation questions are covered?
6. What would trigger a scope change or additional fee?
7. When do we receive files, and which rights or licenses need separate attention?
8. What remains uncertain in your estimate?

Record the answers in the agreed scope. If a candidate cannot estimate responsibly without further investigation, ask for a bounded first phase with explicit outputs and a decision point before continuing.

When an external design partner may not be the next step

An external engagement needs someone inside your company who can provide context and make decisions. If nobody owns the product direction, establish that responsibility before expecting a design team to resolve it through interface work.

Likewise, a full redesign may be premature when the user problem is unclear, and additional design output may not help when engineering cannot take it forward. A focused review, a smaller workflow or a different engagement model may fit the immediate constraint better.

Choosing a studio and choosing how to staff design over time are related decisions. This guide addresses the first. For an ongoing need, compare a design subscription, an agency and an in-house hire to see how much product context, availability and internal ownership your team requires.

Frequently asked questions

Does a SaaS design partner need experience in our exact industry?

Usually not. Exact industry experience helps most when the workflow has unfamiliar constraints. For most products, transferable experience matters more: look for work with similar users, information density, permissions and product complexity. Ask how the candidate would learn the parts of your domain they do not yet understand.

Should we choose a fixed project or an ongoing engagement?

Choose a fixed project for a bounded workflow with agreed deliverables. Choose an ongoing engagement for a changing backlog your team can prioritize every week. Compare responsibilities, capacity, exclusions and commercial terms before choosing either arrangement.

Should we request a free design exercise?

No. Start with relevant work, a structured walkthrough and the same brief for all candidates. If an additional exercise is necessary, agree a bounded, paid scope and how its output may be used. Avoid making speculative product work the default condition for being considered.

Can a design partner guarantee better activation or retention?

No. A partner can improve the design and show how it will measure the effect. Ask how the team would investigate the problem, test a proposed change and track the result. Design work contributes to a wider product system that also includes implementation, reliability, pricing and customer expectations. Treat a promised business outcome separately from the evidence supporting it.

Discuss your product design priorities

If you are defining a new workflow or reviewing an existing product, explore Gestures’ SaaS product design services. Our product design work spans interfaces, dashboards, workflows and design systems.

Bring the task you want to improve, the evidence you have and the constraints your team is working within. We can discuss the work you have in mind and whether Gestures is the right fit.