Building a
design system:
Givelify Analytics Studio

Research, planning, designing, and rolling-out

Problem space

Givelify's product team faced a major challenge. There was no single standard or source of truth to follow when it came to foundational design styles, components, or patterns causing inconsistencies in UI and UX throughout the product. Our product teams worked in silos, further exasperating the problem.

We knew we needed a solution that can help our designers have more time to focus on solving for their user’s problems, rather than trying to find and/or recreate the proper style, component and their interactions, or pattern for their user flows.

Since design systems are common solution in today’s leading organizations that enable scalability across their ever-evolving products, we leaned in to learn from them. We sought to implement a design system because we realized that our current processes would continue to add to our design debt and would be unsustainable in terms of scalability overtime.

How might we help our designers spend more time on things that matter?

Role

I took the challenge being the sole designer to plan, define, create, and roll-out the design system for the product team.

Research

A few of amazing design systems that I studied

A few of amazing design systems that I studied

Getting inspired

Before I got started, I intensely studied the design systems of brands that succeeded in scaling products from nimble start-ups to large organizations such as:

  • Polaris by Shopify

  • Carbon by IBM

  • Material UI

  • Uber

  • Duet

  • Wave

All these organizations had so many different solutions of a working design system that enabled them to scale, from the different stage of the design system product, structural build and naming, categorization and organization, and token use.

I mapped out the young vs. mature design systems, noting the common foundations, components, and patterns and how they were documented and distributed.

Compile and audit

I took gathered of all our screens that exist in production, Figma design flows, and style guides and component libraries then took inventory of the styles uses and all the re-usable components and patterns, and where they existed in the product. It was amazing to find over 200 different style buttons, over 500 different text fields, and other similar components that were used in production and in the existing design files. It was helpful to compile this all to visually show how our basic building blocks were re-designed and re-coded over and over again.

I also made sure to study effective design components and patterns of successful SAAS companies to take inventory of the patterns that was common and let users complete their tasks, with ease considering Jakob's law. The purpose was to make sure that if an atypical component or pattern and their interactions existed in our library, I wanted to take this opportunity to improve upon it.

Ideate

Figjam card sorting activity with product design team

Figjam card sorting activity with product design team

Card Sorting

I ran a card sorting session with our product design team to uncover 2 things:

  1. What is the names of all the existing components that all the product designers can agree upon?

  2. How do the naturally designers group and categorize these components?

The card sorting activity unveiled lots of difference in the language of the components as well as the way designers would naturally group them. I understood this was end-all solution but a good place to start grouping our components, knowing we would naturally iterate and evolve the groupings.

Another goal of this exercise was to prime their knowledge of groupings in advance so that when they do use the design system in the future, they would know the components and patterns that exist in the system as well as where they may belong.

Atomic design structure

Atomic design structure

Atomic design

Because our product was constantly evolving, our main requirement of the design system was to create a flexible architecture that could adapt to future changes easily.  In order to make this possible, I looked upon Brad Frost's Atomic Design principles. Atomic design allows for extreme modularity by breaking down all elements to their fundamental building blocks. I audited the current component libraries, listed all the existing components, and broke apart each component by atoms, molecules, and organisms so that we can re-create all of the components atomically.

Atomic breakdown of existing foundation and components

Atomic breakdown of existing foundation and components

Solution

Foundations

Before starting, I aimed to incorporate the latest branding into our design language, while creating a distinct look and feel for our analytics product. I started off by compiling all the various component libraries and styles that were in the Givelify's Figma file and production environments across marketing and product teams. I gathered all the different uses of color, typography, spacing, shadows, border styles and radius, and grids and made comparisons to where and how they were used and if I could find some alignment between them. I collaborated with the lead designer to finalize the final type and color scales to ensure brand fit and the usage logic, while ensuring good hierarchy, readability, and accessibility (WCAG 2.2).

Building a design system: Givelify Analytics Studio

Atomically built, responsive, pixel-perfect components and interactions

After finishing our foundations, I eagerly started on building modular, atomically built components. My goals included:

  • Atomic structure are flexible for swapping instances

  • Flexible to manual changes

  • Responsive to different device sizes

  • Included all the associated interactions

  • Enhanced usability

Building a design system: Givelify Analytics Studio

One-to-one mapping

In order to ensure that we can provide the devs the right direction to update or create components and patterns to align them to the design system in Figma, I created a one-to-one mapping from their current storybook to our current design system in Figma. We wanted to ensure that there was an associated codebase for the styles, components, and pattern that existed in our Figma design system in Storybook so that Figma and Storybook can become the central source of truth for our designers and developers. Our design system engineer took the responsibility of consolidating the differences and creating a backlog of tickets that noted the new or revised storybook component with the latest specs.

Tokens synced in Figma to Github via Specify

Tokens synced in Figma to Github via Specify

Token implementation

I created a roadmap to start implementing design tokens to store our visual design attributes such as color, typography, spacing, border radius, and border styles to push modularity and reusability to the extreme, ensuring a closer parity between design and implementation while strengthening design and developer communication.

