Building BlockFi’s mobile design system 2.0 that supports 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 build the best product we could.
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
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).
What really helped expedite the redesign of the design system itself was 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.
Our goal was to uncover 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:  Product Managers,  Designers,  Web Developers,  iOS Developers,  Android Developers and  Content Manager.
As we worked our way 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 we could and couldn't provide.
We also noticed a lack of documentation parity between what was provided in design libraries and in documentation in built components. Because of this lack of parity, even if we communicated to our product design partners what was available, the same information didn't hold true when passed down to engineering.
Through research, we identified three main problems we wanted to focus on creating solutions for:
1. Piecemeal availability was causing unnecessary confusion.
2. Existing DS design and developer documentation was fragmented.
3. Design system components and assets weren’t fully meeting the needs and use cases of feature teams.
Additionally, we identified three key area metrics that we wanted to quantify to understand the actual impact design systems had on BlockFi products development.
1. What's the impact on feature launch velocity?
2. How can we increase code adoption?
3. Is there improvement in # of Figma library component inserts?
Design system components and assets weren't fully meeting the needs and use cases of feature team designers and engineers. The process to address this could be broken down into three steps:
1. Prioritizing DS components needed with redesign designers and get them built!
2. Creating more robust design documentation to catch development considerations from the beginning.
3. Embedding design system workflows more deeply into engineering processes and structure.
I'll focus on two components that went through this process: Lists and Navigation Headers.
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.
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).
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
Changes for 320px, 375px, 360px
When building, in order to reflect how components would be used and built, both components followed an atomic architecture to 1. help scalability and 2. to develop parity between design components and code components.
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.
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
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.
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.
A willingness to listen and developing open lines of communications creates a more resilient and flexible system.
Taking the time to workshop blockers allows 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 your design org autonomy and ownership allows 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 :)
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.