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: senior Product designer

I was the responsible Product Designer to lead and 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.js 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. 

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. 

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.

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.  

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  filters, search fields, etc. The idea was that molecules should be made up of smaller atomic components already built.

… Then the organisms

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. The idea was that molecules should be made up of smaller atomic components already built.

TO BE CONTINUED

This page is a work in progress. I will update it whenever anything changes. In the meantime, I would love to tell you more about how I went about designing the system.