Consistency vs. Flexibility in Design Systems

How Lucid’s Core Framework helps manage the tension between these important needs.

Design systems are a critical tool in helping product teams scale the quality, consistency, and efficiency of design output. At their best, design systems allow designers and developers to rapidly and repeatedly leverage quality design solutions, freeing them up to spend time solving first-order problems. For example, instead of creating new buttons each time a designer mocks up a screen, a designer can instead spend that time conducting thorough user research or optimizing a holistic workflow.

At their worst, design systems can stifle innovation or slow down the total velocity of feature teams, and while they are capable of scaling quality design solutions, they can also scale poor design solutions. If the design system’s date picker is a frustrating experience for users, it won’t get better just because it’s used consistently—it simply means you have a poor design (and by extension, user frustration) repeated throughout your product.

So how can you maintain the design system’s capability of scaling good design solutions and creating product consistency while also providing the flexibility needed to constantly improve and innovate? This was, and continues to be, a crucial question as we develop our design system. Lucid has a culture of fast-moving, autonomous feature teams that are empowered to make quick product decisions and constantly push the boundaries of what has come before. If we were to create a successful design system in a company with that type of culture, it would need to be one that allowed designers and engineers to continue pushing those boundaries.

To help guide our teams in the use of our design system, we developed what we call The Core Framework. Borrowing from geological terminology, the Core Framework describes layers of consistency within the product landscape; the patterns, components and behaviors that inhabit those layers; and how those layers interact with each other.

The Crust

One important insight for us — which may seem obvious, but is critical to the way we think about our design system — was that the design system is not the product. This means that our design system will never be completely comprehensive; there will always be components, patterns and standards that are not part of our documented design system. This is true in part because our team lacks the resources to adequately document the vast output of all of our rapidly-moving feature teams. More importantly, the design system is not comprehensive because not all output from every feature team should be included in our design system.

For certain highly specialized experiences — intentionally designed for a single, specific need — it doesn’t make sense for us to impose the constraints of designing a generic solution. In other words, if our product won’t benefit broadly from a specific design solution, we don’t include it in our design system. This both frees feature teams to push the boundaries of our product and also frees our design system team from the significant overhead of documenting, building, and proliferating a generic component that will only ever be used once.

These specialized experiences make up the Crust of our product. Highly subject to change with rapid innovation and experimentation. It’s the proving ground for some of our most forward-thinking solutions and it lives outside of our design system.

The Mantle

There are some product experiences that are often repeated, but not universally. These might be more complex patterns such as property panels or onboarding flows. Each may be slightly modified to meet a specific need, but still draw upon an established pattern that helps each instance of the experience feel familiar to users while also making it simple for feature teams to execute.

Many patterns that live in the Mantle may have started out in the Crust. A single feature team designs a highly-specialized experience that then gets picked up by one or two other teams to be used in different areas of the product. As the design scales, it must be vetted by each team and modified to fit a slightly wider set of use cases. This process of a pattern’s transition is formalized by inclusion into the design system. The basic behaviors, functions and usage guidelines are documented and made available to the entire team.

These Mantle patterns still maintain a level of flexibility. Certain sections may be added or omitted, some parts may get bolted on or replaced. But each change is bound by guidelines that help to provide consistency and clarity to users and product teams alike.

The Core

At the center of our product and design system are the patterns and components that compose the Core. These patterns are universally used by our product teams and appear in most areas of our product. Simple, generic components like buttons, toggle switches, radio buttons, check boxes, and text inputs live at this level, as well as brand standards like colors, icons, and tone of voice.

These Core elements, because of their universality in the product, require a much more stable and consistent application. A button in one area of the product needs to behave in the same manner as a button in another area. For users, variability in these Core components can cause massive friction, forcing them to re-learn what should already feel like second nature.

To ensure Core components are treated consistently, we explicitly label them as Core in our design system documentation as well as in our code base. Any proposed modifications to these components must include the design system team and pass through a rigorous approval process that includes thorough system audits and user testing before any change can be made. Because of their widespread use, even a simple change, like making scroll bars a couple of pixels wider, can have far-reaching unintended consequences.

It’s in the Core that the design system team focuses its efforts. We aim to ensure that all Core components meet a high threshold of quality and include important attributes like accessibility, touch interactions, and responsive design. In this way, we’re able to provide the most impact with a limited amount of resources, and we provide consistency where it matters most.

Using the Core Framework

Part of using the Core Framework is creating a shared understanding around where teams and individual contributors are safe to push the limits. By designating a component as Core we can clearly communicate to teams that any change will require a lot of time and effort to implement. When we talk about a Mantle pattern, a designer should feel empowered to explore alternative implementations that stretch its stated purpose. And when teams explore a new concept that requires a fresh approach to a novel problem, they should feel comfortable pushing the boundaries of our product in the playground of the Crust (while still leveraging Core and Mantle components where it makes sense).

As we refine and improve our design system, we hope to continue using the Core Framework as a way to frame discussions and encourage positive behaviors for those that utilize it every day. Helping designers and engineers understand what to do when they run into limitations of a component is crucial for them to act autonomously and with confidence, as they continue to push our products into new areas and explore innovative ideas. As our product experiences continue to evolve, we can continue to provide a unified, predictable, and intuitive experience for our users through our design system.

This is a post from the UX design team at Lucid. Lucid is the only visual collaboration suite that gives teams the power to go from imagining the future to building it. We make collaborative visualization and brand templating tools: Lucidchart, Lucidpress, and Lucidspark, and we’re currently hiring!