Hiring a UI/UX Designer: What to Include in Your Design Contract

Hiring UI/UX design talent is one of the highest-leverage decisions a product manager or startup founder can make. Great design can clarify product strategy, improve activation and retention, and reduce engineering rework. But even experienced teams get burned when expectations live in Slack messages, Figma comments, and “we’ll figure it out” calls—rather than a clear contract.

This guide is written from the client/buyer perspective and walks through what to include in a design contract when you hire a UI/UX designer—so you get the deliverables you need, on a realistic timeline, with ownership and collaboration rules that prevent painful surprises.

Along the way, you’ll see how to structure a ui designer agreement, what clauses matter most for startups, and how to adapt a design contract template to your specific project. (And yes—these are the exact kinds of terms people search for when they type “hire ui ux designer contract” into Google.)

---

Why a UI/UX design contract matters (even if you “move fast”)

Startups often prefer lightweight processes. But design work is inherently iterative and subjective. A solid contract doesn’t slow you down—it:

• Sets scope boundaries so “just one more screen” doesn’t turn into 40 unpaid hours and resentment.
• Defines deliverables so you can plan engineering work confidently.
• Aligns on review cycles and feedback responsibilities, preventing endless revisions.
• Clarifies IP ownership so you can ship, fundraise, and scale without legal uncertainty.
• Establishes payment triggers tied to progress, reducing risk for both parties.

Think of the contract as part of your product infrastructure: it makes collaboration repeatable.

---

1) Parties, project overview, and definitions

Every agreement should start with the basics:

• Legal names and addresses of client and designer (or agency)
• Effective date and term
• High-level project description
• Clear definitions for terms you’ll use later (e.g., “Deliverables,” “Final Files,” “Revisions,” “Acceptance”)

Why it matters: Ambiguous language fuels disputes. For example, “final design” could mean mockups, a clickable prototype, dev-ready specs, a design system, or all of the above.

Client tip: Add a short “Project Goals” section (e.g., redesign onboarding to increase activation, improve usability for X persona). While not legally binding like deliverables, it provides context when tradeoffs arise.

---

2) Scope of work: be specific about what you’re buying

The scope of work (SOW) is the heart of your hire ui ux designer contract. It should clearly state:

Deliverables (examples you can adapt)

• Discovery artifacts: stakeholder interview summary, competitive audit, UX audit
• User research plan and scripts (if applicable)
• Information architecture: sitemap, user flows
• Wireframes (lo-fi) and/or high-fidelity UI designs
• Interactive prototype (Figma) for key flows
• Design system components (buttons, inputs, typography, color tokens)
• Handoff package: specs, redlines, annotations, asset export, dev notes
• Usability testing plan + results summary (if included)
• Accessibility review checklist (e.g., WCAG 2.1 AA targets)

What’s explicitly out of scope

Spell out what you are not buying. Common exclusions:

• Front-end development or production build
• Branding/logo design (unless included)
• Copywriting (or define who provides copy)
• Illustration/animation work
• User recruitment costs or incentives
• Ongoing design support after handoff

Client tip: If you don’t define exclusions, you’ll often end up impliedly asking for them through feedback, and the designer may reasonably assume they’re included.

---

3) Process and milestones: avoid “deliverables-only” contracts

UI/UX design is not just output—it’s a process. Your ui designer agreement should include how work will happen, not just what will be produced.

Common phases

1. Discovery (requirements, constraints, alignment)
2. Concepting (flows/wireframes, approach options)
3. Visual design (UI direction, components)
4. Prototyping & validation (test/iterate)
5. Handoff (specs, assets, walkthrough)

Milestones tied to approval points

Define milestones such as:

• Milestone 1: Wireframes for onboarding flow (client approval required)
• Milestone 2: High-fidelity designs for core screens
• Milestone 3: Prototype + handoff + final walkthrough

Why it matters: Milestones create natural checkpoints. They also make it easier to link payment schedules and acceptance criteria to real progress.

---

4) Timeline, dependencies, and your responsibilities as the client

Design timelines fail more often due to client delays than designer performance. Your contract should include:

• Project start date
• Estimated schedule per milestone
• Review windows (e.g., “Client will respond within 2 business days”)
• Key dependencies (e.g., “Client provides brand guidelines, product requirements, and access to analytics by X date”)

Include a “pause” or “delay” clause

If the client goes silent, the designer should be able to:

