Skip to main content

scope creep for UX designers: where research turns into free rebuilds

UX scope creep hides inside words that sound like collaboration: 'let's explore that,' 'while you're in there,' 'can you spec the edge case too.' The damage is rarely one giant ask — it's discovery that won't close, flows added one screen at a time, and a handoff that quietly turns into unpaid QA. Your statement of work should fix the number of flows, the research method, and the handoff format, and your replies should point at those numbers instead of negotiating against your own calendar.

Patterns to watch for

  1. 01The discovery that never closes

    You scoped a two-week discovery phase: interviews, a synthesis readout, and a problem statement. Then the client wants 'just a couple more' user interviews, a competitive teardown you never agreed to, and a second readout for a different team. Discovery is the easiest phase to inflate because it has no obvious finish line. Define the deliverable that ends it — a signed-off problem statement — and bill anything past that date as new research.

  2. 02The flow that grows one screen at a time

    You agreed to design the onboarding flow. Then it's 'and the empty state,' 'and what happens if they skip,' 'and the returning-user variant,' 'and the error path.' Each screen feels like part of the same flow, so saying no feels petty. But a flow is a count, not a vibe. Scope onboarding as a specific number of screens and states; every screen past that count is a line item with its own estimate.

  3. 03The handoff that becomes QA

    Your contract ends at a Figma handoff with redlines and a token sheet. Instead, the developer pings you daily: 'what's the hover state,' 'the spacing looks off in staging,' 'can you check this build.' You've drifted from designer to embedded QA. Specify what the handoff includes — and that build review, design QA, or implementation sign-off is a separate, billable engagement with its own hours.

  4. 04The research used to justify a rebuild

    You ran usability testing as scoped. The findings are uncomfortable, so the client says 'great, now redesign the three flows that tested badly.' Research that surfaces problems does not include fixing them — that's a new design phase. Separate the research deliverable (findings and recommendations) from any redesign work in the contract, so an inconvenient result doesn't silently obligate you to a second project for free.

  5. 05The late persona pivot

    Mid-project, a stakeholder announces the real priority user is someone you never scoped for — enterprise admins, not the consumers you designed around. Now your information architecture, your flows, and your test plan are all aimed at the wrong person. This is a brief change, not a refinement. Your contract should name the target users and treat a new primary persona as a trigger for re-scoping the whole engagement.

Red flags

  • The brief describes 'the product' without naming a primary user or a fixed count of flows and screens.
  • Discovery has no defined end deliverable — interviews keep getting added with no sign-off milestone.
  • Developers contact you directly for build fixes after a handoff you considered final.
  • Usability findings are immediately reframed as a mandate to redesign, with no new statement of work.
  • A stakeholder introduces a new 'real' user segment late in the project.
  • Requests to 'just spec the edge cases' arrive after the happy-path flows were approved.
  • The client treats your Figma file as a living backlog they can keep adding tickets to.

How to respond

UX work invites scope creep because it looks open-ended from the outside — a file you can keep opening, a problem you can keep exploring. Beat that by anchoring every conversation to a countable thing: flows, screens, research sessions, handoff artifacts. When a new screen or interview appears, don't debate whether it's 'big.' Say which number it exceeds and offer a change order with a fresh estimate. The most reliable framing is refinement versus new surface area: refining an approved flow is inside scope, adding a screen or a persona is not. Designers who hold this line read as rigorous, not rigid — clients trust a UX partner who can say exactly where the work ends.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

How do I scope a discovery phase so it actually ends?+

Tie the phase to a deliverable and a date, not to a feeling of completeness. Write it as: 'Discovery includes up to eight user interviews, one synthesis workshop, and a problem-statement document, delivered by [date]; sign-off on the problem statement closes the phase.' That gives you a hard stop. If the client wants more interviews or a second readout after sign-off, it's additional research priced separately. Without a named end deliverable, discovery expands until someone runs out of patience — usually you.

A developer keeps asking me to fix things in the build. Is that in scope?+

Only if you scoped implementation support. A handoff deliverable — redlines, specs, a token sheet — is a document, not a standing service. If the developer needs you reviewing builds, answering daily questions, or QAing staging, that's design QA, and it should be its own engagement with a block of hours. Reply: 'Build review wasn't part of the handoff scope. I can set up a design-QA block of [hours] to cover implementation questions.' Otherwise you become unpaid embedded staff.

Usability testing showed problems and the client wants me to redesign those flows. Free?+

No. Research and redesign are two phases, and you only sold one. The testing deliverable is findings and prioritized recommendations — naming what's broken and what to do. Acting on those findings is a design phase with its own hours. Separate them explicitly in the contract so an uncomfortable result doesn't quietly become a mandate for a second project. You can absolutely propose the redesign as the logical next step — just price it as new work, not as a warranty fix.

How do I count screens so 'one more screen' doesn't keep happening?+

Scope flows as an explicit inventory of screens and states, listed in an appendix: happy path, empty states, error states, edge cases, and variants you'll cover. Then 'can you also do the skip path' has a clear answer — it's either on the list or it's a new line item. The trap is scoping by flow name ('the onboarding flow') instead of by count, because a flow can always sprout another screen. Count the screens and states up front.

The client changed who the primary user is halfway through. What now?+

Stop and re-scope before you design anything for the new persona. A new primary user invalidates your information architecture, your flows, and your test plan — it's a brief change, not a tweak. Send: 'We scoped around [original persona]; designing for [new persona] is a different problem that affects IA, flows, and testing. I'd like to re-baseline the project as a change order.' Doing the new-persona work inside the old budget means absorbing a second project's worth of effort.

Should I include a design system in a product-design engagement by default?+

No — name it explicitly or leave it out. Clients often assume a 'reusable system' comes free with screen design, but components, tokens, documentation, and governance are a distinct deliverable with real ongoing cost. Decide up front whether you're delivering screens or a system, and price accordingly. If they ask for a system after you've delivered screens, that's a new engagement. Spell out in the contract whether handoff includes reusable components or just composed layouts.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide