Back to use cases

Design system


2018 - 2019


Agile product team & me

My Role

Creation & design


At one of the companies I worked for, we decided to create a design system. There are many reasons to invest time/money into setting up such a system, but these were our main drivers:

  • There was a lot of design 'chaos' in the applications that we worked on;

  • We were building multiple interconnected big platforms, of which the designs weren't aligned;

  • The design being implemented wasn't guided by principles or research and resulted into a bad user experience;

  • The interface/component library needed a big update, the design wasn't really modern or clean;

  • There was no real design driven development in the company so it would be a good opportunity to educate peers on making good design choices.

The project was mostly maintained by my design colleague and me, with support of our product manager. We were given approximately 3 days a months to spend on this 'project'. There was no end-date, it was considered as a never ending process


Ready, set, go!

Starting on such a big project can sometimes seem a bit daunting. Especially if you and your colleagues have never done this before. Even though I read hundreds of articles on creating, building and maintaining a design system, I thought it was quite difficult to get started. But eventually we did, by creating an inventory of all the components that we were using and adding them to our Figma component library.

For us this was the most logical, since the team was using Photoshop and XD at the time and there wasn't one design file or library containing all of these components and assets we had. Figma seemed the best program for us to use and we still had to create functionalities with our existing component library. By doing this it allowed us to keep working at the same pace while also being able to investigate our current state of being. Especially for me being quite new in the team this was really useful.

Getting the foundation right

getting buy-in

When we investigated the existing components, we took a lot of screenshots and noted down all the missing items or functionalities/components of which the experience wasn't quite clear and could be improved. Besides that, we looked at where we were wasting time and what were the main causes for that wasted time, most of these reasons I have mentioned in the Background section.

We used this information to present to our management to get buy-in to spend time on building a proper design system and creating awareness within the development team.

defining a process

We first wanted to tackle the issues of not being aligned on the design, losing a lot of time in discussions and having no 'set of rules' guiding us in the process. This was really important to get fixed, since this was the core of most of our issues, especially being a remote design team.

We defined the following:

  • Tooling: which tools are we going to use and how are we going to use them? What will be our naming conventions, how will we create our components, how will we handle developer handoff?

  • Lifecycle: how do we create new components, when do we update components or other items and when do things get handled?

  • Feedback: who will give feedback, what's the desired timeframe for getting feedback, how does feedback get handles,... (eg how do you handle comments in Figma)

  • Team: who is responsible for what, who is involved (--> the whole sprint team),...

We documented this all in a dedicated Confluence space that everyone had access to. However, it was the goal to have a dedicated Storybook-like website in which this would all be described.

Getting started on the system itself

We got our buy-in and we defined our process, now it was time to get started on the system itself. Here we had to get started with our basics, which were the following

  • Design Principles: this was a tough one. We discussed a lot and had a few workshops, but in the end we let us guide by this Jared Spool article. One of those was for example "The user should always be aware of the context.". This was a problem in many of our current designs, you didn't know where you where or what exactly was expected from you as a user. We could actually use this principle when testing new designs and it would guide us in making good design decisions.

  • Colors: We defined all our colors and shades we could use as well as the possible cominations and their acessibility status. Both for marketing as product requirements.

  • Assets & Branding: We added and defined all our icons and brand assets as well as how they should be used and integrated in the system. I'm still not sure if branding/brand assets should play a big part in a design system.

  • Typography: We bought our own typeface and based ourselves a lot on IBM's design language. However, I'm not a typographic expert.

  • Accessibility: Since we were updating components and creating new ones, this was a good opportunity for us to incorporate accessibility requirements from the beginning. Our developers were actually enthusiastic and it didn't take them too much time to integrate this. We also took the time to re-educate ourselves as designers so it would be taken into account with all our our new designs and features.

- to be updated -

Result & Retrospective

To be updated