The Anatomy of a Component Sprint | Figma Blog (opens in new tab)

The Washington Post’s design system team developed a roughly 10-day “component sprint” to replace siloed, linear workflows with continuous designer–developer collaboration. Each component is jointly planned, designed, implemented, refined, and documented, with input from the wider team throughout. The process aims to reduce miscommunication, uncover technical constraints early, and create components that serve real product needs.

Why the Component Sprint Was Needed

• The Washington Post launched its design system in 2019 to help teams deliver news experiences quickly and consistently.
• Earlier components followed either:
  • A design-led process for inputs such as selects, radios, and checkboxes.
  • A developer-led process for technically complex components such as carousels and search inputs.
• Both approaches caused delays, unexpected compromises, and gaps in communication.
• Designers sometimes overlooked existing components or pursued custom solutions, creating overrides and last-minute requests for new variants.
• Developers could be forced to focus on visual details instead of solving technical and product problems.
• The new process brings the relevant people together early and gives designers and developers shared ownership.

Sprint Structure and Shared Ownership

• A designer and developer from the core design system team lead each component from beginning to end.
• Every planned component receives its own sprint, although the timeline can vary.
• The approximately 10-day process is intentionally open and inclusive rather than closed and sequential.
• The wider team contributes feedback and expertise at multiple stages.

Kickoff: Balancing Impact and Effort

• The team holds a weekly 30-minute meeting to evaluate candidate component tickets in Jira.
• Ideas are prioritized according to potential impact and required effort.
• Jira tickets serve as shared, evolving spaces where stakeholders can:
  • Leave feedback asynchronously.
  • Record insights from Slack discussions.
  • Group related ideas.
  • Connect proposals to business goals.
• An impact-versus-effort matrix visualizes priorities:
  • Larger circles represent ideas with more votes.
  • Numbers identify clusters of related ideas.
  • Colors indicate associated business goals.
• Once a ticket is prioritized, a designer and developer are assigned to lead delivery.

Concept: Defining Scope and Goals

• The sprint begins with a two-hour meeting involving the wider team.
• In a FigJam file, participants:
  • Define the component’s goals.
  • Agree on requirements.
  • Assess the scope of work.
  • Clarify assumptions and technical needs.
• The meeting reserves the final 15 minutes for review.
• Using FigJam enables both technical and non-technical contributors to participate.
• The team focuses first on shared expectations and requirements, avoiding premature debate over detailed visual design.

The component sprint provides a practical framework for building design-system components collaboratively: prioritize openly, pair design and development from the start, and establish scope with broad input before implementation begins.