Bliss Design System v1.x

The continuation of the internal design system for BRYTER.
Screenshot from the overview page of the Bliss docs.

Overview

After the first take on the Bliss Design System and the mentioned priority shift during mid-2020, we continued work on Bliss in November 2020. With a small new team of three (two frontend engineers plus me), we began taking inventory of the current state of Bliss and started planning the future.

With the goal of moving the component library of Bliss to a JavaScript-based foundation, we quickly moved ahead in building an early proof of concept and shipped the first toolkit for Bliss Icons to our consumers.

Coupled with numerous feedback session with stakeholders across engineering, design and product management, we landed on moving forward and build our new JavaScript-based components as Web Components. Furthermore, we also decided to make all the development work open-source, which you can find on GitLab.

As this is still an ongoing project, I will only focus on some areas we've worked on during 2021 and what we've learned from it:

Rebuilding components and improving accessibility

With a one and a half year history of Bliss v0.x, we approached our move to Web Components with a reconsideration of our current design decisions for each component. Every component we migrate to Web Components went under a detailed rethink and usage analyses. All this happened together with the design team and numerous feedback and design critique sessions.

Besides some visual adjustments, our primary focus was on improving the accessibility of each component. One of the most significant changes we introduced during our early development efforts was the alignment of the visual appearance of the focus ring.

Screenshot from Figma showing checkbox components variants structure.
The checkbox components and how it is structured inside our Figma library.
Screenshot from Figma showing toggle components variants structure.
The toggle components and how it is structured inside our Figma library.

To make usage and communication between designers and engineers more straightforward, we also leveraged the power of Figma to add additional information to the Figma components individually. With this information, consumers not only were able to get to the component documentation via a click of a button, they also were able to see the current availability of individual components and potential gotchas directly inside Figma.

Rebuilding our documentation

With a new technical approach, revisited components and better accessibility support, we had to find a reasonable solution on how to approach documentation for the new generation of Bliss. As we used Storybook mostly for focused development in the beginning, we decided to take it one step further and also incorporate more written documentation inside it.

Our goals with rebuilding the documentation page was not only to be more flexible in comparison to our first version, hosted on zeroheight. We also wanted to establish one place where consumers could find everything they needed. For every new Web Components implementation, we declared the documentation and resources on zeroheight as legacy and moved all new documentation details over to Storybook.

Screenshot from the Bliss legacy documentation page, showing deprecation warnings.
We added deprecation warnings to all the documentation pages that were focused on legacy components, we now had a Web Component alternative for.

Besides that, we also extended our general documentation offering, which initially was mostly focused on components. Step by step, we were able to identify and document more and more general patterns we needed to align on and added some guidelines.

Screenshot from the Bliss pattern documentation, showing guidelines around the usage of toggles.
Pattern guidelines around the usage of toggles.

Support and collaboration

With more adoption and general usage, support and collaboration requests from designers or engineers happen more and more. I think, this should be seen as a good thing, as adoption and usage are great indicators for relevance. Furthermore, every support or collaboration request is a chance to make a consumer happy and educate them for the next time they run into a similar problem. We established different ways to support and collaborate with consumers.

Support channel

Probably 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 our driving principles of our support channel was always being fast in the initial response, while being thorough around the solution.

Proposal board

Design systems are a big collaboration effort. Early on in our journey, we decided to create a proposal board to make it easy for consumers to suggest or request new components, improvement, or report bugs. This proposal board also served as a general “what are we currently working on” overview for everybody who was interested. To make the whole experience about adding a new item to the proposal board a breeze, we added multiple different issue templates including structure and examples to choose from.

Open Office Hours

We also offered fortnightly office hours where stakeholders could join and discuss different problems or solution with us. Office hours can help when topics aren't time sensitive but a general interest around a question or topic is present for one or some consumers.

Swap Days

One experimental addition to our list of different collaboration methods were Swap Days. We offered teams to do their work in swapping legacy code implementation with new Bliss Components. To successfully accomplish this, we created full-fledged merge requests with new Bliss Components that only needed a review from the specific teams. This method not only incremented our overall adoption, but also increased the understanding of Bliss Components across teams, as engineers still needed to review merge requests and learned different ways of using Bliss through review.

Bliss Ambassadors

The product area of BRYTER operates in numerous cross-functional teams, called “Units”. All of these units consume Bliss, or different parts of Bliss, regularly. In these kinds of setups, with a fast growth in new joiners, communication channels can lose their power from time to time. As everybody focuses on achieving the goals of their units, it is sometimes difficult to give feedback or react to us requesting feedback from different teams.

We felt the slow and steady decline of our communication channel and needed to take a different approach to inform units on an equal level.

This is where the idea of Bliss Ambassadors comes into play. We created a forum for people to become Bliss Ambassadors for their unit. This meant that we had a direct contact person in every unit we could talk to, without running into the “talking into the void” problem. We also started to organize fortnightly Bliss Ambassador Syncs, where every ambassador joins a 30-minute call. In this call, ambassadors get the hottest updates from the Bliss team and have space to share the latest struggles of feedback from their unit.

What I've learned

Communication and documentation are the two primary cornerstones of a successful design system. We tried to over-communicate and open up more and more different kind of communication channels, so information could easily reach others. While it sometimes feels like being too much, there is no such things as over-communication.

During 2021, I've come to realize many similar things that Lauren LoPrete talked about so thoughtfully during her Design Systems Burnout talk at Clarity 2021. Working on design systems is a long game! It also can sometimes feel like a thankless job. This should by no means feel like a negative realization, but a realistic one.

As design systems teams, we can only do so much. Keeping communication flowing, building trustful relationships with consumers and stakeholders, and setting clear boundaries and expectations are the most important pieces. Everything else, like technical implementations or visual changes, come only after that.

Special mention and thanks to Gabrielle von Koss, Carolyn Stransky and Kilian McMahon for working with me on Bliss during 2021.

Position Design System Lead
Company BRYTER
Year 2021
Responsibilities
  • Design
  • Documentation
  • Product Management
  • Front-end Engineering