Context

BlockFi, a crypto exchange, was redesigning its entire web app to usher in a new phase of mobile-first business.

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).

Research

We needed to first uncover existing gaps within the current web-first design system, to understand our own pain points

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.

Priority #1

Design DS components to be more aligned with feature team needs, so less time was wasted on detaching and remaking UI.

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 a component works uniquely to BlockFi’s product allowed us to stand out from our competitors and other design systems.

For example, in 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 created a foundation to seamlessly update everything, saving on time and energy when implementing.

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
etc.

Architecting atomic components allowed the design system to scale efficiently and with less design and build time.

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.

Testing components out in real screens helped us cut down on iteration time and additional effort required to revisit design.

Priority #2

Collaborating on dev-forward documentation speeded up the handoff process and eliminated unnecessary confusion.

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 ensured our app was usable by all users, bringing in more customers.

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

Priority #3

Embedding design system workflows more deeply into engineering processes and structure eliminated barriers to collaboration and shipping updates.

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.

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.

Reflection

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, which in turn gives design stakeholders autonomy and ownership allowed for a closer working, living, and breathing system.

Also, nested instances are great. The closer to code architecture and semantics, the better!