Design system

Status

2+ years and going

Team

2 Product Designers

3 Engineers

Role - Product Designer

Component Design, Visual & Interactive Design, Prototyping, Guidelines, Documentation

Overview

Overview

Overview

When I joined Teamshares, the design system was limited to design tokens like colors, typography, spacing, and shadows, with no component library in place. This led to inconsistent styles and a less intuitive user experience, presenting an opportunity to build a robust design system that better addressed user needs.

The goal was to build a design system that improves design consistency across our products and facilitate better workflows between design and engineering. I partnered with senior designers and engineers to make this happen.

Design tokens (colors and spacing examples)

Impact

Impact

Impact

We conducted an online survey with 32 product team members 6 months after implementing the initial update.

Data source: Gathered from online surveys completed by designers and engineers

Problem identification

Problem identification

Problem identification

In the kickoff session with all the designers and engineers, we identified the issues with the current design system and the repercussions they caused.

Problem identification with designers and engineers

Let’s not build from scratch

Let’s not build from scratch

Let’s not build from scratch

We initially attempted to build components from scratch, but the effort required to finalize designs for modals alone was significant. This approach wasn’t scalable, I brought together designers, engineers, and the PMs to discuss pivoting to existing design libraries, considering factors like development time and maintenance requirements.

Board outlining the reasons for adopting an existing design library

Being principled

Being principled

Being principled

We gathered together and created design principles for the design system, as the new library would be changing significantly. It was time to put a stake in the ground and define how we want the design system to be. We landed on principles I’m quite proud of:

Driven by accessibility

Driven by accessibility

Driven by accessibility

Build an inclusive design system that is easy to use and accessible for as many users as possible.

Consistent experience

Consistent experience

Consistent experience

Ensure a unified user experience that remains consistent across all product.

Focused essentials

Focused essentials

Focused essentials

Include a curated set of components that address the most common and impactful use cases.

Brand cohesion

Brand cohesion

Brand cohesion

Maintain visual harmony by aligning components with established design tokens, company aesthetics, and style guidelines.

Tech stack compatibility

Tech stack compatibility

Tech stack compatibility

Ensure seamless integration with development environment and tooling for smoother implementation.

Design & eng alignment

Design & eng alignment

Design & eng alignment

Foster collaboration between design and engineering to create solutions that are both innovative and practical.

These principles provided the groundwork for us to start exploring the potential design systems for Teamshares. We eventually decided on the Shoelace design system.

Crafting for efficiency

Crafting for efficiency

Crafting for efficiency

Design and engineering work was inefficient because we did not have a single source of truth for design components. To address this, I worked with other designers and engineers to evaluate each component and tailor it to our product requirements. This collaboration resulted in the development and documentation of 50+ components in Figma.

Creating configurable components

Following the atomic design theory, we created consistent, responsive elements that could be used across all products.

Expanding variant selections

Following the atomic design theory, we created consistent, responsive elements that could be used across all products.

Revamped Shoelace components and variants

Introducing responsiveness

To address the limited responsiveness on mobile, I proposed an adaptable layout with breakpoints at Mobile (390px), Tablet (834px), and Desktop (1440px), each featuring tailored margins, grid systems, and responsive components.

Updated responsive screens with breakpoints

Collaborate with engineers

Collaborate with engineers

Collaborate with engineers

We held pairing sessions with engineers to ensure the Shoelace components matched the updated designs in Figma.

We also hosted handoff sessions to discuss updated code in Shoelace 2.0 and Figma’s dev mode with all engineers and designers across different products, ensuring everyone was aligned.

Walkthrough of codes on Shoelace 2.0 and dev mode on figma

Outcomes

Outcomes

Outcomes

Shoelace 2.0 transformed our workflow, delivering 60% faster development cycles and consistent user experiences across Teamshares products. This foundation has significantly reduced maintenance overhead and accelerated our ability to scale efficiently.

Published

Figma integrated

Code steady

Guideline

Documentation

Accessibility

Testing

Interactive

Responsiveness

Modern UI

Templates

Limitations

Limitations

Limitations

Advanced components

While Shoelace provides essential components, complex UI patterns like complex data tables and specialized charts require custom development.

Mobile interactions

Touch interactions and mobile-specific UI patterns need enhancement to deliver a more polished mobile experience.

Better documentation for edge cases

For edge cases, teams sometimes create components based on individual interpretation, leading to inconsistent styles, increased design and tech debt, and lack of adherence to established patterns.

Takeaways

Takeaways

Takeaways

Negotiating design decisions

Each design decision required communicating with designers and engineers to reach consensus. This was challenging due to varying preferences, so I implemented a voting system to make decisions more efficiently.

Continuous updates

Unlike product design, a design system requires ongoing updates, from tweaks to code adjustments. Although a tedious process, it’s incredibly rewarding to see the design system evolve over time.

Architectural thinking

Building custom components from scratch trained me to think about design in an architectural way, focusing on structure, scalability, and cohesion across all components and products.

© 2025 Rachel Yang · Based in NY

© 2025 Rachel Yang · Based in NY

© 2025 Rachel Yang · Based in NY