A design system for all teams

Over the years Fielmann developed several different interfaces for their diverse users. Each project was done by a different team, without considering previous interfaces. New design languages developed each time. To prevent fragmentation, we create a unified brand image and pushed for more design awareness throughout the company by developing a design system which every team and role could easily use. 

The Team

  • 5 Designers
  • 1 Product Owner
  • 2 Developer

My Role

  • Market Research
  • User Research
  • Wireframing
  • Creating & Writing guidlines
  • Art direction for icons and pictograms
  • Infographic design

Used Tools

  • Sketch
  • Abstract
  • Markdown
  • Dropbox Paper
  • Trello

Duration
6 Month

Problem

Different teams would spend time on building the same UI elements in different ways. This was not only costly but would also fracture the look and feel of the brand across different touchpoints and user groups.

Goal

Create a single source of truth that all teams can use no matter which customer group (B2B or B2C), platform (web, app) or touchpoint (in store, at home) they are working on.

Challenge

Make it easier for each team and role to use the Design System and the  components it provides, then creating new ones.

The Process

Internal Interviews

... to learn about the different needs of different roles. We translated what they hoped to get out of the design system into meaningful improvements to their day to day work.

UI Audit

... to identify all existing components and their use cases as well as the different touchpoints we need to consider when building a single source of truth. 

Workshop a Visual Language

... that already considers the different use cases, so that interfaces and components that are not included in the design system yet can be created in the same look and feel.

Brainstorm & Decide

... on important guidelines we want to communicate so all designers are aligned on decisions that concern architecture and anatomy of interfaces.

Write Articles

... about the guidelines that we can present to each other and iterate on till we found a common understanding and language. These were refined again by a professional writer before being released in the design system.

Create Infographics

... to help communicate the guidelines as a picture says more than a thousand words, especially when it comes to visual concepts.

Document & Build

... all identified UI components so that designers can browse and read about existing ones and decide if they can use them for their current project or would need to create new ones.

Create Libraries

... to use in day to day work. Those would live in Sketch for designers and as React components for devs.

Establish Biweekly Meetings

...for designers between teams to update each other about new learnings and needs for the design system that could not be identified beforehand so that it stays relevant in the future as well.

Content Workshop

Posters of content to get stakeholder buy in

We wanted to achieve...

Atomic structure
Especially with all the colors floating around, we knew we had to start at the very beginning though we did chose other names. The structure of our design system was inspired by the Atomic Design by Brad Frost.

User based
Our company was not small, it had many teams with different users. We had interfaces for the end customer, the optician, interfaces that the optician and customer would use together and the office employee. We made sure to take the different needs into consideration. For example, the customer would get interfaces with more white space, more focus on legibility (especially because we are talking about people who need glasses) whilst the optician got interfaces that show more information and options at once.

So we decided on...

Complex but not complicated


We decided to adjust pillars for Atomic Design to make suit or needs better. “Atoms” was “Basics”, “Molecules” was “UI Elements”, “Organisms” was “ UI Patterns” which we found more self explaining. Instead of “Templates” and “Pages” we decided to provide information about the navigation architecture and common page structures within our different products. 

Flexible


As we had many teams working on different products, there would always be new needs and new UI elements emerging. To create a constant communication and feedback loop, we worked with the software Abstract to keep everyone up to date, but also to easily learn about suggestions from other teams. We also established a biweekly meeting to share new designs and catch redundancies early.

DIY

We wanted to not only document UI elements, but also guidelines about how we think about design at our company, so every role can be enabled to think like a designer. This meant we needed a wiki. We also wanted interactive capabilities so people could interact with the content and learn about behaviors such as states or streching on different screen sizes. Experiencing or reading.

Futura based

The brands main font was Futura. This was a great inspiration to us, as the Futura came with characteristics we could use, like border radius, sizes and spacings. We also based our icon font on it so they would look cohesive when used together. 

Article Overview

Button Documentation

Behaviour examples

Fun Fact
The wording and definition of Basics, UI Elements and UI Patterns sticks with me to this date. 

Lesson Learned
Because everything was built on a platform we even wrote ourselves, the design system not evolved anymore after my team left the company a couple years later. If we had done this with a more accessible online tool, the design system could have been carried on by anyone, not only us.