How Zebra Sprints Work

Assumptions, boundaries, and what to expect — so there are no surprises.

We've made assumptions and boundaries to create your quote and process. These come from 60+ client projects and five years of refining how design sprints work best. They protect both of us — you get certainty about what's being built, and I can focus entirely on delivering the best work.

If any of these assumptions change, the budget, schedule and project plan may need to be re-evaluated together.

What You Get

A Zebra Sprint delivers a working, deployment-ready front-end — not a Figma file or a PDF. You get production code (Next.js/React) shipped to your codebase that your engineering team can build on immediately.

Each sprint focuses on one critical user flow. This is deliberate. Focusing on the most important interfaces and features (but likely not all of them) speeds up development and produces the most impact for product-market fit.

After the sprint, we recommend going straight to development and implementing any recommended product changes, additional screens, or edge cases as you develop the technical stack. This is faster than designing everything upfront — technical challenges always reshape screen requirements.

What's Typically Included

Working front-end application with mocked data and responses — your team wires it to your backend later
Responsive design: desktop, tablet, mobile
User testing with real users (video recordings, AI transcripts, expert analysis)
Evidence-based iteration from testing results
Daily async video updates during the build
Results presentation with evidence and recommendations

We'll do our best to cover all of these, but we adjust priorities as your needs emerge during the sprint. For example, on the Research Tech project we prioritised very high-level product decisions and validation, we built mobile responsiveness as front-end, but we down prioritised front-end testing for their technical team. We'll keep you updated during the project and if there's a specific thing in this list that must be done, please tell us upfront!

What's Not Included

These are separate engagements if needed:

Brand or identity design
Backend development
Native mobile apps (unless specified)
Ongoing maintenance or support
Full redesign across multiple flows (each flow is a sprint)
Component library (unless specifically scoped)

If you need exact screens designed for flows outside the sprint scope, let me know before we start so we can include them or plan additional sprints.

Scope Freeze

After the workshop, scope is frozen. You know exactly what you're getting. I know exactly what I'm building.

This is the most important boundary in the process. It exists because every successful sprint we've run locked scope early, and every difficult one had scope shifting mid-build. The structure protects both of us from the most common cause of project failure: changing requirements during execution.

How it works:

Workshop — We define the flow together. Your team brings domain knowledge, I bring UX expertise. We align on exactly what gets built.
Scope locks — After the workshop, that's what I build. No additions, no "quick changes," no expanding the brief mid-week.
New ideas become the next sprint — Great ideas that come up during the build? They go into the next sprint, not this one.

Changes to scope after the workshop can be accommodated from €1,000 per change, depending on complexity. This isn't a revenue source — it's a signal that the change has real cost. Most clients never need this because the workshop does its job.

Visual Fidelity

The case studies in your proposal represent the visual fidelity and scope you can expect. We work to a high standard — think Linear, Notion, Raycast-tier interfaces.

If you have a specific visual direction in mind (based on another product, brand guidelines, or a reference you admire), share it before accepting the quote so I can factor it into the approach. Starting fresh without constraints produces the best results, but I can work within established design systems too.

During multi-sprint engagements, we may prioritise validating the core application over polish in early sprints, then dedicate a Visual Sprint to design system work once the UX is proven.

Communication

Async-first, no exceptions during the build.

One workshop kicks off each sprint. Then I disappear into the work. You get daily Loom video updates showing exactly what's been built, what's next, and any decisions needed.

No Slack pings, no "quick syncs," no status meetings
Questions get thoughtful written answers, not rushed verbal ones
48-hour response window on non-urgent items — nothing is urgent in UX

Why this matters: A "quick call" doesn't cost 15 minutes. It costs the 45 minutes before (anticipation breaks focus) and the 23 minutes after (recovery to deep work state). The best design work happens in uninterrupted 4–5 hour blocks. Protecting those blocks is how you get the quality you're paying for.

Schedule

Sprint weeks are protected time. Once a date is booked, that week is reserved exclusively for your project.

Workshops are scheduled in the afternoon (CET) — mornings are reserved for deep work
Build days are focused execution — concentrated design sessions — quality comes from focus, not hours
Schedule changes after booking may incur a fee for the reserved time — the earlier you flag changes, the easier they are to accommodate

The sprint typically follows a split-week model with an async gap (we'll let you know if it's a different process in your proposal):

Day 1: Workshop + scope lock
Days 2–4: Rapid build, daily async updates
Async gap: You send the test link to users when ready — this happens on your timeline
Day 5: Results analysis, UX iteration, final presentation

Day 1 Guarantee

If Workshop 1 reveals that the sprint can't realistically deliver what you need, you can cancel for a full refund at that point. No questions asked.

This has never been used. The pre-sprint conversations and proposal process ensure alignment before we start. But the guarantee exists because you should never feel locked into something that doesn't feel right.

Payment

Payment is by bank transfer in milestones tied to project phases, not calendar dates. Your specific payment schedule is in your proposal.

Typical structure for a multi-sprint engagement:

Milestone	When
Upfront	Before Workshop 1 — confirms the project
Mid-project	End of Sprint 2 (or mid-engagement equivalent)
Final	On delivery

The upfront payment confirms the project and reserves the sprint dates. No payment = no reservation.

Workshop Attendees

Workshops work best with the right people in the room:

The Decider (required) — the person with final authority on product decisions. Without them, decisions stall.
Domain Experts (recommended) — people who understand your users, market, or technical constraints. Their knowledge prevents assumptions.
3+ attendees recommended — workshops with 1–2 people lack the diverse perspectives needed for good decisions.

All workshop attendees should complete the onboarding flow before Day 1 so everyone understands what the sprint delivers, what it doesn't, and where the boundaries are. This prevents mid-sprint confusion about scope.

What Happens When Things Change

Things change. That's expected. Here's how the process handles it:

Situation	What happens
New idea during the build	Noted for the next sprint. Doesn't change this one.
Scope addition needed mid-sprint	Change order from €1,000 per change, depending on complexity.
User testing reveals the flow needs rethinking	That's the point — we iterate based on evidence in the UX Fixes day.
Schedule needs to move	Flag early. Changes may incur a fee for reserved time.
The whole direction needs to change	Workshop 1 is the checkpoint. After Day 1, we've aligned. New directions become new sprints.

The goal is simple: no surprises for either of us. You know what you're getting, what it costs, and when. I know what I'm building, the timeline, and the boundaries. Everything else is just good communication.

Questions?

If anything here is unclear or you want to discuss how these boundaries apply to your specific engagement, reach out:

charlie@zebradesign.io

These boundaries aren't restrictions — they're the reason Zebra Sprints consistently deliver. They come from five years of learning what makes client projects succeed.

Back to: The Zebra Sprint · Sprint Types · Project Setup