The Mission

"Creating a themeable Design System for a multi-product company to increase acceleration, decrease lead times and produce an overall consistency for the "Europace Experience"

Setup

Team members: 3,5
UX Design: 0,5
UI Design / Product Owner: 1 — Hey, that's me!
Development: 2  — Innersource Code Owner

Designers Note:
The development of a design system, contrary to what might be assumed, is not a linear process. Much like any other product, its creation was highly iterative. This involved repeatedly revisiting and refining previous steps based on new learnings and insights, ensuring that these were effectively integrated into the system.

First of all:

Getting the buy-in from the product board.

To secure resources for the design system, it was essential first to highlight the issue it aimed to address. The existing process of discovering and delivering solutions was costly and slow, often leading to repetitive development. Additionally, various product teams operated in silos, lacking a unified design language. This awareness wasn't a one-time effort but involved ongoing communication between the design system Product Owner and the Product Board, ensuring the design system's problem-solving capabilities stayed in focus and resources remained allocated for it.

Creating the vision of the design system

In order to have a clear idea of where the journey should take us, the vision of the design system was developed in a workshop format and in consultation with the product board. The product and product design principles as well as the company's business goals served as the basis for this.

The challenge to streamline:

10

Products

04

Design languages

03

Frameworks

Funny findings

• 50+ grey scales in one product 
• a whole platform used inline styles
• no clear separation between front and backend
• altering design languages inside of one frontend
  

And now the biggest part: Alignment.

Gathering info about the current state of tech environments

Different decentralized teams are working with different tech stacks. From Angular to React over to old GWT or plain HTML / CSS landing pages.

For that, the decision to produce a web component-based Library was set, as the maintenance of multiple, framework libraries was not possible for resource reasons.

Gathering the roadmaps and goals of the product teams

In order to understand the prioritization and plans of the product teams it was necessary to gather their roadmaps and the goals they want to achieve. In that way, we could identify on a high level which team could participate in being a pilot for the first design systems components.

Setting up first KPIs for the design system for making the impact measurable

Making the impact of a design system measurable can be tricky. Especially in the first steps and phases. We identified a set of shared core components: how many of these have already been described in the concept, and implemented in the design and how many have been written in code to make the success of usability visible?

Adoption was chosen as the second indicator to show whether the teams make use of the components.

Thirdly, and for later phases, we chose lead times for design and dev tickets. How quickly can concepts and designs be tested? And how quickly can new products be made marketable and go live?

Identifying pilot teams with
Product Board and Management.

12 Teams were interviewed to identify their potential of being a pilot for the first design system implementation. 1 team was chosen to be the first pilot partner due to the fact that they were building a brand new b2c frontend.

Setting up the
required architecture

A scalable and easy-to-maintain library & token architecture were provided for delivering the right environment for the B2B Platform with multiple running products, several B2C solutions as well as white-label solutions for our clients.

Development of a token system for centralized management of design decisions

A key requirement was that design decisions could be managed centrally to make them available to both design and dev roles. This made the use of tokens indispensable. After recording the necessary tokens in the first version, naming conventions were established on which all subsequent tokens could be developed.

The token set made it possible to meet the growing demand for white-label solutions for Europace products and to deliver scalable offers for this market.

Creating foundations

In the course of the rebranding of the Europace brand, the first foundations such as color palette, fonts, elevations, state rules, etc. were developed for the design system.

Identification of first standard components and production of UI libraries

After creating an overview of which components are the lowest common denominator across all products, these were created in the concept and design. A concept/wireframe library and a delivery/design library were made available for the design roles.

The first goal was to have easy-to-use and ready-to-prototype Figma component libraries.
To ensure that we were in constant feedback with the actual users of these libraries: the product designers in the respective product teams.

Since then, these versions have been successively expanded, and feedback from user research from the product groups has been incorporated through regular exchange formats.

Documentation process & templating

Documentation is a tiresome topic but a must for every design system. For this reason, documentation is an integral part of the acceptance criteria for design system tickets.

To facilitate the documentation of components, various template formats have been developed to simplify the process and reduce the structural workload for employees

V.1 Innersource governance process was developed

Bottlenecks in developer resources led to the decision to use an inner source model. A first version of the governance process was developed and introduced to decide when something should become part of the system or whether a development is a stand-alone solution.

Automation, PR rules & semantic versioning

To compensate for resource bottlenecks, a lot of emphasis was placed on automation and autonomy of the design roles. The token system makes it possible for design roles to push a PR draft via Tokensstudio and preview their changes in a storybook. If the adjustments are as desired, the PR can be submitted

MVP release of the first usable version in Q1 2024

A testable beta version has just been released and is currently being tested so that it can be used in early 2024.

The MVP package are the token set translated to CSS and the first component of a checkbox. Whitelabel themes for customers are offered in a separate package.

Let's talk about it.

If you have any feedback, questions, or any type of input: don't hesitate to get in contact with me.

Imprint  —  Data Security