Team Onboarding Flow

Onboarding for workshop attendees — understanding scope and boundaries before Day 1.

Team Onboarding Flow

Priority: Must Have

Build a simplified onboarding flow in sprint.zebradesign.io for workshop attendees who aren't the primary decision-maker. The current onboarding flow is designed for the founder/buyer — team members need a lighter version that sets expectations without proposal review or payment.

Why This Matters

The problem (Research Tech, January 2026):

Daniel (team member) attended Workshop 1 without full context of scope boundaries and the value being delivered. This led to:

  • Extra user research sessions being requested mid-sprint
  • Additional questions that were hard to push back on
  • Scope creep from someone who didn't know where the boundaries were

The fix is structural: the process says no, not you. The workshop structure creates boundaries that protect both parties — but only when everyone in the room understands those boundaries before they arrive.

"Onboard all team members through the project/onboarding flow before Workshop 1. Anyone attending a workshop needs to understand: what the sprint delivers, what it doesn't, and where the boundaries are." — Retrospective, locked decision

What Exists Today

The Research Tech onboarding flow at sprint.zebradesign.io/onboarding/research-tech-1 has 6 pages:

  1. Proposal review — Scope, quote, deliverables
  2. Engagement summary — Sprint details, assumptions
  3. Terms acceptance — Checkbox confirmations
  4. About — Client information collection
  5. Confirmation — Next steps
  6. Invoice — Payment details

This works for the decision-maker (founder/buyer). Team members don't need proposal review, terms acceptance, or payment pages. They need to understand the sprint boundaries and come prepared.

What to Build

Team Member Onboarding Flow

A 3-4 page flow, separate from the founder onboarding. Each attendee receives their own link.

Page 1: What This Sprint Is

  • What a Zebra Design Sprint delivers (one flow, one week, validated in code)
  • What it does NOT deliver (full redesign, multiple flows, backend, ongoing support)
  • The timeline and async model
  • How workshops work (2.5 hours, decisions happen here)

Page 2: Your Role in the Workshop

  • Why you're invited (domain expertise / decision authority / technical context)
  • What to prepare (review prep questions, bring knowledge about users and constraints)
  • What to expect (exercises, voting, scope lock)
  • The boundary: scope was agreed with the founder — workshop is about depth within the agreed flow, not adding breadth

Page 3: Prep Questions

  • Same questions from the prep kit (see 01-pre-sprint-prep.md):
    • What is the one user flow that matters most?
    • Who are your target users?
    • What has been tried before?
    • Any technical constraints locked in?
  • Text input fields so responses are captured, not just reviewed
  • These feed into workshop preparation

Page 4: Confirmation

  • "I understand what this sprint delivers and what it doesn't"
  • Checkbox confirmation
  • Name, role, email (for calendar invites)
  • Optional: links to reference materials they think are relevant

Tracking

  • Admin view showing list of attendees and completion status
  • If someone hasn't completed 48 hours before workshop, flag to the primary contact
  • The primary contact (founder) can see who has and hasn't completed

Client-Specific Adaptation

When building for a specific client:

  • Page 1 content adapts to the agreed scope (which flow, which product)
  • Page 2 roles adapt to who the founder has identified as attending
  • Prep questions may add client-specific questions based on the pre-sprint call
  • Number of attendees varies — the founder provides the list during pre-sprint prep

How It Connects

  • Referenced in methodology: 01-pre-sprint-prep.md step 6
  • Locked decision in: learnings-zebra-design-sprints.md
  • Evidence in: retrospective.md → "Only the Founder Had Project Context"
  • Current app: sprint.zebradesign.io (sprint-client-app)
  • Architecture: 4-products-built-building/sprint-client-app/architecture-decision.md

This is the single most important build item for the next engagement. Without it, the scope creep problem from Research Tech will repeat.