Creating and implementing a Design System for headless CMS

My

Role

I started and led the initiative through the stages of research and structural system and semantic definition with a multidisciplinary (design/dev) proto-team. After these stages I moved to a contributor role and helped with visual and implementation nuances.

The

Team

Throughout the 2 years of this project I collaborated and supported a broad variety of teams and working groups. From design team and initial Design system working group to cross supporting 4 development teams (total of 20+ people). More parts of the project were conducted by outsourcing partners, both in design and in development.

The

Outcome

Fully fledged and functional design system for a growing SaaS Product.

Sliming down the codebase by 22k lines of unnecessary code after the implementation of the desing system into production environment.

01

Context

During the couple of years I've been working on Kentico Kontent, the UI has changed quite extensively.

The latest big change has occured with a rebrand that happened in 2019. Product, formerly known as Kentico Cloud has got a new fresh name and brand - Kentico Kontent.

And of course change this big meant that we need our UI to reflect it. However a fairly simple change – switching to new brand palette and switching to more accessible combinations for section headers – was surprisingly costly in development time.
At the time we were seriously considering a large redesign in our roadmap for a next FY and to be honest this fresh insight was quite scary. If a fairly small and simple change cost us almost two months of 2 larger development teams, how much would it take us to do a substantial UI change in our product?

As time went on we decided to tackle both challenges (fresh, on-brand UI and Design System) simultaneously. Little did we know how big of a bite this proved to be.

Changes of the Kentico Kontent UI over last 2.5 years

02

the Process

This is a brief summary of the process we followed when creating the design system. In depth case study below

Problem definition

After our previous experiences with (slight) redesigns it was clear that we lacked the ability to make effective design changes across the scope of the whole product.

Phase 0 – Researching the problem space

This was the time when we asked the question:
What do we need from Design System?
We researched and discussed this with everybody impacted (designers, developers, content developers). We also had to address the questions of its expresiveness, technical feasibility and implementation as well as define the boundaries of what should be included in our design system.

Phase 1 – Audit and analyze

Here we've made a full blown UI audit. We mapped every piece of component in the UI, every interaction, every logical piece or composition. With a help from a developer on our proto-team we launched a CSS parser of all the styles, colours, typography styles, etc. Here we realized that our UI is much more messy and decentralized than we thought so.

Phase 2 – Systematize

This was a time for "cleanup". We organised everything into precise boxes. We created the abstract structure of the system, defined the taxonomy and semantic structure of our future design system based on the precise need of our product.

Intermezzo – New UI takes the limelight

As mentioned in the beginning, we were simultaneously working on a complete UI redesign for our app. Huge deal of the visual design work was outsourced to an external agency. Roughly at this time we received the final visuals and delivarables, so we started to define the Design System on the overlap of this new UI and our previously defined abstract structure.

Phase 3 – Define

We defined all the components of the new UI, starting with atomic things - colors, lines, surfaces, corner radii, gradients, layout rules, grids, basic typography scales etc... Every single thing was tokenized and for every single constituent of the system we defined its:

Phase 4 – Test and implement

We gradually build and defined more and more complex structures, and while building we also tested how various components and concepts fit together.

These definitions were then folowed upon by our development teams which implemented and tested their codebase representations. We also build and a design system library in Figma for the Design team and an extensive documentation for everyone in the company.

Early attempts at categorization

Collage of all the various buttons from our UI

Parser of all colors and typographic styles used in our app

New, accessible color palette

Example of our new semantic color system, high to low level tokens and usage guidelines in our documentation

Description and definition of an image tile component

The same component implemented in our Storybook and its various states

03

Shipping and Impact

After a longer deliberation we decided for a gradual implementation and adoption of the Design System in the product itself.

Right now, every product team that implements any new feature is obligated to implement a part of the component library into our mater codebase.

Regarding impact - since the implementation itself will take a substantial amount of time we expect a gradual return of investment, exhibited mainly by the more efficient implementation of both new UI and changes to the current one.

Right now we're measuring the percentage of already implemented components (vs. the rest of the codebase), and we're expecting to see the full impact on our ability to scale the product in the horizon of 2-3 years.

What did I learn: