Bliss Design System v0.x
The initial journey of the internal design system for BRYTER.
When I joined BRYTER in July 2019, one of my primary focus-points was the creation of our internal design system. BRYTER still was quite young (little older than a year) but growing fast. The overall pace of development was smooth and new features were developed in no time.
Starting to build a design system from scratch, that supports the speed of the team while also trying to systematize and consolidate the overall product design, sounded like an exciting challenge.
Looking at it from today's perspective, we established foundations for designers and developers to consolidate their work and improve the overall alignment and consistency. Designers use components inside Figma and follow usage guidelines for components inside our documentation. With our Bliss CSS library, developers move quicker and build solutions more consistently while speaking one language when collaborating with designers.
Getting the fundamentals right
During my first weeks at BRYTER we started to take the initial steps to get started on our design system. After conversations with some design, product management and engineering folks, we began drafting an RFC to summarize our plan.
Based on this RFC I moderated different discussions to get a broader understanding about the different viewpoints. Involvement of the product team was superb and also critical because the design system would affect everybody from our product team, it wasn't only focused on designers or developers.
From the start, one of the key goals of our design system was to create a technology-agnostic solution. While Figma was our tool of choice to create the pieces of the design system for designers, we agreed on a CSS library with semantic and accessible HTML suggestions for developers. This would meet the balance between being technology-agnostic and also fast in terms of our implantation time. Besides that, it also provided fast feedback cycles, which becomes crucial if you're developing something new and want as much buy-in as possible.
After all the initial discussions and alignment across the product teams, we also agreed on (unarguably) one of the most important parts of a design system, its name. From this point forward, our design system was called Bliss.
Atoms are everywhere
At the beginning of Bliss, we deliberately focused on small pieces with big influences across the design of the product. For us, it was clear from the beginning that we would start with agreeing on atomic design decisions before getting to any components (e.g. buttons, tabs, form elements...):
These different areas are the fundamentals of every interface at the core. With the initial focus set, we immediately started with redefining our color system. As I was playing with the colors, it became clear to us, that we needed a system to make more systematic decisions around color. A more systematic approach would especially help us make our reasoning and guidance around accessibility and color contrast easier.
With a color system defined from a design perspective (designers could use the colors with Figma Styles), we needed to also make this available for our developers to quickly create real life examples for our new colors.
Everything is a token
To help bridge the gap between design and development, we introduced Design Tokens as a toolkit for manage atomic design decisions, like colors. For the implementation and management of our Design Tokens, we started using a tool called Style Dictionary.
With this in mind, we started to extract the color values from Style Dictionary and release an initial version of what we later called Bliss CSS, a CSS library that enables developers to get the Bliss visuals into the codebase. After we released all the color tokens, we started to go through different areas of the BRYTER product and replaced old with new color styles. These new color styles are now served by Bliss CSS as Design Tokens.
We repeated this approach for Typography and Spacing. First, design everything inside Figma, then bridge the gap between design and development with Design Tokens, and lastly offer finalized styles to developers with Bliss CSS. This specific approach worked perfectly with these small design atoms, and it had two main positive effects:
1. Designers and developers started using Bliss directly and could align our design language more and more (color names, typography styles or spacing, everything had the same naming structure now).
2. Because we actively started replacing working code with new Bliss CSS Design Tokens, developers weren't scared to try it out themselves and saw the positive impact right away.
While all the foundational work is needed and Design Tokens already helped designers and developers in their daily work, actual components is where the big gains become noticeable. The interesting challenge for us during the development of different Bliss components was the alignment between what was already in use and where Bliss needed to align different approaches to surface one general solution.
Therefore, we started every component creation process with an interface inventory to surface current patterns and see where we can align components. Because most of the tasks around Bliss at that time were led by myself, good prioritization was key to keep a good and constant release flow going.
During my time working on Bliss, this was probably the most "heads down and produce" phase. With our roadmap in mind, I mostly switched between Figma and Bliss CSS to develop components on both ends, while also getting feedback from designers and developers. This process was a huge collaboration effort and I couldn't have done it without the help and guidance from all people involved.
Documentation is king
By the end of 2019 releasing new Bliss CSS components had become common, but documentation started falling behind. While we started using Notion at the beginning to document decision-making and basic guidelines around components, Notion wasn't the right place to have detailed documentation for a design system.
Because of a lack of resources (work around Bliss was mostly done by myself at this time) we needed a quick solution without much initial effort. We decided to go with zeroheight to create one unified place for documentation. One place where designers, developers, product managers or anybody else could go and find what they were looking for.
Besides the general foundational and design documentation, the key focus of the documentation page was around components. Each individual component page followed a three section model.
All the general and design-focused information about a component. What are its variants? How to use it? What type of content can this component accept? What are the accessibility guidelines?
If somebody wants to understand everything around one component, this section is the one they would go to. For more detailed questions, there is always more to explore, but this page is for everyone.
The code section of the component documentation was mostly for developers. This page hosted some code examples that could be manipulated in real-time. All the showcased examples where semantic suggestions on how to use the Bliss CSS classes to get to a specific result. They also included some accessibility best practices.
The tokens section was a straightforward documentation of all the specific design tokens that were scoped to an individual component level.
Pause and struggle
While the first seven months of our Bliss journey were full of improvements and progress, sometimes priorities change inside a fast-growing company. As the design system got to a level where general usage was common across our different teams and other pressing features were more important to the company, I moved to another team. As the only core member of the design system team, this meant that Bliss needed to go into a temporary maintenance mode and with very limited resources only bug fixes were possible.
A new beginning
While the time Bliss went into maintenance mode took longer than initially expected, it had a good outcome after all. On one hand, we could prove that Bliss offered value to our teams and across disciplines. On the other hand, it became clear that we needed to put more focus into Bliss to make the solutions it offered even more beneficial to BRYTER.
That's why we decided to hire a team and start the journey to rethink the current state of Bliss. Moving into a world where Bliss not only focuses on styles (Bliss CSS) but offers fully functional and encapsulated components.
This process is ongoing, and you can find more about it on GitLab organization. Going forward we're going to make all new Bliss related work open source (sadly not Bliss CSS at this point).
PositionDesigner & Developer
- Design Systems
- UX & UI
- Front-end Engineering
- Product Management