A few of amazing design systems that I studied
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.
I took the challenge being the sole designer to plan, define, create, and roll-out the design system for the product team.
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
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.
I ran a card sorting session with our product design team to uncover 2 things:
What is the names of all the existing components that all the product designers can agree upon?
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.
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.
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).
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
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.
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.
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.
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
Initial learning curve
Additional need for flexibility for changes in requirements
Saved time and energy
Easy to use
5/5 satisfaction survey results
100% designer and developer adoption
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
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.
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