Bliss Design System

A browser window is displaying the Bliss documentation website, showing the page for button components and their detailed design, code, and design token documentation.

Role

Design Systems Lead

Timeline

2019 — 2022

Team

Profile picture of Gabrielle von Koss Profile picture of Carolyn Stransky Profile picture of Kilian McMahon

Overview

Bliss is the design system that empowers the user experience at BRYTER. What started as a small initiative after I joined BRYTER in mid-2019 became a proper team by the end of 2020, with up to three full-time engineers working on it.

When I was kickstarting Bliss solo at the beginning, I focused on establishing a solid foundation around color, typography, spacing, and icons before branching out into components. In addition to a solid design token structure, I concentrated on providing Figma styles and components for designers, along with a lightweight CSS library for easier adoption by engineers.

With a proper team established at the end of 2020, we started moving the component library of Bliss to Web Components and standardizing and maturing more and more of our patterns and practices.

Screenshot showing Figma data table and list components in various states and variations.
Figma component we've used to construct UIs with lots of data that require tables.
Different sizes and styles of feedback-related components, such as banners or badges.
Various states and styles for our Figma form components.
Our own set of hand-drawn icons in the common

Documentation

From the start, documentation was a key pillar of how we approached Bliss. Design systems are at their core about creating a shared space of understanding, patterns, and tools, which makes documentation one of the most important pieces of this equation.

While we started very lean with zeroheight instances at first, we gradually transitioned to Storybook. While Storybook was initially focused on development, we decided to enhance it by incorporating additional written documentation. Step by step, we were able to identify and document more general patterns we needed to align on and added some guidelines.

Screenshot of the Bliss documentation homepage, showing a general overview of the documentation and quick links to certain areas.
Bliss documentation homepage with many quick links to the most common pages for designers and developers.
Each component had its own documentation page focusing on design and engineering documentation, as well as references to the used design tokens.
Screenshot of the Bliss Icon documentation with pattern guidelines on how and when to use the toggle component, along with specific examples.
Besides component-level documentation, we also provide more guidelines on patterns and when to use them.
Screenshot of the Bliss Icon documentation with detailed guidelines about how to draw new icons, including their sizes and proportions.
Detailed documentation about our approach and guidelines to drawing BRYTER style icons.

Collaboration

With increased adoption and general usage, support and collaboration requests from designers or engineers are becoming more frequent. We have implemented various methods to support and collaborate with consumers.

Support channel

The easiest way to approach our team and ask for support is the #bliss_support channel in Slack. In hindsight, this is also by far the most frequently used channel to get in touch and ask for guidance. One of the driving principles of our support channel has always been to respond quickly initially.

Proposal board

Design systems are a significant collaborative effort. Early on in our journey, we decided to create a proposal board to facilitate consumers in suggesting or requesting new components, improvements, or reporting bugs. This proposal board also served as a general overview of "what we are currently working on" for everyone interested.

To streamline the process of adding a new item to the proposal board, we included various issue templates with structures and examples to choose from.

Open Office Hours

We also offered biweekly office hours where stakeholders could join and discuss various problems or solutions with us. Office hours can be helpful when topics are not time-sensitive, but there is a general interest among one or more consumers in a question or topic.

Swap Days

We offered teams the opportunity to ask for support from us to replace their legacy code implementation with new Bliss Components. To successfully accomplish this, we created full-fledged merge requests containing the new Bliss Components that only required a review from the specific teams.

This method not only increased our overall adoption but also enhanced the understanding of Bliss Components across teams. Engineers still needed to review merge requests and learn various ways of using Bliss through these reviews.

Bliss Ambassadors

The product area of BRYTER operates in numerous cross-functional teams. All of these teams consume different parts of Bliss. In this setup, communication channels can lose their effectiveness from time to time. As everyone focuses on achieving their team's goals, it can be challenging to provide feedback or respond to requests for feedback from other teams.

We noticed the gradual decline in our communication channel's effectiveness and realized the need to adopt a new approach to ensure equal information dissemination among all units.

This is where the idea of Bliss Ambassadors comes into play. We created a forum for people to become Bliss Ambassadors for their teams. This meant that we had a direct contact person in every team whom we could talk to, without running into the "talking into the void" problem.

We also started organizing fortnightly Bliss Ambassador Syncs, where every ambassador joins a 30-minute call. During this call, ambassadors receive the latest updates from the Bliss team and have the opportunity to share the most recent feedback or struggles from their unit.