BRIGHTSIDE BENEFITS

DESIGN SYSTEM

Overview

I was tasked by Brightside’s CEO to refresh our platform look-and-feel and consolidate our products into a cohesive platform with a unified experience. Before getting started, I gathered our product, design and engineering leads to discuss the scope of such a project. There, I uncovered a few roadblocks:

  • Each product was built independently by different teams creating an inconsistent user experience.

  • Our front-end components were not standardized and code was not reused or shared across products.

  • We lacked a unified design system that allowed design assets to be shared across teams.

  • We lacked processes to coordinate efforts between teams.

  • We accumulated lots technical debt that resulted in considerable amount of bugs and decreased development cycles speed.

    • Avg. 100 front-end bugs per sprint

    • Avg. 12 stories not completed per sprint

Goals

Once I had a clear understanding of the underlying problems, I set out to define an action plan. I started by organizing a task force of product and engineering leads for each product to define the initiative objectives. We agreed on 4 initiative goals:

  • Design a new global navigation

  • Refresh the UI look-and-feel

  • Build a modular design system

  • Unify our front-end codebase

System Colors and Typography

We then proceed to create a naming convention that could be used across products and codebases. This created a shared language between teams that facilitated collaboration and coordination.

Prior to the start, I lead the design sprint to lay the foundation of the design system. We created a style guide to loosely defined our typography, colors, icons, and spacing. This foundation proved essential for guiding our work in a unified direction while allowing room for individual exploration and course-correction

Styleguide.png
 

Design Templates and Layouts

While creating these components, we collected them in a master file, which we referred to throughout the design process. After a while, we began to see huge leaps in productivity by using the library when iterating on designs.

For efficiency, we reviewed the progress at the end of each day, to course-corrected when necessary, and share learnings. Also, I ran weekly documentation marathons to allow designers to document specs and organized their files.

 
 

Implementation phase

While the design team re-designed the experience, the engineering team would focus on untangling the codebase. Firstly, the team laid the foundation by tokenizing the system primitives and introducing them to the existing codebase. This allowed for consistency and streamlined changes.

Then, the team set to centralize the components in a shared repository to enable any engineer to commit changes or use existing components. Through this process, all components with duplicated use cases were removed.

Once the components codebase was unified and the re-design was complete, a laborious refactoring process started where the team replaced each component with its system counterpart across all products. To complete the transformation, the new login experience and global navigation were introduced to consolidate experience.

Spending Account (DDA)

Overview

Brightside aims to create a “smart wallet” experience for the underbanked, giving them access to a spending account where they can monitor spending and have Brightside’s Financial Assistants (FA’s), access to each of their clients spending. This would in turn help align the client and their personal FA on where the client can budget better, give them insight on their spending and get them on track to accomplishing all their financial goals. This is why we have built out the Brightside Spending Account which is displayed below.

Having started from scratch, no company branding was involved, so a bare bones architecture was designed focused on functionality for the V1.

 

Before building designing out the architecture of the spending account, I wanted to gather the product leaders and conduct an app audit and ultimately construct a user journey to give us a sense of direction for all future products. This app audit also allowed us to break up into squads at Brightside, partitioning out the products while still being able to have visibility across other teams.

 

These designs were the first hack at the Spending account, taking our initial wireframes and updating them with the style guide that I designed to create consistency across the app. Everything from signing up for the spending account all the way to contesting charges on their account.

 

We gave each of our clients a physical Brightside debit card to link to their Brightside Spending account so they can use it like you would use any debit card. The advantage of this as opposed to having our clients use their personal bank’s debit card, is that these transactions will be fully transparent with their own FA. Above are the hero screens for the card activation flow once they receive their card in the mail.

 
Funding 2.png

Once our clients have set up their spending account, we give them the option to fund their account via paycheck deductions or ACH funding from their 3rd party bank

 
Transfers.png

Once our users have funded their account, we give them the ability to transfer funds between their spending account, savings account and via ACH external 3rd party bank.

Waitlist - Campaigns

Certain features and functionalities in the Brightside App needed to be tested with our power users. Things like interest and demand by our clients were instrumental in the decision making process as to which features should be released to all users and whether we needed to pivot from features that were in the pipeline.

The Brightside leadership team and I decided to implement a “Waitlist” page for all future products we planned on including in the app. We would use the same template as the “campaign” pages to maintain consistency throughout the app and would cascade across all platforms.

Waitlist.png

Banner Notifications

A major obstacle we faced with the Brightside app was how we would approach notifications throughout the app. There are several types of notifications and in the past, the approach was chaotic and unorganized. We found ourselves with several different, inconsistent notification types. I decided to simplify the structure of our banners into one component that was dynamic.

I broke down our notifications in the following way:

  • Navigational: Any banner that required an action that would navigate the user to a subsequent screen, they would see a banner with a chevron the right side. This could apply to normal or error banners.

  • Dismissible: Banners alerts that don’t require immediate action or attention would have an “X” affordance at the end of the banner

  • Non-dismissible: Banners that require action or are “Priority 0” would be constantly displayed on screen until the action has been completed. Whether this is information requiring 3rd party bank action or something similar. No affordance is given at the end of this banner.