Skip to content
TWINJAM

SOW template · Design & UX

UI/UX Design Sprint Statement of Work Template

A sprint SOW that fixes the number of flows, screens and revision rounds, so a five-day or three-week design sprint ends with a decision rather than an open-ended redesign.

Fixed fee, 1 to 4 weeks5 deliverables · 6 exclusions
UI/UX Design Sprint SOW.docx Parsed
5
Deliverables
6
Exclusions
1 + 1 rounds
Revision rule

Design & UX · Exclusion rule

A design system, component library or production-ready UI specifications.

Ambiguity fix

Studio will design the new onboarding experience.

Studio will prototype up to 2 onboarding flows and up to 12 screens to answer the agreed sprint question.

Best for

Product design studios running discovery or validation sprints for product teams that need a tested prototype, not a full design system.

Design sprints are short by design, which makes every extra flow or extra test round a large share of the fee. The common failure is a sprint that turns into a full product redesign because nobody wrote down where the sprint ends. This template defines the problem statement, caps the prototype at named flows and screens, limits user tests, and states plainly that production-ready UI and a design system come later, under a separate SOW.

Copy any clause block below into your own SOW. Numbers, appendix names and tools are placeholders drawn from a typical engagement, so replace them with the counts from your proposal. Every clause is written to be read by a client, not used against one.

§ 2

Deliverables

Count everything. A deliverable a client cannot count is a deliverable a client can expand.

  1. 2.1A facilitated kickoff and mapping workshop (up to 4 hours, up to 6 client participants) producing an agreed sprint question and target user.
  2. 2.2Lightning demos and solution sketches consolidated into one storyboard covering up to 2 user flows.
  3. 2.3A clickable high-fidelity Figma prototype of up to 12 screens covering the storyboarded flows.
  4. 2.4Five moderated remote usability sessions (45 minutes each) with participants recruited to the agreed screener.
  5. 2.5A findings readout: session highlights, issue severity table and recommended next steps, delivered as a Figma page and a 45-minute presentation.
§ 3

Exclusions (out of scope)

Name what the engagement does not include. These are the lines your PMs will cite most often.

  1. 3.1A design system, component library or production-ready UI specifications.
  2. 3.2Screens or flows beyond the two storyboarded flows.
  3. 3.3Participant incentives and recruitment platform fees, which are passed through at cost.
  4. 3.4Brand identity, illustration, motion design and copywriting beyond interface microcopy.
  5. 3.5Development, technical feasibility studies and engineering estimates.
  6. 3.6Additional rounds of user testing after the findings readout.
§ 4

Revision limits

The storyboard includes one consolidated revision round before prototyping begins. The prototype includes one round of changes after internal review and before user testing. Changes after testing are captured as recommendations in the readout rather than applied to the prototype.

§ 5

Acceptance criteria

Acceptance needs a measurable test and a window. Without both, delivery never formally ends.

  1. 5.1The sprint question and target user are agreed in writing at the end of the kickoff workshop.
  2. 5.2The prototype covers every step of the approved storyboard and runs in Figma's presentation mode without broken links.
  3. 5.3Five sessions are completed, or rescheduled within the sprint window if a participant does not attend.
  4. 5.4Delivery of the readout completes the engagement.
§ 6

Client assumptions & dependencies

Tie each dependency to a date so a late input has a known effect on the schedule.

  1. 6.1A client decision maker attends the kickoff and storyboard sessions and can approve direction on the spot.
  2. 6.2The client shares existing research, analytics and brand assets before kickoff.
  3. 6.3Recruitment criteria are agreed within two business days of kickoff so sessions can be booked in time.
  4. 6.4Feedback is consolidated by one named client contact.
§ 7

Change control

Adding a flow, screens beyond 12, extra test sessions, a second sprint question or production UI work is a change. The studio will propose a change order within one business day stating the added work, hours, cost and effect on the sprint calendar. Because sprint calendars are tight, approved changes may extend the sprint by whole days.

These clauses are drafting guidance written from agency delivery practice. They are not legal advice. Agencies should have final MSAs and SOWs reviewed by counsel, especially for liability, IP, payment and termination terms, which this template does not cover.

Ambiguity check

The phrases that turn into free work, and what to write instead.

These are the vague lines we see most often in design & ux SOWs. Each one sounds reasonable at signature and becomes a dispute three months later.

Ambiguity check1 vague term flagged

Before

Studio will design the new onboarding experience.

Safer rewrite

Studio will prototype up to 2 onboarding flows and up to 12 screens to answer the agreed sprint question.

Why it matters: "The experience" is unbounded. Flows and screen counts are measurable.

How to adapt it

7 steps from template to signed SOW.

A template saves drafting time. The protection comes from replacing every placeholder with the real counts, names and dates from your engagement.

  1. 1

    Read the UI/UX Design Sprint SOW end to end and mark every number, appendix and named tool that does not match your engagement.

  2. 2

    Write the sprint question into the SOW before signature, even as a draft, so scope has a reference point.

  3. 3

    Set screen and flow caps from your last three sprints, not the ideal sprint.

  4. 4

    List recruitment costs as pass-through so incentive changes never touch your fee.

  5. 5

    Add a follow-on option for production UI so the next phase is already framed.

  6. 6

    Run the ambiguity check: search your draft for words like all, any, ongoing, as needed, unlimited and timely, and replace each one with a count, a list or a date.

  7. 7

    Have your counsel review the final MSA and SOW before signature, then load the signed SOW into TWINJAM so every request is checked against it.

Editable Word file

Get the UI/UX Design Sprint SOW as a DOCX.

Every clause on this page in one formatted document, with numbered sections, appendix placeholders for your counts and a one-page change order form to attach to the SOW.

  • 19 numbered clauses
  • Revision and change control language
  • Change order form with hours and rate fields

UI/UX Design Sprint SOW.docx

Editable Word file with appendix placeholders

One email with the file, then The Profitable Agency newsletter. Unsubscribe in one click.

Signed the SOW? Let TWINJAM hold the line.

TWINJAM turns these clauses into boundary rules, flags Slack and Jira requests that cross them, and drafts the change order with the clause already cited.