Introduction
What Is a Design System
At a high level, a design system is a collection of reusable UI components and interaction patterns, guided by clear standards, that can be assembled together to build any number of applications. Think of a design system as the building blocks of an application or product.
Benefits
Efficiency
Design systems allow designers and developers to reuse their components and interaction patterns across an application rather than repeatedly building components from scratch.
A common example of this is a simple button component. Prior to having a standardized button component in our design system at Indio, developers would recreate or copy button code from somewhere else in the app to use in their project. Over time we started to accumulate many different types and sizes of buttons – creating a lot of inconsistencies in our UIs. Creating components from scratch each time they are needed is really a waste of developers’ time. Design systems help to solve this problem.
Consistency
Design systems introduce a shared design language that informs the design of individual components and interaction patterns of an application.
Design systems allow for consistent experiences to be more easily created across teams, products, and platforms. A consistent design language also helps us to create better and more cohesive experiences for our customers and, at Indio, our customers’ customers.
Scale
Design systems allow product development teams to better scale their products and build faster.
Design systems not only help teams build faster, they also help in the discovery and research phases of the design process. Having a library of standardized components in our design tool, Figma, allows us to quickly create mockups and prototypes that we can put in front of users to get feedback on.
But Isn’t a Design System Just Another Name for a Style Guide?
Well, yes and no. In our view, a design system is not a style guide. A style guide can however be a piece of a design system.
A style guide is a static artifact of the design process that documents decisions made at a specific point in time. Style guides typically address foundational aspects of a product’s brand. Things like color, typography, spacing, iconography, and illustrations.
A design system is a living product that is in a constant state of evolution. Unlike a style guide, a design system is never complete.
Mature design systems typically contain:
-
Working component examples and documentation
-
Component sticker sheets for design tools (Figma, Sketch, etc.)
-
A set of design tokens/variables
-
Usage guidelines for components and interaction patterns
-
Style attributes and guidelines (color, spacing, type, icons)
-
Accessibility guidelines
-
Content writing guidelines
But wait, there’s more…
A design system should also include a set of processes that enable its governance, maintenance, continued evolution, and foster a community of contributors.
Design System Examples
What are some examples of design systems?
Obviously, these examples are managed by large, dedicated teams with significant resources behind them. Not all product development teams have the ability to fund a standalone team to work on their design systems.
Indio’s Design System
What does this look like for Indio?
Since we currently don’t have the capacity to build a documentation site like Google Material Design or Microsoft Fluent, our documentation is available in our design tool, Figma. All of our front-end engineers have access to Figma which allows them to self-serve and find the information they need.
Building a Community
How We Started
When I first started at Indio, there wasn’t really a design system. There was a library of components that were sometimes used, sometimes not, and not much standardization or communication around what to use and when. As such, we decided to start over.
We started with foundational elements, like color, typography, spacing, and basic components like buttons. At the time, Indio had three engineering teams. I would work with a developer on a component and then we would communicate out to the other teams via Slack, with myself being the single point of contact for all the teams.
Engineers from the three teams would reach out with questions and feedback.
This worked ok in the beginning, but then our engineering teams grew. We added a second team in Austin, and hired more developers in Poland and San Francisco. We also hired a second product designer and a director of product design.
We found that our ad hoc single point of contact approach didn’t scale very well. Also, individuals on the different engineering teams weren’t always on the same page with respect to the design system.
Since we were a small startup, creating a standalone team was out of the question. Rather than continuing on our current path, we saw this as an opportunity to build a community around our system with hopes of solving our communication issues.
Champion Model
We Are the Champions
Given that our teams were growing, and would continue to do so, how might we go about building a community around our design system that would enable contributions from any team member, while also allowing for communication to better flow across geolocations and time zones? We decided to implement what we call the champion model.
So what do we mean by the champion model? It’s really pretty simple. Each engineering team designates an individual to be its design system champion. The champion is responsible for gathering issues or questions from their respective team, relaying information back to their team, while also helping to drive the design system effort forward.
We also made the decision to expand the ownership of the design system. In my prior experience with design systems, I’ve found they work best if they are co-owned by an engineer and designer.
Now that we’ve expanded our community design system champions, how might we better plan design system efforts and communicate information back to engineers and designers? One thing we’ve done is to create a working group. The working group includes the design system owners, design system champions, and engineering leadership.
We get together every two weeks and use this time to discuss any issues identified by the champions and owners, and to review the overall health and progress of our system. Everyone in the working group is assigned tasks that contribute to the continued evolution of the system.
Federated Model
But How Do You Get Systems Work Done?
We’ve talked a lot about how we organized ourselves around the design system owners, champions, and working group, but how do we actually get systems work done without having a dedicated team? We’ll talk about this in more detail when we go over our processes, but the short answer is, we use a federated model.
Federated Model Overview
In this model, anyone within the greater product development team, whether they’re a designer or developer, can contribute to the design system.
Generally speaking, most design systems work at Indio is completed in the context of feature work. If a feature requires a new design system component or an enhancement to an existing component, any front-end engineer or product designer working on that feature is empowered to contribute to the system.
In the federated model, the product or design system is at the center. Sure, there are design system owners and champions who guide its governance and evolution, but putting the system at the center is key. Everyone is encouraged and empowered to contribute, and those contributions are then available for anyone to use.
What We Have Built Together
Here are just a few examples of contributions made to our Design System by our feature teams:
-
Tags
-
Progress Indicator
-
Avatars Photos
What’s Next
While many of our screens do utilize design system components, we do have a number of sections of our product that rely on old pre-design system componentry. Our approach to this is to retrofit these experiences whenever we do significant design and development work on them.
Accessibility: Our product just underwent an accessibility audit so ensuring accessibility is baked into our components is a high priority for us.
Component Refactors: With any design system, component refactors are inevitable. We have a few components that would benefit from a second pass.
Closing Gaps in Documentation: As mentioned earlier, we have large gaps in our documentation, but we’re always at work making it better.
Content/Writing Guidelines: Writing copy for a product is hard. Writing copy for an insurance product without having an insurance background is even harder. Having these guidelines available for new hires will be a huge help.
As I mentioned earlier, a design system is never done, and we have many, many gaps to fill. But that’s what makes this interesting, right?
Taylor Keeler is a Senior Frontend Engineer at Indio.