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 h1, h2, h3, h4, h5, h6 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.
