The anatomy of a component sprint

At The Washington Post, we help readers understand the rapidly evolving events shaping their world. In order to deliver the news quickly, reliably, and at a high quality, we need tools and processes that accelerate collaboration. So, in 2019, we embarked on an ambitious journey to craft The Washington Post Design System (WPDS).

Building a rich library of interactive components hasn’t been easy. In the early days of the design system, we shipped new components either through a design-led approach (as in the case of select, radio and checkbox inputs), or a developer-led approach when it involved more technical complexity (as in carousel and input search). Both of these scenarios had their pitfalls, causing delays and unexpected compromises. It became clear that we needed to get the right people in the room early on to offer guidance and close knowledge gaps. After years of refinement, we’ve developed a component sprint that does just that. Led by a designer-developer pair, the component sprint acts as a bridge between teams and ensures meaningful collaboration at every step.

The Washington Post’s component sprint starts with pairing a designer and developer who champion the process from start to finish, while also gathering insights from the wider team.

If you’re reading this, you’re probably familiar with the pains of siloed design and development workflows. Before we instated the component sprint, we suffered mismatched expectations around how a component should look or function. At times, developers were put in the awkward position of pointing out potential technical limitations, or being pressured to focus on nuanced visual details rather than devising solutions. At other times, miscommunication limited the contexts in which a new component could be deployed. Designers were disappointed that their use cases weren’t fully considered—or worse, were unaware of existing components that could meet their needs. As a result, some opted for their own solutions, which led to frequent overrides and requests for features and variants that needed to be assessed on the fly by the design system team.

The component sprint evolved our process from a closed, linear approach to a more open and inclusive one. The roughly 10-day process guarantees balanced, democratic input, and we kick one off for every single component we plan to work on, though some sprints go faster than others. Here’s how it works.

The component sprint evolved our process from a closed, linear approach to a more open and inclusive one.

“ The component sprint evolved our process from a closed, linear approach to a more open and inclusive one. ”

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

To have a true sense of shared stewardship in what is being built and shipped, gathering as much input as possible is crucial. For example, we have a weekly 30-minute meeting where we evaluate our candidate component tickets in Jira based on potential impact versus effort. Each ticket on our idea board is a dynamic space for stakeholders to leave feedback and insights asynchronously. We also use these tickets to capture relevant information from our many conversations on Slack.

Bigger circles indicate ideas with more votes. The number in each circle denotes a cluster of related ideas, and the color correlates with business goals correlated with that cluster.

Once we prioritize a component ticket based on everyone’s input, we assign a designer and developer from the core design system team to take charge of its delivery. Pairing them from the start ensures that communication happens throughout the entire process.

Concept: Defining scope and goals

Next, we schedule a two-hour meeting to kick off a sprint with the wider team. In a FigJam file, we define goals, agree on requirements, assess the scope of work, and leave 15 minutes for review. Gathering everyone in a FigJam file helps further democratize the design process because it allows both technical and non-technical contributors to clarify expectations, align on assumptions, and agree on technical requirements for the component without getting mired in design specifics just yet.

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.

After aligning on a shared vision, we move into a state of mutual discovery. During this hour, we drop screenshots, links, reference code snippets, and other artifacts from our site and around the web into the FigJam, annotating them according to our defined toolbox: API, behavior, accessibility, animation, options or variants, considerations, and requirements. This framed approach allows us to quickly capture and categorize insights from everyone in the meeting while narrowing the findings according to our scope and goals.

A discover toolbox using FigJam’s built-in widget helps organize links, screenshots, code snippets, and other artifacts dropped in the file.

We aimed to differentiate the action menu from our existing navigation menu, emphasizing its role as a temporary overlay that presents a contextually relevant list of commands or actions to the user.

For example, as we explored the action menu component, the exercise revealed a range of expectations around how it would function. Some stakeholders felt it would facilitate navigation, citing examples of navigational menus, but we’d already designed another component for that purpose. This prompted a thorough discussion. To avoid confusion and more accurately reflect its intent, we transitioned from calling it a “dropdown” to an “action menu.”

Run your own component sprint with this template modeled after The Washington Post’s workflow.

Design, implementation, and refinement

As the sprint continues, the funnel for participation narrows. After the first component sprint meeting, the designer-developer pair that we initially identified work asynchronously, touching base often to make sure that technical constraints inform the concept, and that the visual design informs the implementation. At this stage, 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. Continual dialogue is the bedrock of this phase, ensuring that both the design and technical aspects evolve cohesively.

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

A side-by-side comparison of a design mockup and code powering the input search component.

During the development of the input search component, for instance, a key point of discussion was the component’s empty state. The designer envisioned dynamic empty states reacting to user input: an initial state with a generic message, an active state reading “searching for…,” and a no-result state with a message like “no results found.” The developer, on the other hand, prepared for a static empty state based on actual search results. Constructive dialogue helped them reach a consensus to implement a default empty state that users could customize to be dynamic. This then simplified the workload for both teams and created flexibility for end users.

When it comes to the final product, all of our components are delivered in the Figma and code libraries at the same time, so no one is designing or building with assets that don’t exist. The designer-developer pair coordinates to make sure these changes happen in sync.

Delivering preliminary documentation

Documentation isn’t just an outcome of the sprint—it’s an integral part of our process. By documenting our insights, decisions, and plans on the site, we ensure the longevity and adaptability of our components. It serves multiple roles:

• Blueprint for implementation: a shared point of reference for designers and developers.
• Record of decisions: the rationale behind decisions made during the sprint. This transparency is invaluable when new team members join or when we revisit a component to make informed modifications or extensions.
• Stakeholder communication: a touchstone for communication with wider stakeholders and a way to invite feedback early in the process.
• Feedback loop: a tangible artifact that facilitates further iterations, as the component sprint might reveal additional considerations or optimizations.
• Knowledge transfer: an environment where anyone in the organization can understand the intent, capabilities, and limitations of a component, promoting informed usage.

The Washington Post Design System UI kit documents all their components.

Since adopting the component sprint, we’ve cut down the delivery time of a new component from six weeks to approximately 10 days. The process has greatly minimized, and in some cases completely eradicated, blockages due to technical limitations or the need for last-minute compromises. While we track design system adoption through internal tools and Figma’s library analytics, it’s ultimately part of our culture—and considered in our annual performance goals—to exhaust the design system as a resource in both design and development.

Design systems don’t just deliver components—they act as bridges, facilitating connection and understanding across teams. The true power of a design system lies in bringing together diverse perspectives to achieve collective goals, which is why an open process is so important; when everyone has a stake in the system, the result is shared stewardship. The evolution of our component sprint ensures that each component is robust, adaptable—and mostly importantly—meaningful to its users. We hope our journey inspires others to continually reimagine their own processes.