One of the largest professional sports leagues in the US, running a multi-year digital transformation with the lead agency. Phase 3 carried a specific risk: the agency designed, but the client's engineers built. Any ambiguity in component specifications would surface as rework on a high-visibility engagement spanning 32 club properties. The open question: could the design system's logic, its entitlement states, seasonal variations, and breakpoint behavior, cross an organizational boundary without information loss?
The challenge
Phase 3 inherited complexity from two directions.
Client side. The client's PM and engineering teams owned Jira, CMS, and QA. The agency designed and specified; the client built. Requirements had to be precise enough for another organization's engineers to implement without clarification.
Agency side. A new design team with zero prior system experience was onboarded. They needed to understand a legacy component library, complex entitlement logic (logged-out vs. subscriber vs. premium), seasonal variations (pre, regular, post, off-season), and day-parting windows (morning, afternoon, primetime), all before sprint one.
Ambiguity anywhere in those requirements would resurface later as rework, on an engagement everyone was watching.
The solution
A requirements-first approach that locked every component's states, variations, and decisions before design began. The centerpiece was a two-hour in-person requirements workshop.
My role
Product Manager embedded within the agency team, partnered directly with the client's web PM and main stakeholder. The job sat in the connective layer between design output and development execution, with no ownership of the client's Jira, CMS, or QA.
Strategy and approach
The first two weeks absorbed all of the ambiguity, on purpose.
- Current-state UX audit across the client's web, mobile app, premium product, and competitive platforms (other major leagues, streaming services, sports media), surfacing structural gaps, navigation inconsistencies, and off-site link leakage.
- Legacy component matching. Every existing component categorized as kill, reskin, or redesign against the updated design system.
- Requirements workshop. Two hours in person produced a complete component list per page, confirmed states and variations, and clear decisions for each legacy element.
- Component specification. 9 detailed specs in Figma across four breakpoints (mobile, tablet, small desktop, large desktop) with element descriptions, required/optional flags, responsiveness notes, and accessibility considerations.
Planning
Delivery ran on a weekly staggered cadence, most complex components first, to maximise development lead time. Every Friday a completed component package went out, and that rhythm kept the multi-year engagement on track across both organizations.
Sprint 0 had two priorities, navigation and the link list, the foundations that unblocked everything after them.
Cross-functional alignment
- Twice-weekly design reviews with the client's web PM and stakeholder, maintaining a 48-hour feedback turnaround.
- 48-hour lock rule. Requirements locked before design started, no late-stage scope additions.
- Accessibility co-authoring. Component-level requirements written with the accessibility lead.
- New team onboarding. Brought a design team with no prior system experience up to speed through component matching and workshop outputs.
- Coordinated delivery across agency designers, developers, QA, and the client's Product, Engineering, and Analytics teams.
Stakeholder trust
One outcome measured trust: the client's internal PM could write development acceptance criteria directly from the Figma documentation, with no extra clarification cycles. The specs made the full trip, agency to client to client's engineering, intact.
The twice-weekly design reviews and 48-hour feedback SLA created a predictable rhythm. Both sides knew exactly when decisions would be made and when deliverables would arrive.
Before and after
| Dimension | Before (typical agency handoff) | After (requirements-first) |
|---|---|---|
| Edge case discovery | During development | Before design started |
| Entitlement coverage | Partial (logged-out vs. subscriber) | Full (3 user types, 4 seasons, 3 day-parting windows) |
| Design rework | Frequent mid-sprint | Eliminated through upfront lock |
| Acceptance criteria | Required clarification cycles | Client PM wrote criteria directly from Figma |
| New team ramp-up | Weeks of context gathering | Compressed into workshop and component matching |
| Legacy decisions | Unclear, debated per component | Kill / reskin / redesign confirmed for every element |
Tooling and reporting
- Requirements. Figma (component specs, 4 breakpoints), workshop documentation.
- Tracking. Client's Jira (agency didn't own), agency-side sprint cadence.
- Communication. Twice-weekly design reviews, 48-hour feedback SLA.
- Research. Competitive audit across six platforms.
- Accessibility. Co-authored requirements with the accessibility lead.
Results
- 9 component specifications covering 3 entitlement states, 4 seasonal variations, 3 day-parting windows.
- Kill / reskin / redesign decided for every legacy component across 4 page types.
- Zero clarification cycles between agency specs and client engineering.
- Consistent Friday delivery maintained throughout the phase.
- New design team productive within first sprint despite no prior system experience.
Entitlement logic
The subscription hub required component states that changed based on three dimensions simultaneously.
- User type: logged-out, standard subscriber, premium subscriber.
- Season: pre, regular, post, off-season.
- Time of day: morning, afternoon, primetime.
A single component could have 30+ possible states (3 by 4 by 3). Documenting this in Figma across four breakpoints meant each component spec was essentially a decision tree. Getting it right before design began, rather than discovering edge cases during development, was the entire value of the requirements-first approach.
Why this worked
Most agencies design first and discover complexity during development. This engagement inverted that. Entitlement logic (3 user types, 4 seasons, 3 day-parting windows) means a single component could have 30+ possible states. Discovering those edge cases mid-sprint would have cost weeks per component. Discovering them in a two-hour workshop cost one afternoon.
The governance model, 48-hour lock rule, weekly Friday delivery, staggered complexity, created predictability for both organizations. The client's PM wrote acceptance criteria straight from the Figma documentation, and not one spec came back with questions.
On a design system engagement, the PM earns their keep on requirement precision, the kind that survives a handoff to another company's engineers.