By Matt Trice

Building our organization's design system seemed like a straightforward task until we tried to implement it. As our org continued to grow, the need for a design system seemed obvious. With more developers and designers joining the organization it seemed like the right time to codify how we design digital products. The heightened onus on our design deliverables was exciting. However, we quickly learned that theory-crafting design systems is easy, but actually implementing and gaining org-wide traction is challenging.

As a daily power user of Figma, crafting the visual elements and establishing a cohesive design language came naturally. I pride myself on pixel-perfect design and thought I would be able to knock this design system out.

We envisioned a future where our design files would seamlessly translate into code, fostering a near 1:1 Figma-to-code match that promised increased efficiency and a stronger connection between design and development.

Efficiency means not having to re-build or re-design the same component again and again. A stronger connection means speaking the same design language, sharing the same design principles, faster prototyping, accessibility compliance, and streamlining handoff processes.

It all made perfect sense in theory.

However, as we delved into the implementation phase, we encountered challenges we hadn't fully anticipated.

What you will learn

• The insights we gained, how we changed our thinking

• Improvements we made to our workflow

• What did not work

• What we’re doing that does work

The Need for a Design System

In short, we wanted to level up our design process and how we hand off design. While building a design system demands an up-front time investment, the return on this investment becomes evident as the system matures and grows.

ROI

• Improved consistency & quality

• Collaboration across disciplines

• Reduced build costs

Where to start

Figma + Storybook

We started with an in-house product build that was actively in development.

I teamed up with our front-end team (typically a primary front-end dev and an occasional secondary front-end dev) and as I built components in Figma, they built components in Storybook.

Storybook is an open-source development tool that allows you to create, document, and test individual UI components in isolation. Basically, we were creating a component library code repository.

Design Tokens

The concept of design tokens seemed straightforward. Snippets of code, typically JSON, that store design decisions. Tokens are platform and technology-agnostic and designed for flexibility and scalability.

Salesforce’s Lightning Design System sums it up well:

“Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development.”

I meticulously crafted the naming convention for typography and colors and exported tokens that our developers were able to consume.

Success! (Kind of but not really)

However, when it came time to scale the system to a new product, what scaled seamlessly in Figma did not scale as seamlessly (as we had hoped) on the development side.

Specifically, with a new batch of typography and color tokens came new naming, and parts of the front-end code base had to be re-factored to account for the new styles.

We realized what was lacking was a proper token structure.

We were using a hybrid of core and component/semantic tokens. We didn’t realize it at the time but having a proper token structure is crucial to usage and scalability.

A token structure introduces the concept of a 3 layered token system. At the base, you have primitive, core tokens (like color ramps). Above that are aliases of the core tokens. Token aliases let you relate a semantic token to a base token for a specific context or to get a level of abstraction.

The structure helps to communicate the intended purpose of a token independent of the core value of the token.

Read more about the Token Pyramid Structure.

What about Storybook?

Turns out we were a little premature here. An active Storybook library full of usable React components is only valuable if your team uses it.

The key thing to emphasize here is that it's difficult to determine what patterns are likely to be repeated until the app is actually built. The lesson learned is, to build a thing and take inventory after it's been built.

That inventory is the baseline for Storybook. Doing it the way we started was putting the proverbial cart before the horse.

Getting lost in the weeds

With no instruction manual for how to build your org’s design system, it was easy to go down rabbit holes and “get lost in the weeds.”

Design Systems are unique and different for every organization. While there are tons of how-to’s, downloadable UI kits, publicly available systems like Material Design, and new Figma plugins daily, none of them will just fit into your organization’s workflow off the shelf. It takes communication and collaboration to truly understand your org’s needs.

Enrolling in Dan Mall's Scaling Design Systems course turned out to be a pivotal step in understanding the challenges of implementing our organization's design system.

The course provided much-needed clarity on various fronts.

One valuable insight that really stood out was a quote from designer Jose Torré:

“Rather than approaching design systems like architecture, we should approach it like gardening.

An architect designs a structure considering every single detail, but once they’re done, they move on to the next one.

A gardener plants seeds and tends to them. They know what they planted, but they don’t know exactly what the garden is going to look like. They find out as it grows and intervene when they find weeds, or they want to make changes.”

Ah hah! This made sense. We slowed down, took a step back, and paid closer attention to what seeds we had already planted and what was already growing.

As the course wrapped up, Figma released its variables feature which had us re-evaluating our tokens process.

And if you can, I highly recommend taking one of Dan’s courses.

Finding our direction again

On the design side, we've made some strategic adjustments to our approach.

We believe incorporating a design tokens handoff is key to scaling and theming our design system. With Figma’s variables feature released, this felt like a perfect avenue to building a layered token library. We also decided to focus on understanding and incorporating this one aspect of our workflow.

Once we understand and have adoption with color tokens, we will scale into other design tokens.

Recognizing the complexity of Token Studio, we dialed back its usage, as trying to learn it alongside Figma variables proved too intricate, with a steep learning curve that could hinder adoption.

What we stopped doing

• We paused our usage of the Tokens Studio Plugin and are focused on creating and managing variables within Figma. The Tokens Studio plugin while very robust and powerful, is too steep of a learning curve to practically add to our current design stack

What we started doing

• We have started to embrace a pre-made Design System called Tetrisly for its well-constructed Figma components. (Currently, this is a Figma-only kit but React components are coming)

• We are crafting our own variables and tokens on top of the Figma kit.

• We are holding workshops with our front-end development team to collectively decide on things like token structure naming conventions and how to assemble Figma designs for proper token output.

Communication is Key

One of the most crucial lessons we've learned on our design system implementation journey is the importance of communication.

While we utilized Figma color styles and diligently created JSON tokens, hindsight revealed a significant gap: the absence of a proper token structure.

Additionally, while well-intentioned, our experiences with internal adoption highlighted the need for more constructive feedback.

It was a lesson on the importance of reaching out and collaborating with members of your organization who are outside of your direct team. Most importantly, talk to your engineers about what’s working for them and what isn’t. Find the middle ground where design and development overlap and processes intersect. And then document how you can work together as an organization.

What We're Doing Now

We are actively focused on implementing a token structure for color. This means design and development are working together to name and organize design color tokens.

• Cross-team adoption of a color tokens flow

• Scaling the color tokens flow into additional token sets like typography and border radii

• Scaling into more specific use case components that are privacy and web3-focused

What We're Doing Next

When Decent DAO started our journey of building a design system, we were a venture studio building blockchain products that spanned the web3 ecosystem. Since that time, we have narrowed our focus to building web3 privacy applications. We believe privacy is critical to the next stage of growth in the space. Design will be critical to ensuring privacy features and user experience work hand in hand.

How does that translate to our design system?

Much like Decent’s decision to focus on privacy has directed our collective builder focus, the decision to focus on privacy should be reflected in our Design system as well.

Privacy by Design

By integrating privacy considerations into the design process, a design system can promote the "privacy by design" concept, which emphasizes proactive measures to protect user data throughout the product's lifecycle.

• Consistency in Privacy Features

• Data Minimization

• Security evangelist of secure design patterns and coding practices

• Keep privacy UX top of mind with user-friendly privacy controls

• Guidelines for privacy compliance design

• Promote a culture of privacy awareness within the organization

I hope this has left you with some clarity for your own design system project.

If you're working on integrating privacy features into your application, we’d love to connect with you. Discover more about our work at decent-dao.org, send us a message at hello@decent-dao.org, and join our community on Discord.

Matt Trice is a core team member and design workstream contributor at Decent.

@NFTrice0000 ; matt.trice@decent-dao.org