Design System UI is More Expensive Than a Product Team’s UI

Higher Quality and More Engagement Require More Steps

As new collaborators engage with a design system for the first time, there are two common, similar objections:

There’s so many steps. It’s so long and too complicated.

This workflow is far more complicated than how we make things on our team.

First off, I recognize and validate their perception. Yes, making design system features requires many steps. It takes time. Yes, making design system features (on teams I lead) is always more complicated than how other squads make features directly for their products. But why? Shouldn’t it be the same?

There are two main reasons it’s not: quality and engagement.

1. Quality: Design systems must be made to a level of quality to meet or exceed what every adopting team requires. Team(s) resist using features from somewhere else if they feel they do it better themselves.
2. Engagement: Autonomous teams decide how to make a feature since they’re the only team using the feature. In contrast, design systems require wide community engagement to ensure features used by everyone are made for everyone.

Here, conversation may go sideways. “So, you’re saying we don’t make our product features with quality? You’re saying we ignore feedback from others? You’re saying our decisions are rash?” Nah, I’m not saying that. Instead, expectations and visibility of a design system’s quality and engagement are higher.

Also, other teams deal with many, many other complicated concerns that “dumber” UI features from a design system don’t. Design systems deliver only a user interface layer, blissfully unaware of data, security, services, monitoring, performance, and other concerns of a high-end product experience. Product designers and developers don’t expect design systems to do these things. What they do expect is that designing and coding a design system’s UI feature to be as easy — dare I say “quick and dirty?” — as it is on their team.

We must debunk the myth that a design system workflow should be the same as a product squad’s workflow. Instead, a design system needs more steps, substeps, and rigor to achieve the quality and engagement it promises.

Comparing System & Product Team Workflows

Once a design system has normed into a predictable workflow of making features, you can compare those steps and substeps to the process other teams follow.

Design Systems Include More Steps

In most design system programs, a workflow includes five or six top-level steps. From what it will Propose to Design, a team outputs Code, Doc, and Design Assets that it will predictably Release.

Contrasts with product team workflow emerge immediately. Product teams only release Code and not Documentation (anywhere near as deep or polished) or Design Assets (to be reused formally by other teams). A product team’s Propose workflow is usually limited to within-team grooming and planning, more rapid yet engaging less of at all with outsiders.

Design Systems Include More Substeps

Product and system teams pursue Design and Code similarly.

Product and system designers both scope features, illustrate variations and states, and annotate work for handoff to a developer. System and product developers both compose HTML, CSS, and JavaScript, test functionality and consistency across browsers, (hopefully) review with the assigned designer, and refine based on feedback during code review.

Substeps of design that product teams may not pursue

However, system designers also aggregate art from dispersed sources, more precisely align work with a visual language (usually, via design tokens), and respond to iterative feedback from critique with their design community.

Substeps of coding that product teams may not pursue

Similarly, system developers can’t just hack a solution and call it a day. Existing within an ecosystem of tools and dependencies, system developers are held to a higher standard of integration. The API must reflect conventions and feedback of the community. Test coverage must be wide and deep. If accessibility is a promise, specialists must review and approve every new and enhanced feature.

Design Systems Conduct Some Substeps More Rigorously

Many teams deliver features of at this high level of quality. Many coordinate and align work with other teams. Absolutely, there are high performing teams out there!

Unfortunately, there less-than-high performing teams out there too, getting by shipping design and code barely “good enough” to get the next feature into production. Design systems workflows can’t experiment in the wild like that (the scale of risk of refactoring across adopters is too high). Therefore, a system’s rigor is higher out of necessity.

Substeps of design that design systems pursue more rigorously

During Design, system designers must address all variations and states across many content types expressed across many, many product and platform settings. This considerably lengthens the bulky primary task to design the feature. System designers also smooth rough edges to ensure features robustly handle varying conditions of style, content, and behavior. This requires soliciting feedback routinely from diverse designers and specialists.

Substeps of coding that design systems pursue more rigorously

Code is more formal, too. Files must be consistently modeled and strictly organized in a repository. Detailed APIs requires iteration precise to a catalog’s conventions. Visual test cases are thorough, all those variations of composition, size, background, language, and theme. Concluding the work requires more dispersed reviewers, iteration and documentation.

Delivering interface features through a stable, predictable system over time takes work. A system team must know both its own workflow and be empathetic to the workflows and values of contributors too. So be aware of the differences between them. So equipped, you’ll be able to better articulate what you do to deliver with quality and community engagement and why it’s essential to your mission.