A component sprint that actually bridges design and development

When The Washington Post set out to build its design system in 2019, the team quickly learned that a siloed workflow produces components that miss the mark. Early efforts tended to be either design-led or developer-led, and both approaches caused friction. Developers were sometimes forced to raise technical concerns late in the process, while designers saw their use cases overlooked or discovered that existing components already covered their needs—leading to overrides and ad-hoc feature requests.

The solution was a roughly 10-day “component sprint,” led by a designer-developer pair, that runs for every new component the team plans to ship. The process is designed to get the right people in the room early, capture diverse input, and keep design and implementation moving in sync.

An illustration of a ship hull being built in a warehouse with several workers building the body or examining drawings

Kickoff: prioritize by impact and effort

The sprint begins with a weekly 30-minute meeting where the team evaluates candidate component tickets by weighing potential impact against effort. Each ticket on the idea board serves as a living space where stakeholders can leave asynchronous feedback, and the team captures relevant context from Slack conversations there as well.

Once a ticket is prioritized, a designer and developer from the core design system team are assigned to own delivery. Pairing them from day one ensures communication flows continuously rather than being handed off between phases.

Concept: align on scope in a shared space

The actual sprint kicks off with a two-hour meeting attended by the wider team. A FigJam file holds the agenda: goals, requirements, and scope of work, with 15 minutes reserved for review. Working in FigJam keeps the discussion accessible to technical and non-technical contributors alike, so the team can clarify expectations and agree on technical constraints before getting into visual details.

From there, the group moves into a discovery phase. Participants drop screenshots, links, reference code, and other artifacts into the FigJam file, annotating each one according to a defined set of categories: API, behavior, accessibility, animation, options or variants, considerations, and requirements. This structured annotation keeps the input focused and tied to the sprint’s scope and goals.

A screenshot of a FigJam file shows clusters of stickies next to considerations like form factor, positioning, viewport / display behaviors for narrow widths, and relationship to similar components.
In a kickoff for an action menu—initially conceived as a dropdown—the team brainstormed requirements, opportunities, constraints, and other considerations in a FigJam file. Here’s a zoomed-in view.

The exercise regularly surfaces differing expectations. During work on the action menu component, for example, some stakeholders saw it as a navigation tool and pointed to navigational menu examples—but the team had already designed a separate component for that purpose. The resulting discussion clarified intent and led the team to rename “dropdown” to “action menu,” a more accurate description of the component’s role.

Design and implementation: a narrowing funnel

After the initial sprint meeting, participation narrows to the assigned designer-developer pair, who work asynchronously while checking in often. The understanding from the start is that both design and code are malleable: concepts can be reworked or discarded without blame. This continual dialogue keeps technical constraints and visual direction evolving in tandem.

A case in point is the input search component. The designer envisioned dynamic empty states that responded to a user’s search input—an initial message like “searching for…,” a no-result message, and so on. The developer had planned for a static empty state based on actual results. Discussion led to a compromise: ship a default empty state that users can customize to be dynamic, reducing work for both teams while maintaining flexibility for end users.

All components are released to the Figma and code libraries simultaneously, so no team is left designing or building against assets that don’t yet exist. The pair coordinates to keep those releases in sync.

Both the developer and designer understand their work is malleable: It can be reworked, or even discarded, and no one is the villain for suggesting a change.

“Both the developer and designer understand their work is malleable: It can be reworked, or even discarded, and no one is the villain for suggesting a change.”

Brian Alfaro, Design Lead (Design Systems), The Washington Post

Documentation as part of the process

Documentation is not an afterthought but a core deliverable of the sprint. Publishing insights, decisions, and plans on the design system’s site serves several purposes:

  • Blueprint for implementation — a shared reference for designers and developers working on the component.
  • Record of decisions — a rationale that helps new team members get up to speed and informs future revisions.
  • Stakeholder communication — a touchstone that invites early feedback.
  • Feedback loop — a concrete artifact for iterating as the sprint reveals new considerations.
  • Knowledge transfer — the whole organization can see each component’s intent, capabilities, and limits.

Faster delivery, shared ownership

Adopting the component sprint cut delivery time for a new component from six weeks to about 10 days. It has also minimized—and in some cases eliminated—the last-minute compromises or technical blockers that plagued earlier efforts. The team tracks design system adoption via internal tools and Figma’s library analytics, but the system’s deeper value is cultural: using it is part of annual performance goals, and everyone in design and development has a stake in making it work.

The real goal of a design system, as the Post’s experience shows, is bringing diverse perspectives together so that components are robust, adaptable, and meaningful to the people who use them.