When we started building a design system we approached it as a project, but as we all know a design system should be always evolving. Therefore it would be a never-ending project. And a never ending project.. that’s something nobody really wants. In this blog I will share how we started our design system as a project, moved on to a process, what the process is and how this works for us.

Why was it a project at first

At first we approached it as a project because we weren’t sure of the outcome or where it would exactly go. Step by step the design system became what it is now.
We couldn’t build the components from scratch because we had to deal with existing styling and legacy. Within the project we did sub-projects, such as replacing all the icons and buttons. But other cases were much more process bound: Identify the component, check the level of legacy and pick the approach to replace it.
In my previous blog you can find more about why and how we started to build a design system.

The tipping point

We had no clear end point for the design system as a 'project' but we had a roadmap that said ‘Convert the core elements’ and 'Reduce custom styling and merge generic styling from applications into one shared bundle'. So when most of our components were reviewed and renewed and we saw applications and client specific styling shrink, we got the feeling the end for this so-called project was near. Also the design system started being used in two major projects and where normally templates were leading, design system components were now used to rapidly implement new UI's.

Setting up the process

Now that teams were using the design system to create new views from scratch, we were getting a lot of questions, such as: “Why can’t this widget do this?”, “Is there an option for that?” etc.

We went from existing components that needed to be reviewed and renewed, to question driven design and development. This required something different than our project-based approach.
In one project, we combined developing a new product and developing new design system components. This failed because of sprint pressure. We where making decisions on the fly, which wasn’t good for the quality of the developed components. So we needed to make a change.

Team

We already had a core team responsible for the development of the design system and which held a weekly meeting. But the team was focused on the project and we were mainly pushing our own agenda. Different members of the team got requests for changes and were figuring out how to deal with them. We needed to change our mindset. The design system team wasn’t only there anymore to create a design system but also to improve components, develop new components on request, help and share.

A structured way to get input and to act on the input

Requests came from everywhere: on slack, one on one, on product development boards, after demoing a feature etc. All this communication needed to be channeled and structured in a better way.

While we were running our design system as a project, we had been using a Trello board with 4 columns:

• Backlog
• Issues
• In progress
• Fixed.

To better facilitate the process, rather than a project, we changed the columns to:

• Backlog
• Inbox
• Specs
• Design
• Front-end
• Review
• Implementation

Inbox

Although the first column is Backlog the process starts at the Inbox. Everyone in our company adds their requests to the inbox column. During the week everyone can report or request a new component, additional functionality for a component, an error, inconsistencies, etc. On Monday morning the design team goes through all the cards that have been added to the Inbox. We discuss the request: is it something we want, we need, what is the priority and what needs to be done. Cards go from the Inbox to the Backlog (low prio), Specs. (yes we want this), Front-end (this is a minor change or a bug) or are rejected (this is not something we want).

Specs.

Specs, specs, specs. For a solid design system in which components are developed for the right reason this is an important step. We’ve already checked if this is something we want but in this column we have to do a more in depth search. Why do we need this, don’t we have an other component already providing these features, what is the core function etc. When the specifications are clear we can start the design.

Design

With the specifications we start the design of the addition, component or function. The styling and interaction are worked out in this phases.

Front-end

After the design phase it is sent to front-end. A front-ender picks up the component and develops the component or makes the changes.

Review

When the styling and front-end development is done, we review the component before it goes to implementation so we can still make changes if this is needed. We check if the component meets its specifications. After the review is done and there is nothing to be changed, it moves to implementation.

Implementation

Implementation has two sides. First there’s the actual implementation in our applications where the request came from in the first place. Additionally, the functionality is added to and documented, in our component library, so it's accessible for everyone to use.

Backlog

As all other backlogs, cards that go here are good ideas but have no priority.

Turnaround time and fall back

The turnaround time of the process depends on the kind of request. Adding a different type of icon to the confirm widget can be done within a day, while developing a whole new component could take a couple of iterations. We have no strict time frame.

The development of our applications follow a continuous development process. Most of the time the need for new components starts when concepts are formed or pages and flows are designed. This means there is still enough time to develop the component, or at least the MVP (minimal viable product) of a component before it gets to development. But sometimes there isn’t much time to wait on a new or improved component. In that case we have two options for fallback;

• Use existing items
• Custom (and local) code.

Both come with the arrangement that when the new components is available, it should replace the previous implementation.

How we are rolling after a few months

We’ve started this process at the beginning of this year, so we have been using it for a few months now and it’s good to look back on that.

Promoting the inbox

In the beginning not everyone could find the inbox and most cards were about improvements and issues people from the design system team found, but now most cards in the inbox are from non-design system team members. We've promoted the inbox in our monthly company demos, there is a link on the homepage of our component library and when someone sends a question in Slack everyone refers them to the inbox.

The process

The specs and review step are still a bit underrated. We quite easily decide whether we should take the request in production, send it to the backlog or reject it but we easily step into design or front-end without good specification. This sometimes produces errors and miscommunication, which at the end costs more time to fix. Because the specs are incomplete, missing or too vague the review step is already undermined. This step is mainly being used to ensure code quality at the moment, but it would be good to also review the functionality. These steps feel more like a formality right now, and we have to figure out how we can use these steps better and more efficiently, so they feel like they are actually contributing.

People know what they can expect (and that's important for the design systems foundation)

When you need something in a project but it isn't there, that can be very frustrating. Now with the process we implemented, people know what they can expect. Cards that have been submitted in the inbox are always reviewed on Monday, issues and errors are still handled as soon as possible. We inform people whether we are going to add it to the design system or discard the proposal.

Is it a component or a one hit wonder

Especially when new things come around, it's good to realize if it is something we want for the long run. Can we see this concept being used in other views or application, or is it just needed for this one time? Usually when the concept is very complex and heavily relying on it's context, you shouldn’t make it into a standard design system component. Custom design and development are also a valid option in these cases.

Still it can be hard to determine this, because you just can’t look into the future and know which features users need or what new innovations developers will create. Having this Monday meeting with the team allows us to take a step back and discuss these things and make the right decision.

Conclusion

• The process is part of the quality assurance of the design system.
• With the process we have integrated the design system even more in our organisation.
• People know what to expect.
• It keeps us from making (bad) decisions on the fly.

It's a living thing

The best thing here is that our design system became a living and evolving design system. It hasn’t become a finished project which ends up in the back of a drawer - which I imagine is the fear of anyone working on setting up a design system. People, from all disciplines in our organisation can actively contribute. It’s adopted in the way we work. Even though the process isn’t finalized (will it ever be?) this works for us.