We demoed a few token tools and settled upon Specify in tandem with Theemo Figma plugin for alias and component token creation due to their technical support and ease of use and implementation from both the design and development perspective.

Current items on the developer's backlog includes implementing alias and component tokens and further down our roadmap includes implementing themes for our different products.

Design system governance

In order to ensure that there is a process to adjust and add new components, interactions, and patterns to the design system, we needed to work with the product team to understand how the design system process would work in tandem with the design process. We drew process flows to capture the current product process including the design, development, and QA process and drew out a process flow that allowed for both product design and design system team to contribute to the design system, ensure functional requirements and acceptance criteria, placing the changes or additions on a backlog to build, collaborating with developers to ensure proper build, QA, and release of design system components.

Design system governance baked into product design process

User Testing

User Testing

Usability testing is necessary for the design system to continue to be iterated upon to evolve the design system with the changing needs of the user and business. After training sessions were complete, we started testing with a small group of designers who were willing to test the design system to see if it will fit their needs.

Methodology

Our user testing started with a pre-roll out beta with 3 of the senior product designers using the soon-to-be released design system as they worked in their normal workflow. Designers were asked to use the design system and document the following:

  • Document any pain points as you go through your regular workflow as you use the design system library on your Figma designs.

  • What did you like about the design system?

  • What did you not like about the design

Insights

Pain points

  • Initial learning curve

  • Additional need for flexibility for changes in requirements

  • Breaking Changes

  • Resource constraints

Gains

  • Saved time and energy

  • Easy to use

  • 5/5 satisfaction survey results

  • 100% designer and developer adoption

Release documentation

Release documentation

Change management process

One of the largest problems we ran into while maintaining and updating the design system was addressing changes made to the design system prior to having a change management process. Some changes to Figma design system components caused cascading breaking changes that disrupted designer's designs, which caused some initial pain points. We sat down as a team to retrospect on this issue and discussed several options to test and iterate upon:

  • Change releases documentation and sync with slack channel

  • Breaking change notification

  • Create new variant for breaking changes

  • Potentially detach instance for shipping

Building a design system: Givelify Analytics Studio

Weekly syncs, training workshops, and official roll-out

In order to ensure adoption from our product teams, I needed to make sure that we made our main users and stakeholders aware of the design system and potential changes it may present in their workflow and process and also provided opportunities for them to get involved by providing input on design system usage. I conducted a weekly design system sync for designers and a weekly sync for design and developers to get together.

In addition, I created training documentation on the best practices on how to use Figma and the design system and held several sessions for designers who are more visual and kinesthetic learners to join and interact with the design system to create prototypes.

Design system training slides

Reflection

This project was an excellent opportunity for me to get involved in helping my primary users, our product designers, find efficiency and be consistent with one another with ease. I ran into issues with constraints with resources and couldn’t do everything that I wanted to do in a given quarter and had to break the tasks into doable pieces of a larger roadmap since I was the sole designer taking ownership of the build and roll-out of the design system.

Since our project started off as a grassroots solution, a major challenge I ran into was selling the need of additional tools and resources to maintain a design system to leadership with competing priorities.

In order to do this, I had to really get the devs and designers onboard to stand up together to advocate for the design system by creating an environment of trust and camaraderie. To do this, I ran workshops and meetings to understand the design and dev's workflow by interviewing them and setting up time to understand their pain points with adoption required patience, understanding, and empathy. It is something that I continue to this day to bridge that gap and build evangelism of a strong design system foundation with the company.

I am excited for the future of the design system with endless possibilities for improvement. Of course, this is still not the end, and there are so many things that I would need to do to enhance localization, documentation, and scale this design system to include different themes and different products, which is an ongoing process.

As for some closing thoughts, I know that the design system is truly never finished. There is significant work to constantly maintain and improve the design system to work for our users as the needs of our users and technology evolve, and I'm here for it!

Major thanks to the following collaborators that made the design system roll-out possible:

  • JW Kim, VP of design and innovation: Leadership design system advocate

  • Reé Chen, Lead / Senior product designer: Oversight and spiritual support, User / Usability tester

  • Deo Gochava, Senior FE developer: Design system and token implementation lead

  • Winnie Yuen, Senior product designer: Spiritual support, User / Usability tester

  • Jimmy Santos, Senior product designer: Spiritual support, User / Usability tester

  • Kayla Smith, Project manager: Spiritual support, design governance process main collaborator, and evangelist

  • Chris Whitefield, Lead / Senior product designer: Design system and token mentorship

  • Vissarion Chakvetadze, FE engineer: User / Usability tester

  • Tran Pham, FE engineer: design system component engineer

  • Ken Waugh, Dev lead: Design system and process design support

  • Viktor Mateleshka, Dev lead; Design system implementation oversight and support

  • Hafiz Temuri, Senior FE developer: Design system support and evangelist

  • Boris Zivkovic, PO: Implementation support and evangelist

  • Joe Bennet, PM: Implementation support and evangelist

  • Meghana Bailey, PM: Implementation support and evangelist

10
Foundations
300+
Components and Patterns
100%
Adoption
100%
User satisfaction