Emmi Törnroos
Lyyti design system
Design Ops
As both our product and the product team gained maturity, documentation of components and guidelines on how to use them was non-existent. We needed to put a system in place to manage design at scale while creating a shared language and consistency in the product and in the ways that we worked.
Challenge
Many different people had worked on different parts of the product and created inconsistencies due to unaligned teams and individuals - we had no real system in place to counter it. We needed a way to align teams and the solutions that they were building.
Role
Product Designer
Project management, User research, Visual design
Beginning of 2020 - End of 2021
Background
About me
For a long time I was the UX Team of One in Lyyti. At the end of 2019 I had successfully convinced management to invest more in research and design. So, at the beginning of 2020, I had begun building our design team from the ground up and we had just hired another UX Designer, Fabiana. We had an excellent opportunity to start documenting the components we used and create a reusable system that would benefit both the designers and developers, and most of all our users - using the design system, we could bring them valuable features much quicker.
The need
At the time Lyyti was a 14-year-old B2B SaaS company. The product had grown organically through the years. Many different people had worked on different parts of the product and created inconsistencies due to unaligned teams and individuals - we had no real system in place to counter it. This had led to a disconnected user experience in different parts of the product. We wanted a way to align teams and the solutions that they were building.
My hypothesis was that by developing a design system and continuing to maintain it, we could help teams
- By giving them a more structured and guided way to build solutions to their problems
- To build solutions more efficiently, without having to build similar components from scratch every time
- To create consistent experiences to users by introducing shared sets of principles and rules to components
Getting initial buy-in
The idea started in a Slack conversation in late 2019 between myself and a developer working at Lyyti. Both of us had been troubled by the inconsistencies in the product and how slow developing new features was.
We pitched our case to our CTO and leads by highlighting the benefits the design system would bring
- Efficiency - reducing building time for both design and development, no more scouring files or folders to seek knowledge about the similar solutions
- Consistency - visual, functional and internal consistency
- Faster time to market - increases delivery frequency
- Scalability & maintainability - Saves time and effort on making product/platform-wide changes
- Reduced design and development debt - provide a unified language for teams working on the product
- Accessibility - it is built into everything we do
- Improved teamwork and collaboration - reduces frustration and miscommunications
With shifting priorities and lack of resources, a group of designers, myself included, and developers got to work about a year later in August 2020. OKRs were set to measure our progress and I was set to oversee the project.
Because we wanted everyone to express their problems with current development and have ownership of the solutions, we wanted everyone to contribute to it from the beginning.
Kick off with research
Building a design system was new for all of us, I had no previous experience with it. I read every article I could find about it, attended various webinars, joined design system Slacks and sought counsel from designers who had been working with design systems for years.
1Architecture
Together with the developers, I researched different ways to build our design system architecture. It needed to work both for the designer and developer and not be a chore to use. Weighing the different options, we landed on a process that designers would create the components in Figma, developers in Storybook and everything would be combined as the single source of truth in Zeroheight, containing both documentation and versioning. Zeroheight was the perfect solution for us so that the whole company could access the brand guidelines and documentation - we wanted everyone to use it and to contribute to it.
2Audit
First, we needed to understand what we were working with. The perfect tool was an UI audit - I gathered different UI components we were using in the product to a dedicated file. It was a great way to highlight the inconsistencies and understand the solutions we already had in place. As a “fun” fact, we discovered that there were 8 different variations of datepicker components in the product.
3Start from scratch or use an existing library?
When creating a component library for a design system, there are usually 3 approaches that can be taken
- Creating your own - Build it completely from scratch
- Adapting - Use an existing library as a base and modify it to your needs
- Adopting - Use an existing library as is
Each solution has its own pros and cons. Building a library from scratch maximises brand differentiation but is time consuming and expensive to build. Using an existing library is cheap but brand differentiation suffers. That’s why we opted to use an existing library as a base and build on top of it. Both me and the developers on the team benchmarked different solutions and we landed on Material UI. MUI offers highly customizable design kits in Figma, and React UI library for developers which was tremendously helpful to kickstart the design system.
Starting with the basics
In August 2020, our team consisting of both developers, designers and a marketing specialist started with small steps in the right direction. Our approach was to first tackle basic components and then expand to more complex components.
Based on the discoveries from the audit, we set out to have a first iteration with the following implemented by the end of September 2020:
- Guidelines for colours, typography, shapes and illustrations
- Basic components: buttons, inputs and form controls
Lyyti had just launched a new brand that we wanted to use as the basis for the design system. We wanted to start with the basics, so we added the relevant content from our brand book to Figma and connected it with Zeroheight. In Zeroheight, we documented the guidelines:
- Lyyti’s logos in different sizes and formats
- Brand colours and interface specific colours
- Illustrations
- Tone of voice guidelines and tips
Building the UI kit
With basic documentation and our design system architecture in place, Fabiana and I set to work on the components. We spent a bit of time finding out the style that would communicate the essence of Lyyti.
Atomic design approach
I approached the design with the atomic design methodology because it would allow us to create a more scalable system that would be easier to update. Atomic design is composed of five distinct stages to create UI design systems in a hierarchical manner. The stages are atoms, molecules, organisms, templates and pages. During this stage, we focused only on the atoms and molecules, later branching into organisms, templates and pages.
Atoms can be thought of as building blocks that can’t be broken down to any smaller pieces, e.g. labels and buttons. We started on the atomic level to create the foundation of our system. When updating the atoms, the changes would populate to modules, organisms etc.
Next, we moved on to molecules. They are relatively simple groups of UI elements functioning together - for example a search bar. Creating simple UI molecules makes testing easier, promotes reusability, and consistency throughout the interface.
We documented all items in our UI kit to Zeroheight explaining how to select the right component for the right job and outlining the dos and don’ts of each component.
I really enjoyed this phase of the project as I got to work very closely with Fabiana and the developers in the group. Once a week we had a design system day where we all came to work on both the designs and the implementation. I worked in very close collaboration with the developers, seeking advice on technical feasibility in a close feedback loop and they showcased the implementations and validating it.
Design system in a legacy product
As mentioned, Lyyti was a 14-year-old product at the time. Building and implementing a design system for a legacy product is no easy task. We wanted to build the design system in React, but parts of the product were still using PHP.
We needed to plan carefully how we wanted to implement the design system. We decided to build it with React but use similar styles in older parts of the product. It was not a perfect solution, but we wanted to create as much consistency in the product as possible with the limitations that we had.
Internal launch
Together with the team, I set processes in place for updating the design system. A training was held for the whole product team.
The design system helped me to onboard new designers much faster - everything was neatly documented.
Learnings and reflection
I learned so much from creating (and eventually maintaining) the design system! It helped to level up my Figma skills and increased developer and designer collaboration. I feel it was one big reason the project was a success that developers and designers worked hand-in-hand. Because of our strong collaboration, we could tackle problems fast and efficiently.
As I was overseeing the project and had OKRs to reach, I also learned a lot on project management. To deliver things on schedule and encourage the team to work smarter, not harder. We managed to reach every OKR set to us, just by the skin of our teeth.
If I were to start a project like this again, I would spend time in the beginning to quantify the value the design system would bring to different teams and the business, and the value it brings to our users.
Next steps
I did multiple design reviews during the project, to ensure that the finished product was in line with the designs and the user experience was up to par.
Now the design system is turning from project to process, it&s a product in itself. A design system needs constant maintenance to keep it up to date. Lyyti now has a small team assigned to continue developing the design system further, and processes in place for everyone to contribute meaningfully. The idea is to start building more complex components (organisms, templates and pages) on top of the atoms and molecules.