Bliss Design System v1.xThe continuation of the internal design system for BRYTER.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- Product Management
- Front-end Engineering