Unifying the Bitwarden Design Language

Improving user satisfaction and internal design and development experience through establishing an atomic Design System and Component Library

Background

Bitwarden was using multiple UI frameworks to power their web based interfaces. Users faced an inconsistent–and often outdated–user experience depending on where they accessed Bitwarden.

Internally, processes were bloated and slow as each framework had to be considered by design and engineering when a UI change was made.

Screenshots from 2021 showing the desktop, web app, and extension interfaces all using a different UI framework

My role

Led design system advocacy by defining vision, gathering engineering support, and establishing a working group.

Led design work for establishing the Bitwarden design system, UX writing guidelines, and design usage guidelines.

Presented progress updates and case studies to stakeholders ensuring expectations were met and managed.

Established design team processes for introducing new UI patterns and components to the design system.

Collaborated with engineering and engineering management to gain leadership support for a dedicated design system team.

Supported engineering teams and contractors in migrating legacy code to the design system.

Business Goals

Create a recognizable experience
Unify the Bitwarden design language so users recognize the interface, have a more constant experience, and are more confident in Bitwarden as a product and company.

Expedite design and engineering
Abstract out the repetitive design decisions, so designers and engineers can focus on building the enhancements and features that make the product.

Gathering support

During interviews with engineers, I heard over and over a desire for a component library and hopes for design standardization to make their lives more efficient.

In interviews with product and leadership, I found there was a concern about the product UI and desire to improve it. I worked to show the company how a design system could improve the brand perception and the internal development processes.

Language used in a presentation to gain leadership support.

Diagram used in a presentation to gain leadership support.

Component Audit

I conducted a component audit in the web application – the most robust and well documented of the web frameworks in use. I found even in this single interface there were:

• Many style variants for each component

• Outdated styling and icons

• Inaccessible colors

• Form fields that lacked required indicators and error states

• Overuse of text callouts

I consolidated the different patterns and marked which design patterns should be integrated into the developer component library.

I made subtle design recommendations to make the components more consistent, accessible, and usable, but ultimately tried to keep patterns the same so that during migration to the new system users would not be disrupted but mis-matched UI.

Example of audit document for the button component.

Design tokens

From the component audit, I was able to identify design tokens currently in use. I documented:

• Color variables and usage

• Typography styles

• Border styles

• Borner radius

• Focus indicators

For color variables, I checked each color variable for WCAG AA compliant contrast and made subtle adjustments if needed. Then I worked with engineering to create a Tailwind theme–the engineering CSS framework chosen to style our new component library.

Initial design system components copying styles from the web application.

Building components

As I built components in Figma, the engineering team worked to build them in code so that they could use them within the product. The team leveraged Storybook and Chromatic, to ensure the implementations matched the Figma design specification.

I started with common patterns like buttons, form fields, and tables since these were used on almost every page of the web application.

Design documentation

For each component I built in Figma, I included design documentation which included:

• usage guidelines

• visual states for interactivity

• other configurable properties – such as size or style

• accessibility notes on visuals, screen reader behavior, and other best practices

I drew reference from other well established Design Systems as I worked, including: Polaris, Carbon, and USWDS, to name a few.

Later, I translated the documentation into markdown and opened PR's to include component documentation directly in Storybook. This allowed design and engineering to have 1 place for all things related to the Design System.

Screenshot from Figma showing button components in light and dark themes along with usage and accessibility guidance

Screenshot from Figma showing banner components in light and dark themes along with usage and accessibility guidance

Screenshot from Figma showing form components in light and dark themes along with usage and accessibility guidance

Screenshot from Figma showing dialog components in light and dark themes along with usage and accessibility guidance

Screenshot from Figma showing table components in light and dark themes along with usage and accessibility guidance

Migrating the web app

From early 2022 through mid 2024, the engineering teams worked to migrate the web app to the new design system’s component library when capacity allowed.

Any new features would be built using the new library, and any page redesigns would be seen as an opportunity for engineering to migrate that page to the new library.

The web app before and after being migrated to the Bitwarden Design System

Shared Recipes

One of the key items that helped leadership continue investing into the Design System and UI migrations, was a proof of concept I lead integrating the design system into a data Import form to leverage across web interfaces: the extension, web app, and the desktop electron app.

The POC ultimately showed a 30% increase in team efficiency and the benefit to users who could now expect the same experience across the 3 interfaces

Screenshot showing the import form used in the web app, desktop app, and extension

Migrating the extension

In 2024, I had made enough progress with the web app interface it was time to extend the design system’s benefits to the browser extension.

At the same time, the business prioritized a full extension redesign. This empowered the design team to move forward with component UI updates to modernize the interfaces further.

More about the extension redesign

The Bitwarden extension before and after the migration to the Design System

Design system redesign

The goal of the redesign was to bring in more branded elements and to modernize the existing components. With this in mind I made primarily design token level changes including:

• Color variables to include brand variables and lighter status shades

• Increasing border radiuses to provide a more friendly UI

• Font styles from Open Sans to the brand font DM Sans

• Light blue for micro interactions, such as hover states, to bring a more branded feel

• Nesting form field labels within the field border to improve visual grouping

Updated UI components using the new design tokens and styles.

Updated UI components shown on the web application.

Next steps: migrate desktop app

Throughout the project I set a vision to share the web app interface with the desktop application–this is a common pattern across the industry and would save designers and engineering teams time leveraging the same solution across two interfaces.

To gather support for this, I conducted user interviews on user expectations when it comes to using a web app and a desktop interface.

With this strategy in place, Bitwarden plans to migrate the desktop application next and plans to work toward unifying the two experiences.