SureUI Design System
Building a white-label design system to help life insurance brands using a common design language.
Worked as design lead on the project, lead workshops to introduce design team to new concepts, oversaw implementation, and guided designers to make their own contributions with new components. Communicated with development through the realization of the project and translating the component library into a Storybook document.
3 Product Designers
3 Software Engineers
1 UX Researcher
Building the case for a design system
On the outset, Sureify lacked a singular design system across the multiple brands and products it was supporting. Inconsistencies in the implementation were glossed over, and there was a lack of a single source of truth for the components we were using. Initially, this was seen as a non-issue, as many of our clients were describing our design as “best in the business” at the time.
As our product offering and teams grew, however, the inconsistencies between our products, our designs, and their implementation became a real issue for end users, and therefore a problem for carriers. This led to efforts within the org to start a design system.
- We had multiple cases of clients reporting visual, accessibility, and usability bugs, which were difficult to track down and fix.
- Similar components, or even flows that could be used across multiple products, were built to be single-use.
- Turnaround time was slow, due to having to build things from scratch.
- Communication was difficult, because of differing guidelines, terminology, and components.
We desperately needed a shared language between design and development teams.
Plotting out a comprehensive design system
Sitting down with the design team, we eventually got to a nice list of goals for our design system.
- Create comprehensive design tokens and Figma components that would be in sync with their React counterparts.
- Address issues in implementation and ensure consistency across designs.
- Make the system accessible, easily customizable, and compliant with WCAG 2.1 standards.
- Allow the design system to work on top of white-labeled products and be replaced with branded versions with ease.
- Track similar design patterns and components across our products.
The design and development teams agreed on using the MUI framework. I built a Figma component library with specified tokens and included a changelog to communicate necessary changes to the base MUI components for alignment with our design system.
We organized workshops and 1:1s to align everyone on Figma components and their usage. We devised acceptable "hacks" for purpose-built components, easing the development team's burden. The design team was receptive, enabling effective synchronization.
Organization and additional libraries
To help organize our design system, we also created a pattern library in which bigger elements such as screen templates or design patterns would live. Additionally, we created a data visualization library that included a vast array of customizable charts based on the Nivo React library.
While the team was transitioning from Sketch to Figma, I set up a "helper" library with annotations and page covers to establish structure and organization for our new Figma file system.
Scaling and customization — A design system for every carrier
To ensure that we could easily customize our design system for every life insurance carrier, we developed a workflow in which we could maintain and version control client-specific, branded versions of our design system for every brand. While before, this would entail a designer sitting down and essentially recreating the whole design, the same could now be performed with a simple asset swap.
Here’s the gist of the process:
- The white-labeled SureUI file contains all the base default tokens — colors, icons, typography, border radii, logos.
- When approaching a new brand, we add a new branch to the SureUI file, so that any base updates would trickle down later.
- All brand-specific customizations to tokens or components are made within the file branch.
- Regularly, branches are exported to immutable, versioned files.
- Any white-labeled design files can then be easily branded with a simple library swap for demo, testing purposes, or simply to give the developers a clearer view of all the available tokens.
- Every version of the design system (both base white-labeled, and branded) have their own changelog, which documents any necessary file-specific information.
Things didn’t just work from day one — like everything, the design system and component libraries required refinements, further discussions, and iterations. Eventually, though, through a series of workshops and lots of communication, we were able to create a system that worked well for our team, and which has continued to evolve and improve over time.
A next step that we’re looking into is other platform implementations. Since our products were mostly web-based at the time, most of the focus went into finding a web-based solution. However, with time, the need to branch out the design system became obvious when the same inconsistencies started popping up on iOS, and Android. These implementations, however, will be a part of another case study.
Increased visibility and reduced miscommunication
Documentation, guidelines, design tokens were made visible to everyone. A Storybook library was established to make it easy for everyone to access and use the design system. Miscommunication, a common problem in the past, was reduced. The gap between designs and implementations was minimized.
Improved turnaround times and cleaner designs
The design system led to visible improvements in both our design consistency and processes. Overlapping parts of our products were now more easily reused, which lead to faster turnaround times. White-labeled flows were branded in an instant, thanks to our new processes. New features had a much faster time to market
Positive reception by the organization and carriers alike
These effects were quickly noticed and got an immense reaction from our clients and the organization as a whole. Stakeholders appreciated the improved efficiency, consistency, and user experience brought about by the design system. The product teams felt they could focus more on innovation and problem-solving, rather than reimplementing common elements and flows.