Design Systems Lead
Interaction Design
Stash
2023—Present
Problem Overview
The current system was not scalable
Our old design system was not managed by any particular team. This made implementing reusable components for product teams difficult and ultimately impacted concept-to-code timelines across the org.
No single source of truth
Lack of clear design documentation and component status makes it difficult for product teams to choose the right components, leading to wasted time rebuilding existing components, inconsistency, and drift.
Inconsistency across platforms
Each platform (Android, iOS, Web) had more than 350 unique layouts. There are more than 14 different design variations for entering an amount. Complexity like this leads to cognitively heavy customer experiences.
Scaling
STEP 01
Vision for Stash Design Systems
We asked ourselves, how might we reduce the level of management required to keep our design system healthy? I ran a vision workshop to brainstorm various flows of how our component and style libraries would interact with each other. The general consensus was that enabling automation would make governing a design system scalable, as cohesion between design libraries and code would simplify the process.
Design got to work on establishing the structure of our design libraries, and the foundation for our design tokens. Our engineers created microservices that would connect our Figma libraries and tokens using Figma's open-source API. This enabled our design libraries to seamlessly sync with production code, reducing the need for manual management.
Definitions
Storybook: Interactive code and documentation for components.
Resource Station: Holds resources such as font files.
Token Express: Delivers design tokens to docs and production code.
UI Kit: Figma design library that holds components and patterns
Documentation site: A website that provides a central location for storing and sharing information about the system
M-Asset Transit: Delivers Figma assets to asset manager Banksy.
Banksy: Asset manager that delivers assets to apps.
Banjo: Content manager that delivers Figma strings to apps.
Snuffler: Analytics and actions to detect, block, and remedy misuse/deprecation.
STEP 02
Create Design Styles & Tokens
Now that we had a proof of concept for how our libraries would be managed and automated, the next step was to establish our styles and design tokens. The foundational styles of our app are color, typography, spacing, and motion.
Color
Color is complicated—establishing a fully accessible color library can be a tedious and manual process. As Ashley Seto, a Lead Product Designer at Meta who has scaled accessible color systems several times in her career, puts it:
"Usually you're going to find designers staring at screens trying to determine which blue is the most expressive blue for their brand, picking out a range of colors that they want to use within their creative assets. This part of the process, we as designers, are willing to spend thousands of hours on."
Ashley Seto
Lead Product Designer
Stash needed a solution that would allow us to create a color system that worked for our existing brand while also addressing accessibility issues programmatically.
DYNAMIC COLOR
The team found Google Material Design's Dynamic Color tool to be the perfect solution for our needs. I provided the tool with key colors, and it generated a unique color palette that met accessibility standards. The tool also generated a set of primitive colors, which we then extracted into color tokens. These color tokens can be used by designers and engineers to create consistent and accessible user interfaces.
ACCESSIBILITY
Our new color combinations meet the WCAG 2.1 guidelines' minimum contrast ratio of 4.5:1 for the visual presentation of text and images of text. This means that Stash's color system is now accessible to customers with visual impairments. Our color token naming convention, coupled with documentation, makes it easy to understand our color pairings.
In the process of landing on our new color system, I rigorously tested its application in areas of the product that heavily rely on color as a design element, such as data visualizations.
Typography
A strong typography system helps establish hierarchy and communicate important content by creating clear visual patterns.
TYPE SCALE
To ensure that designers had all the type sizes they needed to establish hierarchy, we followed the major thirds scale. I used the tool typescale as a starting point, and this scale helped create a natural visual rhythm for our new type sizes.
BRAND COHESION
To ensure that our brand and product visual design were consistent, I made adjustments to our font weight, line height, and tracking properties. I then tested out some of our new type styles in marketing material to make sure that everything looked cohesive.
TYPE TOKENS
Finally, we established naming conventions for our type tokens to abstract the type values and provide a common language for designers and engineers to refer to type.
Spacing
Spacing of elements can be used to create visual hierarchy for content and guide focus to certain elements. Too dense information can be hard to digest for a user, so make sure to leave enough space in the user interface.
Our system for spacing was disparate across our platforms, with no real standards for designers to follow. Without proper spacing guidelines, the hierarchy and layouts of our products became inconsistent.
GRIDS & LAYOUT
I established an 8-point linear scale for layout with a 4-point half-step for spacing icons, text blocks, and within components. This standard helps our designers create visual rhythm, and keeps layouts consistent across our UI.
SPACING TOKENS
With new spacing tokens our designers and engineers now have common understanding of what spacing and corner radius properties they can implement in our layouts and components.
Motion
Motion is used to enhance usability and create desired emotions for Stash's customers. Prior to this design system initiative, there was no system or standards for motion. Much of this early work was done in collaboration with our motion designer, Lisa Cai.
MOTION TOKENS
We established a motion library containing tokens that are made up of primitive motion properties (i.e. Easing, Scale, Duration, etc.). Combining these properties and tokens creates all motion elements from transitions to micro-interactions to animations, we call these motion elements functional tokens.
MOTION DOCUMENTATION
To ensure that motion design was properly translated to production, I worked with our engineers to create motion documentation for components. This documentation would be presented alongside our components so that engineers could properly translate motion into interaction states and transitions.
STEP 03
Establish component statuses
Our previous system had no workflow or documentation for the health of our components. Designers would see a component from a previous design and assume it existed, only to find out that it didn't exist or was different across platforms.
Our goal in establishing component statuses was to ensure that designers and engineers knew if a component was healthy to use and what platforms it was available on. We started by tracking component statuses in Figma and eventually migrated to our documentation site.
STEP 04
Build foundational components
In preparation to get functioning components into the hands of our product teams, we dedicated time to designing and building a set of foundational components. We focused on the most common components in our product to get the team started and accustomed to shipping quality components.
Adoption & Contribution
Once we had a scalable Design System in place, our next step was to get the Design System into the hands of our product teams. We treated the Design System as a product in itself, so we launched a beta program, just like we would for any other product. The main KPI we focused on was adoption. Now that we have what we feel is a great product, how might we get product teams at Stash to adopt it into their workflows?
Pilot programs
To get feedback to iterate on our design systems, we followed Dan Mall's principle of "pilot programs." We spoke with product teams and followed a simple set of criteria to ensure that both teams could benefit from the pilot.
"Like television pilots help test audience reactions to a series concept without investing significant resources to create the whole thing, application pilots are a good foundation for ensuring your design system’s design and code are battle-tested."
Dan Mall
Founder, Design System University
Our criteria for quality pilot programs came down to the following:
Scope of project: We wanted to keep these pilot programs at a reasonable size. If we over-commit to too large of a project, the Design System risks becoming a bottleneck, which could jeopardize our adoption rate.
High potential for common components and patterns: The more reusable components we can extract from the pilot programs, the more coverage we can achieve across other product experiences.
Timeline: Ideally, we would like to come in early in the other product team's design process and timeline. This would prevent us from creating a waterfall effect, where the other team is waiting on the Design System team to deliver reusable components.
The Design Systems team follows a process called the Measuring Spoon Cycle. This cycle provides us with an efficient framework that we can pitch to other product teams as a way to ensure parallel progress with their roadmap. As we ship more product experiences, our Design System becomes more mature.
Here are a few UI screens from our first pilot program, where we helped the Universal Features team ship a project to provide customers with an option for an annual subscription.
Documentation site
The final piece of the puzzle for a well-rounded design system was our documentation site. This site provided a central location for storing and sharing information about the design system, from design principles to usage guidelines for components.
Not only did this site provide documentation, but it also functioned as a marketing site for our design system. Everything you need to know about how to use the system was neatly packaged, which greatly helped design system adoption.
Conclusion
As much as the designer in me would like to wrap a bow on the conclusion of this project, unfortunately, a design system is never truly finished. When done correctly, it is a living and breathing system that allows makers to contribute and adapt it to their needs as their company scales.
With Stash's Design System, I am excited to see where it goes. I feel strongly that the standards and processes that the team and I established will ensure that Stash's product teams are able to scale and deliver their solutions to market efficiently.
Credits:
Devin Wilmot: Principle Designer
Mike Cornell: Engineer Manager
Austin Venhuizen: Product Manager
Lisa Cai: Motion Designer
Anjana Balamourougan: Product Designer
Ashley Handy: QA Engineer
Anthony Maldarelli: Engineer, Web
Stuart Barker: Engineer, Web
Quentin Colle: Engineer, Android
Tomas Navickas: Engineer, Android
Manuel Fernandez: Engineer, IOS
Tiz Bruni: Engineer, IOS
All rights reserved ©2023