From UI toolkit to Design System

Project overview

Soon after joining Devex, we designers saw a clear consistency issue. By working in separate squads different UIs for the same elements had been created. This made the site harder to understand and I proposed building an integrated Design System.

This project was built on the sides, taking an extra time while working on other projects to audit the involved UI and creating the related components. Then, we put things together and built the design system into a dedicated file. This is what we achieved:

• Around 70% of the patterns of the site were gathered into the Design System Figma's file.
• Most patterns applied in new implementations were shared independently of the product branch and the use of design tokens was consistent in all new designs and implementations.
• We improved UI design delivery speed by avoiding the need of creating low-fidelity mock-ups (we already had high-fidelity assets at our disposal) nor specifying interactions, when already available within the UI toolkit.
• We also had some responsive templates in place, allowing us to work in some projects within their UI context without the need of replicating those pages.
• Freeing our time of UI design gives designers the chance to put more effort into research, resulting in better UX work.

The building process

The start of the Design System was anything but quick. There was no dedicated team to work on it. This meant that we had to find a way of building while still delivering other projects to the rest of the product team without causing any bottlenecks.

Auditing without an audit

Devex platform includes different products and the development of those products was done by different teams. At the time, you could clearly find 3 different approaches to the design within the platform: one for news- and marketing-related content, other for the jobs- and recruitment-related content and finally the funding-related content, closer to jobs but with its own unique design patterns.

In order to successfully close that gap, we needed to gain perspective of what visual and functional patterns were alike, which were close enough and which ones were unique to their area. I proposed making a UI audit of the platform to collect all those items and then analyze how they related with each other.

There were too many elements and we already had projects waiting for us in the pipeline. We agreed on 3 actions to be done when facing any UI project:

• When working over an existing page, create components replicating existing reused elements as they are at the moment.
• While creating new elements, look for similar items within that same domain.
• If none of the above applies, discuss with the rest of the team about this addition's value and get agreement, or look for alternatives.

After a year in the job, we had the most common components of the Devex platform scattered along different project files.

Scaling the pre-existing UI toolkit

The front-end engineers were working with a UI toolkit based on Bootstrap 5 components. Some of them were basic Bootstrap components modifying the styles to match the Devex brand, others had a wrapper around them to expand their functionality. There were no use cases in place.

We started working by downloading a Bootstrap 5 UI toolkit for Figma and scaled by adapting those assets into our own design system file.

Setting the scope

The front-end team used various technologies: We decided that the system would be applied to new implementations only, using the Bootstrap 5 components as a base.

Atomic 2.0

I created a document defining the work process and proposed an Atomic 2.0 approach for being a clear standard applicable to the existing Bootstrap library.

Building design tokens

I began replicating all primitive tokens from our platform and defining them as Figma styles and variables, making them easy to reuse and update in the future.

Getting bigger

We had gathered all tokens and had at our disposition all Bootstrap assets as well as all the components resulting from our on-the-spot auditings. Our next step was to govern all those components and patterns into an understandable and cohesive design language.

We did so by defining use cases for components, to be used as reference when creating new UIs and as available documentation for the front-end team. We kept all that as part of the Design System file in Figma, given that the front-end would be built differently depending on the technology involved (React or Rails). We had plans to start looking at documentation platforms like Zeroheight or Storybook, but those never came to fruition.

To keep adoption high in the design front, we built several responsive templates for the most common pages, to be used as starting points for new projects. This way, we could focus on more complex patterns and research instead of spending time on replicating already existing UIs.