• Shift the schedule
• Reprioritize other work
• Potentially charge a restart fee for re-onboarding

Client tip: This isn’t “designer-friendly fluff.” It protects you too, by making it clear that missed deadlines may be caused by missing inputs—not vague “design took longer.”

---

5) Revisions and feedback: prevent endless iteration loops

One of the most important answers to what to include in design contract is revision structure. Define:

• Number of revision rounds included per deliverable (e.g., 2 rounds)
• What constitutes a “revision” vs. a “change in scope”
• How feedback should be delivered (single consolidated doc, Figma comments by date)
• Who has approval authority (one decision maker, not five)

Sample revision language (conceptual)

• “Two rounds of revisions are included per milestone, provided feedback is consolidated and delivered within X business days.”

Client tip: Require consolidated feedback. “CEO comments in Slack + PM comments in Figma + engineer feedback in a meeting” is a recipe for rework and missed deadlines.

---

6) Acceptance criteria: define when work is “done”

Design can be subjective, but acceptance criteria can still be objective. Your contract should state:

• What constitutes delivery (e.g., Figma file link + exported assets + written notes)
• How you will review and accept deliverables (e.g., 5 business days)
• What happens if you don’t respond within the review window (deemed accepted, or auto-accept with exceptions)
• Criteria for “material nonconformity” (e.g., missing screens listed in scope)

Client tip: Avoid vague standards like “high quality” alone. Pair quality with tangible requirements: screen list, breakpoints, component usage, accessibility constraints, prototype coverage.

---

7) Tools, file formats, and handoff expectations

If you’ve ever hired a designer and ended up with assets you can’t use, this clause is for you.

Specify:

• Primary tool (often Figma)
• Ownership/access details (e.g., files delivered in your team workspace vs. designer’s)
• File formats for assets (SVG, PNG @1x/@2x, Lottie, etc.)
• Annotation/spec expectations (Figma Dev Mode, component naming conventions)
• Design tokens or CSS variables mapping (if applicable)

Include dev handoff support (if needed)

Many teams benefit from a limited “handoff support” window:

• “Up to X hours of developer Q&A within 14 days after final delivery.”

Client tip: If your team has junior engineers, budget for extra handoff time. It’s cheaper than mis-implemented UI and rework.

---

8) Intellectual property (IP) ownership and licensing

Startups need clean IP ownership—especially for fundraising, acquisition due diligence, or enterprise customers.

Your contract should address:

• Who owns the final deliverables upon payment (typically the client)
• Whether the designer retains ownership of pre-existing materials (e.g., templates, methods, generic components)
• Whether open-source assets or third-party libraries are used, and under what licenses
• Rights to modify and create derivative works

Portfolio rights

Designers often want to show work in portfolios. Decide what’s acceptable:

• May display final designs after product launch
• Must remove confidential data
• Requires written approval for stealth products
• Embargo period (e.g., 6 months)

Client tip: If you’re pre-launch or in a regulated industry, include a strict confidentiality + portfolio limitation clause.

---

9) Confidentiality, data security, and access controls

Designers may need access to:

• Product roadmap
• User insights
• Analytics
• Internal tools
• Staging environments

Include:

• A confidentiality obligation (and define “Confidential Information” broadly)
• Permitted use (only for performing services)
• Security measures (reasonable safeguards, no sharing credentials)
• Return/destruction of confidential materials upon termination

Client tip: If user data is involved, consider whether you need a Data Processing Addendum (DPA) or at least language prohibiting downloading or storing personal data.

---

10) Compensation structure: hourly vs fixed fee, deposits, and change orders

Your pricing model should match the uncertainty level of the project.

Fixed-fee projects (best when scope is stable)

• Total fee
• Payment schedule tied to milestones (e.g., 40/40/20)
• Clear change order process for additional scope

Hourly or retainer (best when scope evolves)

• Hourly rate
• Weekly or monthly cap
• Time tracking/reporting method
• Pre-approval requirement for overages

Expenses

State whether expenses are reimbursable (user testing incentives, stock photos, fonts) and whether they require pre-approval.

Client tip: Even with fixed-fee projects, include a lightweight change request mechanism: written description + estimate + timeline impact + approval.

---

11) Communication cadence and governance

Design work lives or dies by collaboration. Include:

• Primary point of contact on both sides
• Meeting cadence (e.g., weekly 30-min check-in)
• Communication channels (Slack, email, Notion, Jira)
• Response time expectations
• Decision-making process (single accountable owner)

