👈 Home

Building a new mobile-focused design system that scales to support all user interfaces across React, iOS, and Android platforms.

Product Designer, Design Systems
As the second designer to come in and support design systems, my focus gradually grew from designing new components and assets to include the creation of design tokens, creating a11y standards, and adding clear information architecture to our design system; all while working closely with lead feature designers and engineers to align DS with feature needs.

1 Product Design Lead, 2 Product Designers
1 Product Manager, 1 Project Technical Manager
2 Platform Architects, 4 React Developers
2 iOS Developers
1 Android Developer


BlockFi’s product design team took on a complete app redesign.

To successfully deploy a complete app redesign, product designers and engineers required a fully designed, documented, and built design system across native iOS and native Android (and we also needed to update the existing React web design system).


How do we rebuild a design system at the same time as an app redesign?

Important Detail

The product design team, coming together for the first time, bought into using a new DS from the start.

The work was really expedited by the support of the entire product design team. As we were a group that had just come together, taking over previous contractor work, there was an understanding that DS would play an integral role in defining the complete redesign work from the start - without that buy in, it would have been much harder for design system work to get anywhere.


🤔 Uncovering existing gaps within the current design system

To do so, the DS team sought to understand the loop from the perspective of different key stakeholders. Qualitative 30 min. interviews were conducted with: [3] Product Managers, [3] Designers, [2] Web Developers, [2] iOS Developers, [2] Android Developers and [1] Content Manager.

Through understanding our own system, a lot of problems began to uncover themselves. For example, it became clear that because not everything was built, there was a lot of wasted time between engineers and designers trying to juggle what they could and couldn't use.

Even doing a preliminary inventory of DS components painted bigger picture of what the system could and couldn't provide.

There was also a lack of documentation parity between what was provided in design libraries and in documentation of the built components. Because of this lack of parity, even if members of the design system team communicated to our product design partners what was available, the same information didn't hold true when passed down to engineering.

The Main Problems

Through research, we identified three main problems we wanted to focus on creating solutions for:

1. Piecemeal availability was hindering progress.
2. Existing DS design and developer documentation was fragmented.
3. Components and assets weren’t aligned with feature team needs and use cases.

Our metrics of success for solving these problems were as follows:

1. Does the mobile DS improve feature launch velocity?
2. Has there been an increase in code adoption?
3. Is there an improvement in # of Figma component inserts?


🛠 Building BlockFi’s Mobile Design System

I structured my design work to focus on three main objectives:

1. Design DS components more aligned with feature team needs.
2. Work with developers to create more dev-oriented design documentation.
3. Articulate overlaps in designer-engineer workflow processes and structure.

Step 1:

Design DS components more aligned with feature team needs.

Lists were used in some capacity by different designers, all working with their own version. As pages such as Trading and Settings were built, they were going to rely heavily on Lists and the component needed to be thought through from end to end.

Compared to Lists, Headers were first defined by redesign designers. However, people were still using individual header components throughout flows, and as a global navigation component, Headers needed to be fully realized in order to be a functioning design system asset.

Understanding how the List component works uniquely to BlockFi’s product.

By gathering use cases, I was able to understand what exactly helps shape BlockFi's needs out of a List component (these are only a few).

Identifying all criteria for successful components.

With Headers especially, it was key to identify all the properties that would make up a scalable component from the design side. Some of these would include:

Landing vs. Scroll Interactions
Components Available vs. New
iOS + Android Native prebuilds
Dark Mode Considerations
Spacing, Padding Adjustments
Icon Button Interaction Overrides
A11y Choreography
Changes for 320px, 375px, 360px

Architecting atomic components.

When building, in order to reflect how components would be used and built, both components followed an atomic architecture to support scalability and to develop parity between components in Figma libraries and components in the repositories.

Components in action in product features.

Step 2:

Work with developers to create more dev-oriented design documentation.

Different components require different types of documentation. For example, Lists were more easily built through understanding variant states, while Headers needed more documentation around on-scroll behavior.

Pushing for a11y from the design side.

By documenting a lot of the accessibility requirements that we wanted to meet at the very beginning, the DS team signaled that a11y was a non-negotiable consideration when building components.

Covered in documentation: Voiceover Choreography, Large Screen Viewers, Dynamic Text Scaling, Color Contrast Checks

Step 3:

Embed design system workflows more deeply into engineering processes and structure.

Half of design systems is actually getting things built, so as a design system team we looked to embed our design work as closely as we could to engineer workflows.

For example, we reorganized and articulated the full DS workflow for designers and engineers to align together on an agreed process.

Instituting our project tracking systems in JIRA helped us align our outstanding tickets and tasks to better align and keep track of parallel progress with components in development (as opposed to previous ad-hoc tracking in Google Docs).

In line with the Product QA step we aligned on, testing for development was done through Storybook for React Web, Testflight instances for iOS and Android APKs for Android.

Ex. WIP for Lists being built by the React team, demo'd through our staging Storybook.

Revisiting metrics for success

As new redesign components are being merged, we revisited the metrics we set out for Mobile 2.0, keeping in mind that our benchmark is previous feature design releases that went out without Mobile DS support.


🤔 What I learned

A willingness to listen and developing open lines of communications created a more resilient and flexible system.

Taking the time to workshop blockers allowed teams to arrive at a north star vision, solutions for tomorrow and solutions for today.

The systems community is moving towards dynamic layouts and tokens simultaneously, which brings design and development closer than ever before.

Giving design stakeholders autonomy and ownership allowed for a closer working, living, and breathing system.

Also, nested instances are 💯


As a parting note, enjoy this picture of some of us at BlockFi eating spicy Indian fried chicken sandwiches at Rowdy Rooster :)

The amazing team:

Product Managers: Sydney Chang, Melis Baykara Akel
Developers: Diogo Mateus, Jake Basten, Matias Mikkola, Anderson Day, Manu Herrera, Andres Predazzi
Product Designers: Farhan Mian (Lead), Kimaya Malwade

& of course, the entire product design organization.

Next Project: Discord