Creating an Enterprise Design System for Finance of America Companies.
🗓️ When: October 2022 – Current
👨💻 Role: Design Lead – Primary contributor, author, and approver of the design system. Managed the development of the design system and helped establish the production pipeline with lead engineers.
Opportunity
Finance of America (FOA) owns several companies that have their own unique brand and visual product language:
Finance of America Mortgage (FAM)
Finance of America Reverse (FAR)
Finance of America Home Improvement (FAHI)
The executive leadership team created an initiative to unify the customer experience between FOA’s companies. With executive sponsorship behind the design team, the VP of Product Design nominated me to lead the creation of a design system. The design system aimed to be an enterprise resource to unify the visual language of all future product development and marketing sites for FOA companies.
Table of Contents
🧱 FOUNDATIONS
Customers
Accessibility
Principles
Brand
🪙 TOKENS
Colors
Spacing
Typography
Elevations
Grids
🔘 COMPONENTS
Buttons
Float-label fields
Mo re components…
Common attributes
🎼 NAME & LOGO
Name
Logo
➡️ PIPELINE
Development process
🙌 OUTCOME
Release date
4 months later
🧱 FOUNDATIONS
Customers
I refreshed myself with the personas and journey maps of our customers and partners who would be experiencing the outcome of the design system. Below is a persona and journey map I created for the home improvement financing customer.
Accessibility
I referenced the Web Content Accessibility Guidelines (WCAG) 2.1 and targeted the AA level of conformance. I ensured that all typography and UI elements met or exceeded the required contrast ratios:
• 4.5:1 for ‘normal’ text (below 18pt)
• 3:1 for ‘large’ text (18pt or greater)
• 3:1 for components and graphics
I created a login template for various tests. Here you can see that all UI elements exceed the AA level success criterion for contrast. I utilized the Stark plugin to test color contrast ratios for type and graphics within the working Figma file.
Principles
I wrote a few design principles that have proven valuable to me in past work. Each principle helps to explain my rational for the thousands of micro design decisions I’ve made while creating the design system. These principles are intended to evolve with the design system and can be used as a tool to measure, evaluate, and drive design decisions with a shared language and vision.
Brand
I discovered that Finance of America Reverse had the most updated styling of all of FOA’s companies. I extracted the colors, main typeface, and iconography from the Reverse business’s brand to help lay the foundation for the design system. I presented this concept to marketing leadership and gained approval for using these elements.
🪙 TOKENS
Color
Most of the brand colors (aside from the dark blue Denim color) are too light to be used in components and typography. They don’t provide enough contrast when on a light background.
To resolve this, I used a palette generator to create shades and tints of each brand color. This allowed me to expand the brand theme and create darker and lighter color variants. Dark color variants provided accessible options for typography and components. Lighter color variants became useful for subtle UI elements like divider lines, and light backgrounds. Having a palette for each brand color also provided a range of on-brand colors for creating graphics and illustrations. However, even with brand color palettes, a few color gaps remained.
I had a need for new feedback color palettes – yellow for warnings and red to denote danger. Additionally, a palette for main interactive elements (eg: CTA’s, links, tabs, etc.) that had better contrast and saturation than the brand colors. Also, I needed a more balanced range of gray colors for components (borders and fills) and typography treatments.
Lastly, I added a single unique bright-blue color to be used solely as a universal focus state across components.
Typography
I created a type scale that provides a clear visual hierarchy for content-heavy marketing sites as well as interaction-based web products.
Having worked on the home improvement product suite for more than 7 years, I was able to reuse many of the header and paragraph styles I had previously developed. However, to accommodate large marketing layouts I added three display styles.
I created sample layouts to test the scale between titles, subtitles, and body copy. I check the line-height of each text style at varying widths to find a line-height ratio that was easily legible for each text group (display styles, header styles, and paragraph styles).
Font scaling
I met with front-end engineering leads from marketing and product to better understand how type was currently being set and scaled in those domains. I learned that product was reducing fonts at smaller breakpoints, while marketing was using responsive font scaling (RFS). An agreement was reached to support RFS for type above 20pt. This allowed fonts to scale more granularly between viewport widths between 1200px to 360px. However, this created a design issue.
How do I represent scaled text styles per viewport?
To resolve this, I asked engineering to created an html test page for me to see how the text styles above 20pt would scale with RFS. I adjusted the browser width to common viewport sizes and used WhatFont and Fonts Ninja plugins to inspect the scaled font-size and line-height per text style. I then created variant text styles for each viewport based on my findings – desktop (L), tablet (M), and phone (S). The addition of device-specific styles ensured that designers could accurately represent RFS in layouts and that designs would match development outcomes.
Spacing
For spacing between UI elements, padding, and margins we use spacing units that are mainly multiples of 8px. However, sometimes there is a need for tighter spacing below 8px in which case we’ll use an even number (i.e., 2px, 4px, 6px). Spacing units are calculated in rem. The root em is set to 16px.
Elevations
I created four elevation levels to use within the UI to simulate depth. The elevations follow a few general rules that create a consistent visual look, hierarchy, and allow us to expand this section further in a logical way if needed in the future.
Consistent light-source position - The x axis is always 0. The y axis changes at a rate of 2px from one elevation to the next.
The greater the elevation the greater the shadow blur - The blur changes at a rate of 4px from one elevation to the next. The spread is always 0.
Shadow value - The alpha channel of the shadow color changes at a rate of 4% from one elevation to the next. The shadow value increases with the depth so that elements with a higher elevation stand out from elements with a lesser depth.
The device below shows each elevation level in use.
Grids
I discussed grid options with lead engineers from product and marketing. We landed on using Bootstrap’s v5.3 grid system. It comes with six default breakpoints, and has the ability to be customized. This seemed like a flexible system that could accommodate our needs. I created grid styles in Figma for each of Bootstrap’s breakpoints (xs, sm, md, lg, xl, xxl) as well as sample layouts per breakpoint.
🔘 COMPONENTS
Buttons
Buttons were the first component I made for the design system. Calls to action are very important because the user must be able to use them, they also set a tone for the design language, require good contrast, need clear hierarchy in groups, can be nested in compound-components (i.e., modals, search inputs, etc.) and are used very frequently.
Contrast Compliance
Each button meets or exceeds a level AA standard contrast ratio as set by the Web Content Accessibility Guidelines.
Minimum contrast ratios:
4.5:1 - Label and background colors
3:1 - Component and background colors
Button label contrast
Button component contrast
Focus indicator contrast
Button component controls
Each button component (Primary, Secondary, Tertiary) has convenient controls that give designers the ability to quickly adjust the size, color, state, icon position and label.
Button animation
I animated the button states to stress-test the interactions of each button type and to make the component ready for prototyping.
Button base component
This base component is designed to nest inside all of the primary, secondary, and tertiary button variants – 1,680 variants in total. By nesting the base component inside each button variant, I’m able to control all of the common attributes of each button via the base component (i.e., label styling, icon styling, spacing, padding, corner radius, etc.).
I also created a base component for the focus state to have a master control for this universal outline that pairs with buttons and other components.
Primary button component
The pop-out section of the primary button component below, shows the different variants needed for a single button size. I duplicated this group to create different button sizes and changed the nested base component accordingly. Once I had all of the button sizes created, I duplicated the entire color set (i.e., Interactive Blue) to make a new color set (i.e., Denim) and so on.
Secondary button component
Tertiary button component
Float-label Fields
Creating accessible and easy-to-read inputs with flexible variants for error handling and known use cases.
Checking contrast compliance
Each part of the field component meets or exceeds a level AA standard contrast ratio as set by the Web Content Accessibility Guidelines.
Minimum contrast ratios:
4.5:1 - Type and background color
3:1 - Component and background colors
Field component controls
This component has been painstakingly crafted to allow for quick toggling and easy size and state changes. Designers are just a toggle away from an error state, disabled state, show link, hide link, character start, or character counter no matter what size or state the component is set to.
More components…
🎼 NAME & LOGO
Naming the design system
The VP of Design requested a name for the design system. Designers, engineers, product owners, and marketing folks added name ideas to a shared list. After a week, we got 18 names. We ran poll to determine the top three names and again to pick a winning name. To my surprise, my name contribution was selected as the winner - Symphony!
Symphony
A symphony is an elaborate musical composition for a full orchestra. Like the design system itself, when broken down a symphony has rudiments - the basics of musical theory like the beat of a drum (tokens), notes - which represent musical sound with pitch and duration (components and interactions), and movements - individual parts of a symphony that tell a story (layouts/templates).
Design, Product, and Technology teams are the orchestra, working in concert with the design system to create better rhythm, harmony, and composition at scale for our digital suite of products and services.
A well-played symphony can create a powerful lasting experience for the audience. It can invoke emotions and prompt action.
Creating a logo for Symphony
Below are four logo samples I created for Symphony. Each logo is comprised of three parts. Each part represents a layer of the digital product: user interface, design system, and back-end.
The design team voted and #2 won!
Symphony logo
➡️ PIPELINE
Development process
How did we go from designed components to “real” coded components that are packaged and ready for distribution? Figma → Jira → Storybook → NPM
STEP 1 OF 4
Figma library file
Once I completed a component (variants created, prototyped, and stress tested), then I presented it to the design group at a weekly critique meeting. If the component was deemed ‘ready for dev’ by the group, then I presented it at a weekly design system meeting. This meeting gave our core team with lead developers a chance to review the component in detail. If the core team approved the component, then I created a Jira story for the development work.
STEP 2 OF 4
Jira stories
I created component stories in Gherkin with links to Figma components.
Kanban board
I helped prioritize component stories on the Design System Kanban board. We created 6 columns on the board - from To Do to Done with the In Testing column as a dedicated step for design QA.
STEP 3 OF 4
Storybook development
We used Storybook to build and test components in isolation. Storybook also became home to our component documentation.
STEP 4 OF 4
NPM
Once all of the component stories were in the Done column on the Kanban board, our devs published a new design system package.
🙌 OUTCOME
— Symphony Design System v1.0 released on March 10th, 2023 —
4 months later, we had 6 implementations! 🚀
1 of 6
FinanceofAmerica.com
Sample content block
🔍 Design-system lens
2 of 6
FoAHomeImprovement.com
Sample modal
🔍 Design-system lens
3 of 6
Borrower Privacy Preferences (Internal form)
Sample section
🔍 Design-system lens
4 of 6
HECM Management (internal)
🔍 Design-system lens
5 of 6
Broker Log in
Multi-factor verification (SMS)
🔍 Design-system lens
6 of 6
Broker loan pipeline
🔍 Design-system lens
Symphony is now being used by all product designers and product teams at Finance of America.