Select Page

Designing a system for scalable applications

Blackboard Insurance is reimagining the entire commercial insurance experience with a customer-centric, technology-forward and data-driven approach. Turning the insurance industry on its head requires solving big, business and technical problems with creativity and curiosity. The core of Blackboard’s offering is to build technologically strong and innovative platforms that handle everything from underwriting, claims, broker portfolios, analytics dashboard, and more.    

Role: Product designer

I was the responsible Product Designer to establish a scalable design system and component library that would be used across multiple Blackboard applications. I was in charge of designing the design elements, collaborating with engineers to implement and systematize the components in Storybook and then testing them out in their respective applications. The objective was to establish a component library approach that was scalable and thus this led to an atomic design approach with considerations to atoms, molecules, organisms and templates. 

Company

Blackboard Insurance

Year

2019

Role

Product Designer

Responsibilities

Atomic Design
Material Design
Design from early sketching to high-fidelity prototype

The challenge

When Blackboard first was established in late 2017, the software platforms were built  without much consideration to scalability or sustainability. This in return meant that after about a year in, the software platforms experienced major regressions, inconsistencies and lack of scalability. It was clear that we needed to take some steps to make the applications scalable. On the design team, we had already established a robust design system inspired from Google’s Material Design. This design system was shared among the designers (using Abstract), but we needed to extend this system out to include the implemented components as well. 

ATOMIC DESIGN

Atomic design suggests a process of starting with the atoms, then molecules, organisms, templates and pages.  

Understanding the anatomy of our apps 

In order to get started, we needed to understand the anatomy of our apps by conducting an interface audit. This was to understand what component were used the most so that we could build the most useful library. We decided to go through our apps and take of note of the elements that would benefit from being systematized. The following were the patterns and components we wanted to establish.

Colors

All unique colors in our applications. This would be the theme.

Headings

All h1h2h3h4h5h6 and variations of typographic headings.

Global elements

Components like headers, footers, and other global elements that were shared across the different apps.

Navigation

Primary navigation, footer navigation, pagination, and interactive component controls.

icons

All icons used in other components, by themselves, together, and every other interface icon.

Forms

Input fields, text areas, select menus, checkboxes, switches, radio buttons, sliders, and other forms of user input.

Buttons

All the unique button patterns: primary, secondary, big, small, disabled, active, loading, and even buttons that look like text links.

Interactive components

Accordions, tabs, and other functional modules with moving parts.

 

The PROCESS

After investigating the components needed for the library, we started building out the components. This process was intended to be super iterative to allow for close collaboration between the design and engineering team. The idea was to design a few components at a time, and then start building them out to test in Storybook. This was to ensure a healthy loop between design and development, where the front-end code would become more solid and stable with each iterative loop.  

The Process

The process was designed to allow for nimble iteration by getting elements built quickly, so they could be tested and iterated on. 

STARTING WITH THE ATOMS

We started building out the foundational building blocks that comprised all our applications. These atoms included basic HTML elements like form labels, inputs, buttons, and others that could not really be broken down any further without ceasing to be functional.

… Then the molecules

According to Brad Frost, molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule. For us, this included modals, filters, search fields, etc.