Stash design system

Design systems lead, Stash

Stash is a micro-investment and technology services app available on Android, iOS, and web.

I joined Stash in November 2023 and became the design systems lead soon after. My role was to maintain the growth and integrity of Stash Design Systems (SDS) alongside a lean team of Android, iOS, and web developers.

Stash Design System (SDS) is the product of a 2 year effort led by the previous design systems lead to increase velocity between designers and engineers.

SDS is made up of 6 libraries, making it one of the most robust design systems I and many other designers at Stash have worked with.

A contribution model had been created to aid designers in expanding SDS. However, the increased dependence on the SDS team made this model unutilized.

SDS follows a strict layer naming system with the purpose of keeping component nomenclature consistent.

However, despite the effort placed in the creation of SDS, designers found it incredibly difficult to use.
SDS was created by a small team of engineers and the original design systems lead with minimal input from other designers within the org. At the time, designers were mostly relying on adhoc components that followed a less cohesive system. The transition from that to a robust SDS was disorienting and ultimately led to team-wide frustration.

What made SDS hard to use?
Lack of familiarity
Designers were expected to jump into major projects soon after onboarding, limiting their bandwidth to gain familiarity with SDS. Further compounding the issue was SDS’s inherent complexity. SDS relied on Figma as a source of truth for designers and engineers, and so utilized workflows that many designers were not used to.

SDS intentionally created constraints within components to ensure the system’s integrity within designers’ and engineers’ workflows, seen here in the properties panel. Learning to manipulate these properties correctly took time that designers were not afforded, and most designers had never worked with such complexity before.

My role as a design systems lead meant that I had to be in a position to educate other designers (and at times engineers) on how SDS works, while also meeting deadlines for projects. I quickly found, however, that I was the only one expected to gain mastery of SDS, leading to the next issue:

Gatekeeping
Stash relied on a small team of 5 to manage and evangelize SDS from the beginning, creating a culture of dependence. Despite having a number of projects under our belt, most of our time was spent reviewing designers’ work or educating other teams. The general misuse or misunderstanding of SDS made it difficult to maintain its integrity and get buy-in from other teams.

SDS needed to be more accessible to the designers using it.
Adopting SDS and its workflows was difficult for designers because they were largely developed in a vacuum. Designers required not only familiarity with the system, but a system that was workable for them. This meant that SDS as we knew it had to change, and that began with dedicated education and support.

Teaching the basics
I felt it was important to outline the foundational qualities of SDS, such as its reliance on instance swapping (seen below) and key values. My hope was that designers could effectively scale and critique SDS by using these basics as a starting point.

These concepts were documented either as a screen recording, Figma file, or demonstrated during our weekly Design Office Hours.

A look at how a ❖radioItem can be instance swapped within a ❖buttonChoice component to produce the results seen in the wireframe.

A document on how accessibility manifests within SDS.

Developing an effective contribution model
SDS had a contribution model that was left on the wayside as the org relied on my team to manage changes. We decided to bring that back by gradually reducing our SDS responsibilities, teaching designers how to create and merge Figma branches.

A simplified version of our contribution model.

The design org should feel as though SDS is theirs to manage, even if it means changing it entirely over time. My goal was that as designers gained familiarity with SDS, they could review eachother’s branches and determine with confidence the direction they wanted SDS to go.

I also hoped that by opening up SDS, the design team would be more collaborative and share a culture of trust, which I began to see upon releasing this contribution model.

As a designer who values the work and impact of design systems and has developed design systems throughout their career, this was an awesome position to be in.
Unfortunately, however, I was part of the 25% of Stash employees laid off in March 2024. At the time, I was beginning to iterate on our contribution model to address SDS’s growing pains, which added friction to designers’ workflows.

My time at Stash was short but inspiring. I look forward to continuing this work elsewhere!

Quick actions