Bliss Design System v1.x

After the first iteration of the Bliss Design System and the priority shift at BRYTER during the beginning of 2020 (BRYTER - Services), I continued working on Bliss late 2020. With a new team of three (two front-end engineers and myself), we took inventory of the current state of Bliss and started planning for the future.

Our goal was to move the component library of Bliss to a JavaScript-based foundation. We also conducted numerous feedback sessions with stakeholders across engineering, design, and product management, and to incorporate as much feedback and usage insights into the revamp of Bliss.

Components

We approached the move to our new Web Components by reconsidering our design decisions for each component. This involved a detailed analysis of each component’s usage and design in collaboration with the design team and through numerous critique sessions.

Our focus was on improving accessibility, and we made significant changes to components such as aligning the visual appearance of the focus ring across all components.

We also used Figma to add information to individual components, making usage and communication between designers and engineers easier. Consumers could access component documentation and see current availability and potential issues directly in Figma.

Documentation

We revamped the Bliss documentation page to better support our new generation of components. Instead of relying solely on Storybook for development, we also incorporated more written documentation. This allowed us to create a flexible, all-in-one platform where consumers could find everything they needed.

We declared legacy documentation on zeroheight for previous Web Components and shifted all new details to Storybook. Additionally, we expanded our documentation to cover general patterns and guidelines beyond just components.

Support & collaboration

As adoption increases, so do support and collaboration requests from designers and engineers. This is a positive indicator of relevance and provides opportunities to make consumers happy and educate them. We offer various ways to support and collaborate with consumers.

Support channel

One of the most frequently used and efficient ways to reach out to our team for support is through the #bliss_support channel in Slack. Our team values prompt initial responses and thorough solutions, making this channel a reliable and effective resource for guidance.

Proposal board

Design systems require extensive collaboration. We created a proposal board for consumers to suggest new components, request improvements, or report bugs. This board also provided an overview of ongoing work. To simplify the process of adding items, we added issue templates with clear structure and examples to choose from.

Open Office Hours

We also offered bi-weekly office hours where stakeholders could join and discuss different problems or solutions with us. Office hours can help when topics aren’t time-sensitive, but there is a general interest around a question or topic for one or more consumers.

Swap Days

One experimental addition to our list of different collaboration methods was Swap Days. Swap Days allowed teams to exchange legacy code for new Bliss Components with a click of a button. We created merge requests with new Bliss Components that teams could review before implementation. This approach increased overall adoption and improved teams’ understanding of Bliss.

Bliss Ambassadors

BRYTER’s product area comprises cross-functional teams, known as “Units,” that rely on Bliss regularly. With rapid growth and new joiners, communication channels can weaken. To address this, we created Bliss Ambassadors in each unit, providing a direct contact to the Bliss team. We also organize fortnightly Bliss Ambassador Syncs to share updates and discuss feedback struggles.

What I’ve learned

Communication and documentation are the most essential components of a successful design system. Our team believes in over-communicating and utilizing various communication channels to ensure information is readily available and accessible to all stakeholders. We have found that there is no such thing as too much communication, as it fosters transparency and trust.

In 2021, I came to appreciate the sentiment expressed by Lauren LoPrete in her Design Systems Burnout talk at Clarity 2021. Design system work is a long-term effort that can sometimes feel like a thankless job. However, it is essential to maintain realistic expectations and continue building relationships with stakeholders and users.

As a Design Systems Team, we prioritize communication, trust-building, and clearly defining expectations and boundaries; technical implementations and visual changes are secondary to these foundational pieces.

I would like to express my gratitude to Gabrielle von Koss, Carolyn Stransky, and Kilian McMahon for their contributions to Bliss and being a great team.