Design Systems

How might we

create a scalable solution for a multi-product company that accelerates delivery and enables white-label solutions across teams and tech stacks?

My Role(s)

How it started:

From Problem Space
to System Building

Started as a Product Designer in a product team and recognized that the company could miss opportunities to fullfill their strategic goals when not having a centralized solution.

Vision, Objectives & Buy-In.

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

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.

To 

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.

Horizontal to vertical

The main (standard) component library is therefore providing a horizontal layer to provide the product teams with the necessary building blocks to build their product specific libraries.

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.

Hands on.
Starting with standards first.

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

v1.0.0 Innersource contribution model was developed

Bottlenecks in development and design 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

Current version v1.11.0

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