CASE STUDY- 2021
Sonic Design System
INTRODUCTION
Working on a scaling product, we must’ve found ourselves in a chaotic environment where we blame each other teams for the bad quality of output and messy design implementation on shipping products. Which sometimes also easily transitions into hostile interactions between design and dev teams during handoffs. A design system is the ultimatum that prevents this and brings harmony between the teams.
MY ROLE
Product Designer
TEAM
+2 Designers ( Tony , Malavika )
PROBLEM
There was a lot of inconsistency across various UI components (which often leads to failure of brand recognition and trust) in the long run. Designers were constantly investing a lot of time in reinventing and reconstructing different components for the same functionality and requirement, we had so many variations, even for simple components like a button adding further complexity and ambiguity to the system.
Different button variations captured from multiple Figma files
GOAL
“ Building a single source of truth “
So that everyone in the team speaks the same language across all products within Hypersonix.
CHRISTENING (MOTIVATION)
We had to start from scratch, and as common, among Designers, we also made sure to give our design system a cool name. I don’t know why. Small things like this is really motivating.
We Titled our Design system “Sonic“, representing the velocity at which our Rocket ship Company Hypersonix is growing. Sonic V 1.0 meant (Velocity 1 = Version 1 ) which was our internal analogy for emphasizing that, Sonic design system is something that continuously evolves and everyone in the team helps in achieving higher velocities progressively and in turn helps Hypersonix travel through expanding cosmic space = scale and reach higher distances = growth.
We Titled our Design system “Sonic“, representing the velocity at which our Rocket ship Company Hypersonix is growing. Sonic V 1.0 meant (Velocity 1 = Version 1 ) which was our internal analogy for emphasizing that, Sonic design system is something that continuously evolves and everyone in the team helps in achieving higher velocities progressively and in turn helps Hypersonix travel through expanding cosmic space = scale and reach higher distances = growth.
INITIAL HYDRAZINE (FUEL)
- Research
We didn’t know how to go about creating a Design System or if there is some standard way? so we started with some research, reading medium articles, referring to other giant design systems documented out by, IBM, Segment and Atlassian etc.
- Prioritization
We conducted internal meetings with multifold teams including developers, product managers, and design and UX to identify what parts the team would prioritize for the Sonic V 1.0 design system.
- Inventory
Our next task was to create an inventory for every UI element that was Prioritized. Spanning across different pages across our web application we took screenshots of every page, every button, every menu, every popover, pretty much all the UI elements prioritized for V 1.0. Then we took ownership of specific components and recreated them in Figma with properly defined styles and guidelines.
STRUCTURING FIGMA FOR DESIGN SYSTEM
Naming and Documenting are not the only hurdles in this evolving Journey of creating a design system.
We have to account for scalability and think about discoverability for all the incremental components that will be added progressively. As the design system evolves, discoverability becomes a challenge and it becomes difficult for teams to find what they need.
To address this, we used Figma pages as our directory. We created a designated project for design system and multiple files for defining foundation principles and to capture all the components. Each file had a distinct thumbnail image helping users identify things without reading. Each file comprises of the following:
We have to account for scalability and think about discoverability for all the incremental components that will be added progressively. As the design system evolves, discoverability becomes a challenge and it becomes difficult for teams to find what they need.
To address this, we used Figma pages as our directory. We created a designated project for design system and multiple files for defining foundation principles and to capture all the components. Each file had a distinct thumbnail image helping users identify things without reading. Each file comprises of the following:
Figma component thumbnails - in Design system project file
Each file had a distinct thumbnail image helping users identify things without reading. Each file comprises of the following:
- 1. Thumbnail
To help users identify without reading.
- 2. Name
What is the Style defined /component called in the system.
- 3. Status
Tells the user the current state whether it’s (complete and deployed /dev-ready/in-design phase /backlog).
4. Version
To signify the version of a particular component in the system (this helps in the maintenance of a component) To be added while the design system evolves.
Peek of sections defined within or Foundation Principles
Let’s build a component and see it in action
For every component we built we followed the below
documentation sections within Figma:
- 1. Introduction
- 2. Composition
- 3. Intent4. Properties5. Design Tokens6. The Component & Variants
Contents
Each component file starts with a contents Frame that has all other sections headings listed that could be found on the Figma page.
Contents frame- within ELP Card component page
1. Introduction
This section contains brief description about the component itself and its place and use in our product system.
Contents frame- within ELP Card component page
2. Composition
This section contains a blueprint of the component’s construction details with respective labels and layout attributes.
Composition frame- within ELP Card component page
3. Intent
Under this section, different intents available for a component are listed. One common example of intents of components are (positive, negative and neutral) : It can convey tone / feedback to the users.
Intent frame- within ELP Card component page
4. Properties
This section contains information on the properties of the elements composing the component. This is useful for developers.
This section is built to maintain a single source of truth and is populated with collaboration with SDEs.
It also helps in setting limitation thresholds, for example:
- defining a character limit to a text layer inside a component,
- fields which is required/optional
Properties frame- within ELP Card component page
5. Design Tokens
This section shows all tokens and components (if any) are used inside (nested) in a particular component. This helps developers to get an overall understanding of the component just by looking at one frame.
Tokens frame- within ELP Card component page
6. Component and its Variants
Finally, this section contains the master component itself with all the applicable variants which adheres to all the guidelines documented.
Master component frame- within ELP Card component page
There are many hurdles involved when trying to make Figma as a single source of truth for a design system. While everything might not be solved using the structure itself. Communication between teams also plays a very vital role in making it successful.
NEXT STEPS
Figma has recently launched interactive components and right now we are exploring and reconstructing some components trying to make use of this new feature and also debating over its benefits and disadvantages on its incorporation all across the Design system.
CONCLUSION
Design systems are like organs of a living product and it constantly evolves and needs to be taken care of and maintained based on product needs. For products to scale and grow these organs (design system needs to function properly at all times)
