Contributing to Our Design System: The (Happy) Tale of Creating a New Component
From being imagined in someone’s head to being added to the design system and ready for use by everyone
Designing with a design system (DS) is great. Designing with a design system that’s missing that new component you need can be… scary.
A year ago, I needed a tag picker for one of my projects. We wanted our users to be able to add hashtags to written notes about their client meetings. We didn’t have a tag picker in our design system at the time and I had no clue what the process to create it should be.
Some of my thoughts were:
“How do I do this? Who should I talk to? Should I do it on my own? Should I discuss it with the people working on the DS beforehand? After?”
When I talked to my fellow designer-colleagues, I realized that I was not the only one struggling with this. It became clear that we lacked a clear process to receive, centralize and manage the requests and suggestions from designers using our design system on a daily basis.
That’s why we (the people looking after the design system, that we call the Council) started to think about how we could develop a simple but efficient contribution system. We wanted the system to be:
- Collaborative
Allowing anyone to suggest and work on improvements or new things to be added to the system. - Easy
Ensuring that the process of contributing and sharing ideas is super simple for everybody. - Transparent
Centralizing all design-related work and ideas about the DS in one place, accessible to all.
At the time, we had no contribution system and it took me a while and a lot of “adventures” to achieve the desired result of seeing the created tag picker up and running in the design system. This journey triggered the creation of our contribution system.
Now, let’s take a look at how you would create a tag picker following today’s flow.
1. Request creation
The very first step for every request is to create an issue on our Github Enterprise using one of our three pre-defined templates. We found Github to be a very helpful tool to centralize and follow up on all ideas.
In the case of our example, the designer needing the tag picker selects the “New component or pattern request” template because, well, he/she wants to create a new component.
The designer then fills in all requested information and creates the issue when done. The Council’s members are always happy to help them getting through that stage if needed.
2. Check by the Council
This issue is then pushed automatically into the first column of our Design system’s backlog called “New issues”.
The ticket is automatically tagged with its first label — in this case [NEW] that stands for “new component or pattern”.
Every Monday, the four members of the Design System Council meet and tag all the new issues created the past week in order to prioritize them. They define together 3 types of labels to be added to the tickets.
For our example the tag picker, let’s say the Council chooses the following labels:
- Something new — it doesn’t exist in the design system and it’s brand new
- Priority high — it is needed for a project and several other designers would use it on their projects in the near future
- Complexity 3 — it requires a lot of work from a design point of view
They also assign Henry as the Council helper for that component. His role mainly consists of ensuring that the component is aligned with the design system guidelines and guiding the designer through the different steps of the creation process.
The tagged ticket is then moved to the “Backlog” column.
3. Design process
When the ticket has been reviewed and labeled by the Council and the designer wants to start working on it, he/she starts a typical design process.
The ticket is moved to the “In progress” column and a checklist is added to the issue.
The designer working on the component checks the completed steps along the way so that anyone can check up on its progress and see when it will be ready.
4. Development
Once the the design phase is completed, the Github ticket is moved from the “In progress” column to the “Ready for dev” column. It means that the dev team can take it from here and start coding the component. During this phase, the designer acts as what we like to call the “dev hotline” : he/she works closely with the developers to ensure the specs are clear enough, answers any potential questions and reviews the component before releasing it into production.
Once the development phase is over, the issue is closed and moved to the “Done” column.
Now, you might think that that’s the end of it for the designer who initiated the request, but there is still one key step to be completed…
5. Documentation
Last but not least, the designer has to write the documentation detailing how the component works and how it should be used.
To do this, a new [DOC] issue is created and linked to the related ticket.
This phase is crucial, as we document all of our components and patterns. It is actually so important that we also have a checklist for the documentation steps (and yes, I do love checklists).
The designer requesting the new component writes a draft that the Council then reviews. Once everything is validated, it is integrated into a page on our design system website and the asset library is updated if needed.
Once completed, the DOC issue will be closed and moved to the very satisfying “Done” column.
The component can now live happily ever after (but still be edited if needed).
To sum up here’s an overview that illustrates the different steps of the process and the collaboration between designers, members of the Council and developers.
From being lost with my new component suggestion a year ago to being part of the Council and putting in place the new contribution system, I think we’ve made some great progress.
This system is working well for us so far but is likely to evolve, as we continue our pursuit of the perfect contribution system (if that even exists!).
Thank you for reading and please, feel free to share your thoughts and/or questions, I’m always happy to have a chat!
This article is part of our Design System series: a 5-year overview, 4 false assumptions, getting buy-in, governance & chaos (part 1), adaptive colour systems and surviving. Watch this space for more!
