Bliss Design System v0.x

When I joined BRYTER in July 2019, one of my initial focus areas was creating an internal design system. At the time, BRYTER as a company was young but growing rapidly. Building a system that supported the team’s speed and consolidated design decisions was an exciting challenge.

In seven months, we laid the groundwork for designers and developers to consolidate their work and improve alignment and consistency. Designers use Figma components and guidelines, while our Bliss CSS library helps developers work faster and more consistently, fostering better collaboration between them.

Foundations

During my first weeks at BRYTER, we started drafting an RFC to create our design system and moderated discussions with various teams to gain a broader understanding of different viewpoints.

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 being fast in terms of our implementation time.

Furthermore, it also provided fast feedback cycles, which is crucial when developing something new and wanting as much buy-in as possible.

Atomic mindset

At Bliss’ inception, we prioritized making small yet impactful decisions that would shape the overall product design. We understood that it was essential to establish atomic design principles before moving on to individual components like buttons, tabs, and form elements.

We identified these areas as the core building blocks of any interface and focused on redefining our color system first. As we worked on defining our color system, we realized the need for a more systematic approach to guide our decisions, particularly around accessibility and color contrast.

After defining the color system for designers using Figma Styles, we needed to make it available for our developers to quickly implement the new colors in real-life examples.

Design Tokens

To bridge the gap between design and development, we introduced Design Tokens as a toolkit for managing atomic design decisions, such as colors, and began using a tool called Style Dictionary to implement and manage them. We then extracted color values from Style Dictionary and released an initial version of Bliss CSS, a CSS library that developers could use to incorporate Bliss visuals into the codebase.

After releasing all the color tokens, we replaced old color styles with new ones using Bliss CSS as Design Tokens throughout different areas of the BRYTER product.

We repeated this approach for typography and spacing, designing everything inside Figma, bridging the gap between design and development with Design Tokens, and offering finalized styles to developers with Bliss CSS. This approach had two main positive effects:

1. It allowed designers and developers to align the design language more closely, as color names, typography styles, and spacing all had the same naming structure.
2. By actively replacing existing code with new Bliss CSS Design Tokens, developers saw the positive impact of using Bliss directly and were more willing to try it out themselves.

Components

Design Tokens help designers and developers, but components are where the big gains are. Aligning different approaches to surface a general solution was a challenge during development. We started each component creation process with an interface inventory, and good prioritization was key to maintain a consistent release flow.

During my time working on Bliss, this was probably the most “heads-down and productive” 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 collaborative effort, and I couldn’t have done it without the help and guidance of all the people involved.

Documentation

In late 2019, as we continued to release new Bliss CSS components, documentation became a challenge. Notion, which we initially used for basic guidelines and decision-making, was insufficient for detailed documentation of a design system. With limited resources and time, we opted for zeroheight, a unified platform where anyone could access comprehensive documentation, including designers, developers, and product managers.

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.

General

This section contains comprehensive information about a component, including its variants, usage instructions, content type compatibility, and accessibility guidelines. It serves as a go-to resource for anyone who wants to understand all aspects of the component.

Code

The Code section of the component documentation was developer-focused, with real-time code examples showcasing semantic suggestions for using Bliss CSS classes to achieve specific results, and including best practices for accessibility.

Tokens

The token section was a straightforward documentation of all the specific design tokens that were scoped to an individual component level.

Maintenance mode

In the first seven months, we made significant progress on Bliss. However, due to shifting priorities in a fast-growing company, I moved to another team. As the only core member of the design system team, we had to move Bliss into temporary maintenance mode, with limited resources for bug fixes only.

Despite this, our foundations in Figma and Bliss CSS supported designers and developers effectively in their daily work. Going technology-agnostic with CSS also proved beneficial during this pause, keeping things simple, flexible, and adjustable.