Client tip: Make it explicit that feedback must be consolidated by the PM/product owner. This protects the designer from conflicting stakeholder input and protects you from “design by committee.”

---

12) Warranties, disclaimers, and limitation of liability (don’t skip)

Many founders ignore these clauses until something goes wrong.

Common points:

• Designer warrants work is original and doesn’t knowingly infringe IP
• Disclaimer that outcomes (conversion uplift, revenue) aren’t guaranteed
• Limitation of liability (often capped at fees paid)
• Exclusion of consequential damages

Client tip: If you’re an early-stage company, overly aggressive liability terms may scare off top talent. Aim for reasonable protection on both sides.

---

13) Termination, kill fees, and transition assistance

Projects change. Funding changes. Priorities change. Your contract should anticipate this.

Include:

• Termination for convenience with notice (e.g., 7–14 days)
• Termination for cause (material breach, non-performance)
• Payment obligations for work completed to date
• Kill fee (optional) to compensate for scheduled capacity
• Transfer of work-in-progress upon payment
• Short transition support (handoff of files, notes)

Client tip: Define what happens to partially completed designs and whether you can use them. This is especially important if you terminate mid-sprint.

---

14) Non-solicitation and non-compete: keep it reasonable

Some clients add broad restrictions that make designers walk away.

• Non-solicitation (reasonable): you won’t poach the designer’s team members.
• Non-compete (often problematic): avoid restricting the designer from working with other companies unless narrowly tailored (industry + time + geography).

Client tip: If you truly need exclusivity (rare), expect to pay for it.

---

15) Governing law, dispute resolution, and contract mechanics

Wrap up with standard legal mechanics:

• Governing law and venue
• Dispute resolution (mediation/arbitration optional)
• Independent contractor status
• Assignment (can either party transfer the contract?)
• Entire agreement + amendment requirements
• Signatures (including e-sign)

Client tip: If you use contractors internationally, confirm how cross-border disputes are handled and whether local tax forms are needed.

---

A practical checklist: what to include in a design contract (client view)

Use this as a quick reference when reviewing a design contract template:

1. Scope & deliverables (screen list, flows, prototypes, handoff items)
2. Milestones & timeline (with client dependencies)
3. Revision rounds + definition of scope change
4. Acceptance criteria + review windows
5. Tools and file ownership/access (your Figma org if possible)
6. IP ownership + portfolio rights
7. Confidentiality & security (and data restrictions if applicable)
8. Fees & payment schedule + expenses + late fees (if any)
9. Communication & governance (one approver, consolidated feedback)
10. Termination & transition (work-in-progress rights, kill fee)
11. Liability and warranties (balanced protections)
12. Legal boilerplate (governing law, contractor status)

---

Common mistakes startups make when hiring UI/UX designers (and how your contract fixes them)

Mistake #1: Buying “screens” instead of outcomes

Fix: Add goals, constraints, and definitions of success (even if informal), plus a process section.

Mistake #2: No clarity on handoff

Fix: Specify deliverables for dev-ready handoff, formats, and a handoff meeting.

Mistake #3: Unlimited revisions

Fix: Define revision rounds and a change order process.

Mistake #4: Not securing IP properly

Fix: “Work made for hire” or assignment language upon full payment, plus clear portfolio rules.

Mistake #5: No one owns feedback

Fix: Put one person in charge of approval and require consolidated feedback.

---

Other questions you might ask next

• What’s the difference between a UI designer, UX designer, and product designer—and should the contract change?
• Should you use a fixed fee or hourly rate when hiring a designer for an MVP?
• How do you define “done” for UX deliverables like user flows and wireframes?
• What accessibility requirements (WCAG) should be included in a UI/UX contract?
• How do you structure a design retainer agreement for ongoing product work?
• What clauses should you add when hiring a UI/UX designer internationally?
• How can you protect confidential roadmap information while still allowing portfolio use?
• What does a good design handoff checklist look like for engineering teams?

---

Final thoughts

A strong ui designer agreement isn’t about legal posturing—it’s a practical tool for shipping better product experiences with fewer surprises. If you want a faster way to generate a tailored design contract template with the key terms above (scope, revisions, IP, confidentiality, and handoff), you can create one using Contractable, an AI-powered contract generator, at https://www.contractable.ai.