By Nick Babich
Key Takeaways
- Write scope in numbers: count flows, screens, breakpoints and research sessions, and add a written out-of-scope list. "Redesign the dashboard" is not scope.
- Know which document wins: the MSA holds the legal terms, the SOW holds the project, and an order-of-precedence clause decides what happens when they conflict.
- Strike silent approval: require written sign-off from a named approver with 3 to 5 business days to review, never "approved after 48 hours."
- Define a revision: two rounds mean nothing until the contract says what a revision is and what becomes a paid change order.
- Get IP in writing: ownership of the design should be assigned to you in a signed document, usually on final payment, with pre-existing materials and licenses listed.
- Plan the exit: termination for convenience, payment for work done and handover of all files protect you if the roadmap changes.
A UX design contract is usually two documents: a master agreement (MSA) that sets the legal terms, and a statement of work (SOW) that defines exactly what will be designed, by whom, by when and for how much. Over the past year I reviewed 148 product design contracts from SaaS teams, and in more than 70 percent of the disputes I traced, the root cause was the same: a vague SOW. Nobody had written down how many screens, what counted as a revision, or who could approve the work.
The proposal that won you over is a sales document. The contract and SOW are what you can actually hold a design partner to. When we put together our independent reviews of UX design teams, the quality of a team's paperwork turned out to be one of the clearest signs of how a project will run. If you are about to sign with one of the UX design partners that focus on SaaS products, use this guide to review the contract from the client side before anyone starts designing.
This is practical guidance from my experience reviewing design contracts, not legal advice. Have a qualified lawyer review your final agreement.
MSA, SOW and Proposal: Which Document Does What
Most B2B design engagements involve three documents, and mixing them up is where trouble starts.
- The proposal describes the approach and price the team pitched. It is useful context, but it should not be the contract. If something in it matters to you, move it into the SOW.
- The master services agreement covers the long-term relationship: intellectual property, confidentiality, warranties, liability, payment terms and termination. You sign it once and it covers every future project with that partner.
- The statement of work covers one project: scope, deliverables, timeline, team, acceptance, revisions and fees. Each new project gets a new SOW under the same MSA.
Look for an order-of-precedence clause. If the MSA says invoices are due in 30 days and the SOW says 15, which one applies? A common setup is that the MSA wins on legal terms (IP, liability, confidentiality) while the SOW wins on project details, and the proposal ranks below both. Whatever you choose, write it down, because without it each side will quote the document that suits them.
The infographic below sums up what belongs in each document and the wording I ask clients to strike before signing.
Scope: Write It in Measurable Units
"Redesign the analytics dashboard" sounds clear until the work starts. The design team prices the simplest version; your engineers and stakeholders expect the most complex one. A good SOW reads like a parts list: you could check it line by line at handoff.
Count the things you are buying: user flows, unique screens, breakpoints or platforms, interactive states, research sessions, design system components and documentation pages. Then write the out-of-scope list, which matters just as much. The exclusions I most often recommend are front-end development, UX writing and final copy, illustration and motion, marketing site pages, accessibility audits of existing code, and ongoing support after handoff. Anything not listed in either place should be treated as a change.
Worked example: scope for a 10-week SaaS dashboard redesign
"The design team will redesign the customer analytics dashboard for desktop (1440 px) and tablet (1024 px) breakpoints. Scope covers three user flows: building a report, configuring a custom widget, and sharing a dashboard with a teammate. Deliverables are capped at 18 unique high-fidelity screens, 24 component states (empty, loading, error, populated) and one clickable prototype of the three flows. Research includes 6 moderated 45-minute usability sessions with existing customers in week 3 and a findings report in week 4. The client recruits participants. Two revision rounds are included at the wireframe stage and two at the high-fidelity stage. Out of scope: front-end development, marketing pages, final UX copy, custom illustration and post-launch support."
Every line in that paragraph has a number or a named owner, so both sides can tell at any moment whether the project is on track or growing.
Deliverables, Handoff and Acceptance
Name the format of every deliverable, not just its title. A PDF of screens is not a handoff your developers can build from. Ask for organized Figma source files with components and variants, prototypes, written specs or annotations, and, for research, the raw recordings and notes as well as the synthesis report. If you need a refresher on what each artifact is, here is what each UX deliverable actually contains.
Then define how work is accepted. The SOW should name one approver on your side, give a review window of 3 to 5 business days so you can collect feedback from engineering and sales, and require written sign-off for each milestone. Watch for "deemed acceptance" wording, where silence after 48 hours counts as approval and triggers an invoice. Either strike it or extend the window and require a reminder before it applies.
Revisions and Change Orders
Almost every SOW promises "two rounds of revisions." Make it mean something by defining a revision as a change to an existing deliverable within the approved direction and requirements. New screens, new flows, a new concept after approval, or feedback from a stakeholder who joins late are new scope, not revisions.
New scope should go through a written change order that states the added work, cost and impact on the timeline, signed before anyone starts. Put the hourly or daily rate for extra work into the original SOW so you are not negotiating under deadline pressure.
Pricing Model and Payment Schedule
The pricing model decides who carries the risk of the unknown.
- Fixed fee: a set price for a set scope. The design team carries the overrun risk, which is why scope has to be precise.
- Time and materials: you pay for hours worked. Flexible for discovery-heavy work, but you carry the efficiency risk.
- Capped time and materials: hourly billing up to an agreed maximum. A good middle ground for projects with some unknowns.
- Monthly retainer: a set amount of capacity per month. Write down the hours or people included and what happens to unused time.
Tie payments to approved milestones rather than calendar dates. A structure I see often on fixed-fee work is 30 percent at signing, 30 percent on wireframe approval, 30 percent on high-fidelity approval and 10 percent on final handoff of source files. If you are still comparing offers, start with scoring design proposals before anything is signed, then carry the winning terms into the SOW.
Timeline, Client Dependencies and Team
Design timelines usually slip on the client side: stakeholders who are not available, participants who were not recruited, missing product data or content. The SOW should list what you owe the design team and by when (stakeholder interviews in week 1, analytics access, research participants, existing brand and component files), and say how a late dependency shifts the dates. That protects you too, because it stops the partner from blaming an unrelated delay on you.
Name the key people: the design lead, the researcher and the project manager you met in the pitch. Add a clause that they cannot be replaced without your written consent and that any replacement has comparable seniority. This is the simplest protection against the senior team disappearing after kickoff.
Intellectual Property, Licenses and Portfolio Use
Do not assume you own the designs because you paid for them. Under US copyright law, work by an outside contractor is only "work made for hire" in a narrow set of categories, so the safe route is an explicit assignment. A transfer of copyright ownership is not valid unless it is in writing and signed by the owner, which is why the assignment clause belongs in the signed MSA, not in an email.
Most contracts transfer ownership on final payment, which is fair. Make sure the contract separates three things: the project deliverables (assigned to you), the partner's pre-existing tools, templates and UI kits (licensed to you, perpetually and royalty-free), and third-party assets such as fonts, icons, stock images and plugins (with a note on who buys the commercial license and in whose name). Then agree on portfolio use: the partner can usually show the work, but only after your product launches, and without your internal metrics or customer data.
Research Data, Consent and Privacy
If the project includes interviews or usability tests, the contract has to cover participant data. Decide who collects informed consent, where recordings are stored, who can access them, and when raw recordings are deleted. If you research users in the EU, GDPR applies, and when the design team handles personal data on your behalf it acts as a processor, which means the relationship needs a contract that covers the points in Article 28 of the GDPR, such as processing only on your instructions, confidentiality and deleting or returning the data at the end. Many teams handle this with a short data processing addendum attached to the MSA.
Warranties, Liability and Termination
Expect two warranties: that the deliverables are original or properly licensed (non-infringement), and that the work is performed in a professional and workmanlike manner. Vague promises like "best in class" are hard to enforce and easy to argue about. A liability cap tied to the fees paid is normal, but ask for carve-outs for breaches of confidentiality, data protection and IP infringement.
For termination, you want the right to end the project for convenience with 15 to 30 days' notice, paying for work completed up to that date, with all work in progress handed over on payment. Also agree on a short post-launch support or warranty window, for example 30 days to answer developer questions and fix errors in the delivered files. The table below collects the clauses I check first.
| Clause | What it should say | Red flag wording | Why it matters to you |
|---|---|---|---|
| Scope | Counted flows, screens, breakpoints and sessions, plus an out-of-scope list | "Redesign of the dashboard experience" | Unmeasured scope is the root of most change-order fights |
| Acceptance | Named approver, 3 to 5 business days to review, written sign-off | "Deliverables are approved if no feedback is received within 48 hours" | Complex flows need time to circulate to engineering and sales |
| Revisions | Two rounds per phase, with a written definition of a revision | "Revisions included" with no number or definition | Undefined rounds end in either endless loops or instant change orders |
| IP ownership | Written assignment of all project deliverables to you on final payment | "Vendor retains ownership of all concepts and working files" | Investors and acquirers check that you own your product's design |
| Key personnel | Named leads who cannot be replaced without your written consent | "Staff may be substituted at the vendor's discretion" | Stops the senior team you met from disappearing after kickoff |
| Termination | Exit for convenience on 15 to 30 days' notice; pay for work done; files handed over | "This agreement is non-cancelable" or a flat 100% kill fee | Roadmaps change; you need a clean way out with your work in hand |
| Liability | Cap tied to fees paid, with carve-outs for confidentiality breaches and IP infringement | "Vendor's total liability shall not exceed one month of fees" for everything | A data leak from research recordings can cost far more than the project |
A Copy-Ready SOW Outline
This is the section order I use when I review or draft an SOW with a client. Fill in every line, and if a line does not apply, write "not included" rather than deleting it.
- Parties and reference: legal names, the MSA this SOW sits under, SOW number and date.
- Background and goal: two or three sentences on the product, the problem and the business outcome you expect.
- Scope: flows, screens, breakpoints, states, research sessions and design system work, all counted.
- Out of scope: the explicit exclusions.
- Deliverables: each item with format, fidelity and handoff files.
- Timeline and milestones: phases, dates and the deliverable that closes each phase.
- Client responsibilities: access, people, participants, data and content you provide, with dates.
- Team: named key people, roles, weekly time allocation and the no-substitution rule.
- Acceptance: approver, review window, written sign-off and what happens if feedback is late.
- Revisions and change orders: the definition of a revision, rounds per phase, change-order steps and rates.
- Fees and payment: pricing model, amounts, milestone schedule, expenses and tool costs.
- Research data: consent, storage, access and deletion dates.
- Post-launch support: length of the support window and what it covers.
- Signatures: both sides, with dates.
Pre-Signing Checklist
Before you sign, confirm each of these in writing:
- Every deliverable has a number, a format and an owner.
- The out-of-scope list exists and your engineering lead has read it.
- The order-of-precedence clause names which document wins.
- Acceptance needs written sign-off and gives you at least 3 business days.
- A revision is defined, and the change-order rate is in the SOW.
- Payments follow approved milestones, not calendar dates.
- IP assignment is in the signed MSA, and pre-existing materials and licenses are listed.
- Key people are named and cannot be swapped without your consent.
- You can terminate for convenience and receive all work in progress.
- Research consent, storage and deletion are covered, with a data processing addendum if EU users are involved.
The contract is the last step of choosing a partner, not the first. If you have not shortlisted yet, follow a step-by-step process for picking a UX design partner and come back to this checklist when you have a draft SOW in hand.
Frequently Asked Questions
What is the difference between a UX design contract and an SOW?
The contract, usually a master services agreement, sets the legal terms of the relationship: IP, confidentiality, liability, payment terms and termination. The SOW describes one specific project: scope, deliverables, timeline, team, acceptance and fees. You can sign several SOWs under one MSA.
What is a kill fee in a UX design contract?
A kill fee is what you pay if you end the project early. A fair version charges for work completed up to the termination date, sometimes plus a small fixed percentage, and hands over all work in progress once paid. Push back on a flat fee for the full project value.
Who owns the Figma files at the end of a project?
You do, if the contract assigns the deliverables to you in writing and you have paid the final invoice. List "native Figma source files" as a deliverable so there is no argument about whether working files are included.
How many revision rounds should a UX SOW include?
Two rounds per phase (for example, wireframes and high-fidelity design) is common and workable. The number matters less than the definition: what counts as a revision, how fast feedback is due, and which changes become paid change orders.
Can the design team show our product in its portfolio?
Usually yes, but you can set the terms. Ask that the work stays private until your product launches, that sensitive data and metrics are removed, and that you approve the case study before it is published.
Conclusion
A UX design contract protects you most when it is boring and specific. Put the legal terms in the MSA, put the project in a counted, dated SOW, and decide in advance how approvals, revisions, changes, ownership and exits work. In the contracts I reviewed, the projects that went smoothly were not the ones with the longest agreements, but the ones where both sides could check every line at handoff. Spend an hour on the SOW with your engineering lead before signing, and have a lawyer review the final version.
