Chaitanya Prashant - Minds design system

Overview

Designing and helping implement a design system to unify Minds' web and mobile experiences, improve consistency and increase developer velocity.

Role

One of two UX designers on a cross functional product and engineering team. I took the lead on foundational and web components, as well as governance.

Timeline

November 2022 - Feb 2023

Responsibilities

Design thinking, interaction and visual design, Front end engineering (minor contributions).

Team

Chaitanya Prashant - Design
Michael Wroblewski - Design lead
Mark Ryan Sallee - PM
Ben Hayward - Engineering
Martin Santangelo - Engineering
Mark Harding - Engineering / CTO

Problem

As a product development team, Minds lacked a cohesive design system, leading to inconsistent UI components across web and mobile platforms. This inconsistency resulted in inefficiencies with the design and development processes, with teams spending excessive time creating and maintaining disparate UI elements.

As our web app was written in Angular, and our mobile apps in React Native, there was a need to create a language of shared components and elements to help increase developer velocity and improve the consistency of the experience on both web and mobile. With a planned product expansion and exploratory research on Minds Networks (read more here), our team realized that investing in a design system effort early would help unify mobile and web, and help developer velocity over the long run.

Hypothesis

We hypothesized that creating a unified design system of our web and mobile UI components would help bring our interface closer to our brand values, while increasing developer velocity when it comes to shipping features and bridging the gap between design and development.

Defining our scope

How might we design and develop a design language that supports the design and development teams to help deliver consistent user interfaces?

"Design systems aims to mitigate entropy, but entropy is constant." - Laura Prete

This was a defining statement for us, as it helped us set goals for our efforts and initiative. Meeting with the developer and product team at a moderated kickoff workshop, we aligned on unifying our current set of UI components that existed on web and mobile to help consistency and development speed, with a focus on code re-use.

We also took this kickoff time to help establish overarching principles that would govern our design system, and provide a north star for future component development. Although we were a remote team split into different timezones, Figjam and Google Meet made the collaborative workshop run smoothly.

Design language foundations

Although we iterated on these throughout the initiative, the core ideals of our design system emerged from this workshop.

Being up-front with the development team was critical here, as we wanted to ensure that any design system update is conducive to development time. Whilst they were convinced of the longer term benefits of having a re-usable code library, the development team was hesitant of taking a potentially huge re-write on.

To keep consideration of development time as a smaller startup, we aligned on a development schedule where a component would be updated in code if it was part of a feature that was prioritized. With this approach, we were able to incrementally update components and increase consistency across web and mobile.

This incremental approach helped me immensely as a designer, as it made me even more familiar with component usage across the product, and broadened my understanding of the Minds product from a systems level.

Outcomes and key metrics

Reduced UI component development time by 67%.

As we incrementally made updates to the design system, starting with color and typography, and then core elements, there was less back and forth between design and engineering during implementation. This resulted in greater productivity for our development team, which meant more time developing valuable features.

Decreased UI bug reports by 27%.

Although this metric was measured over a longer period of time (3 months after launch), both the mobile and web team reported a significant downturn in users reporting visual bugs and errors on Gitlab.

Consistency and familiarity

With the launch of our design system, as well as unifying components across mobile and web (React), we were able to help in creating a shared language between design and development.

We also created a lightweight framework to guide new component development, including potential approaches to governance. The goal of this was two-fold. One was to ensure that any new component being added to the design system was intentional and would be used in a prominent feature. Second, I hypothesized the framework would help formalize, as well as democratize the addition of new components, where engineers, just like designers, could make the case for a component to be added to the design system.

Initial governance structure document

Solution

Our solution was focused on first systemizing typography, spacing and color with the development team via design tokens. Each named variable for a value such as our brand color, or a spacing value like 4px, corresponded with the token name in CSS. This was critical for us as a team, in terms of design and development speaking the same language.

Check out the live documentation here.

Typography and spacing

Our focus with establishing typography and space guidelines were twofold. Firstly, elements would correspond to its respective code counterpart, ensuring that UI development would be more predictable and reduce inconsistencies in visual design. Especially as Minds is a content and text heavy interface, changes to typography made a massive impact in terms of clarity and accessibility.

We established a soft grid of 4px and 8px increments, with the goal of making both the design and development of interfaces consistent and predictable. In terms of visual design, these increments lend themselves well to responsive design, as most popular screen sizes are divisible by 4 on at least one axis, and usually on both.

Typography

Spacing

Color

Our key goal with refactoring and launching a color palette was ensuring that we stuck with Minds' original brand, while focusing on colors that were accessible and consistent across platforms. The core palette includes detailed specifications for text, backgrounds, accents and colors for light and dark mode. Our design team also generated and tweaked an extended palette that accommodated various design needs and ensured that one-off colors would not be needed. This helped immensely when it came to design handoff, as there is no ambiguity in implementation of a color, and any color outside the palette would need to be refactored or deleted.

Core app and product palette

Buttons

Button component documentation

Iconography

Icon documentation and usage - light and dark mode

Web - form components

Web forms component documentation

Web - navigation

Web navigation surface documentation

Web - overlays and sign-up surface

Web overlays surface documentation

Web - notifications

Web notifications surface documentation

Web - Composer

Web composer components documentation

Web - user channel

Web channel surface documentation

Web - recommendation components

Web recommendation components documentation

Web - activity post

Web post components

Web post components in-feed

Web - utility

Web utility components documentation

Mobile - form components

Mobile form components documentation

Mobile - navigation

Mobile navigation surface documentation

Mobile - overlays

Mobile overlay components documentation

Mobile - notifications

Mobile notifications surface documentation

Mobile - composer

Mobile composer components documentation

Mobile - user channel

Mobile channel surface documentation

Mobile - activity post

Mobile activity post components documentation

Mobile - utility

Mobile utility components documentation

Impact and learnings

Whilst short term metrics are actionable, they lack insight in terms of how a solution might help over the long run. I was thus interested in the design system's update on a measurable factor, such as UI bug tickets submitted. My hypothesis here was that the number of UI bug tickets would be inversely proportional to visual consistency and accessibility.

Although this was measured over a longer period of time (3 months after launch), both the mobile and web team reported a significant downturn in users reporting visual bugs and errors on Gitlab. This also freed up development time that could go towards faster releases and feature development.

Early on, we also realized the value of having comprehensive documentation and governance frameworks for the design system. Documentation of guidelines and design elements served a dual purpose of sharing the 'why' and 'how' of using components, while also helping evangelize our design principles internally. In terms of knowledge transfer, and a day when product members might leave, our documentation and site on ZeroHeight served as a persistent source of truth. it was critical to have a governance framework that allowed for easy updates, but still ensured that there was a clear process and prioritization to account for bloat or unnecessary components.

Even if fighting against entropy is a losing battle, updates to the sign up flow and various surfaces led to a 70% increase in sign up rates on mobile web, which made the initiative well worth it.

Thank you so much for reading! If you have any questions or wanted to ask more about the project, don't hesitate to reach out on my email at [email protected]