Elli is facing a never-ending design and technical debt. Due to the fact that the implementation of new features and components had to be done quite fast. As the company matured, they started to realize that they products had an ever-growing amount of elements and components that were inconsistent not only throughout the different products, but within the same product as well. Having to find a color value for a new feature, was quite the challenge, and not more than a handful of components were implemented in a component library. This decreased the velocity of implementation quite a bit, and slowed down our delivery speed even more. Elli was under a lot of time pressure to deliver fast new features with top-notch quality and user experience, to keep being competitive in the fast-paced world of the e-mobility industry. And due to the lack of a proper set of guidelines and definitions coming from the design side of things, this was currently not possible to keep up.
As I landed into the project the first step was to connect with the different stakeholders in order to get a better overview of the current state of design libraries, and implemented components. And most importantly how was the current development flow at Elli. I had longer sessions and alignment with the PO's of the two products teams that were at the time taking care of the web storybook (component library), and mobile foundations team. Also, I met regularly with different designers as to test ideas, ask for their feedback and see their current work-flow when working with the current libraries in-use. On a first instance, the goal of the Design System was to provide consistency throughout the cross-platform Elli products. But in oder to achieve this, there was a large amount of foundational work that needed to be done first.
The long term goal for Elli's Design System Blitz, is to create a consistent, scalable and sustainable design system, that allows both designers and developers cross-platforms and cross-brands, develop and implement new features more efficiently, via a strong documentation and set of guidelines. The short term goal for Blitz, was to create the foundations of the basic global assets, so each product team could make use of those in the most seamless way possible. The most effective way to do so, was to create tech agnostic design tokens (see images below), this allowed us to switch assets easily due to the systematic approach the design tokens have.
Elli is facing a never-ending design and technical debt. Due to the fact that the implementation of new features and components had to be done quite fast. As the company matured, they started to realize that they products had an ever-growing amount of elements and components that were inconsistent not only throughout the different products, but within the same product as well. Having to find a color value for a new feature, was quite the challenge, and not more than a handful of components were implemented in a component library. This decreased the velocity of implementation quite a bit, and slowed down our delivery speed even more. Elli was under a lot of time pressure to deliver fast new features with top-notch quality and user experience, to keep being competitive in the fast-paced world of the e-mobility industry. And due to the lack of a proper set of guidelines and definitions coming from the design side of things, this was currently not possible to keep up.
Since Elli's digital products are up and running, advocating for quality, consistency, and guidelines, was not a piece of 🍰. It implied a large effort of convincing the right stakeholders, primarily: engineering managers and the VP of the department, to push forward design best practices, user experience and quality as a core factor inside of Elli's way of building digital products.
This was a never ending challenge, but I can happily say we had made a huge progress so far. One of the ways I approached this, was to pitch the stakeholders the value a design system could bring to Elli and how improved and efficient our processes could be.
To ensure consistency and scalability across out products suite, we implemented design tokens as a foundational element of our design system. These tokens standardized visual properties such as colors, typography, and spacing, enabling quick and consistent updates across interfaces. The use of design tokens not only streamlined communication between designers and developers but also facilitated the adaptation of our design system to future changes and expansions.
This tokenized structure also allows us to smoothly switch between the different brands under Elli product lines, in a consistent and hassle free way, as can be seen in the example below:
We have successfully implemented a fully tokenised color library, that allows us to switch between the 3 different brands that are under the Elli App (Skoda, Seat and Elli), and not only that but providing the foundational set of color guidelines for both designers and developers, that previously had quite a difficult time into finding the correct color value. We have implemented 10 different components, into our component library Storybook, including guidelines and best practices in a new documentation platform maintained by us, called Supernova. We are now slowly starting to bring all those assets into iOS and Android repos, and have just begun implementing the first batch of components 🥳.
We have fully implemented over 10+ different components into our component library Storybook, that feeds directly from our tokens structure from Figma via a Json file generated from figma including guidelines and best practices in a new documentation platform maintained by us, called Supernova. We are now slowly starting to bring all those assets into iOS and Android repos, and have just begun implementing the first batch of components 🥳.
Via collaborating with the different product teams, and specifically with devs and designers we created an efficient collaboration flow, where we gathered the necessary input for creating a tailored road map, that would fit the needs of our internal users. We managed to implement a fully functioning token structure that allows us to implement a single component that can be easily adapted to fit both the platform or brand requirements. This is not only reflected in code, but inside of our figma design file (design component library), where designers can retrieve all necessary assets from a single source of truth. Also both parties or any design system enthusiast 🤓 can have access to our guidelines and documentation platform Supernova, that stores all the do's and don'ts, specific details on which tokens were used were, among others; for a more in-depth detail on better working with our DS.
As previously mentioned, on the path to seek the best solution for Elli's design system, we crossed paths with the concept of Design Tokens. To generate this assets we used the help of a plugin called Tokens Studio, we started creating our tokens structure there, which allowed us to push design decisions bi-directionally, to both developers (json file) and designers (Figma styles from tokens).
But in the midst of the creation of our tokens, Figma released a new native feature that supported those tokens inside of Figma itself (Figma Variables), this allowed us to provide large amount of variables directly from Figma, without having to create hundreds of different states and variants for the same component (see examples below).
Reflecting on our comprehensive journey through this design system project we've gathered several valuable insights
These reflections have profoundly shaped our strategies and will continue to influence the progressive development of our design system, ensuring its relevance and efficiency into the future.