Sapling Design System Documentation

I joined Ridgeline as the design systems design lead, working closely with the UI Frameworks and Experience Engineering teams. In addition to owning the Sapling design system, I identified, designed, and implemented a centralized documentation platform to address systemic breakdowns in how design system knowledge was created, shared, and maintained.

Overview

Ridgeline was in its sixth year as a startup when I joined. The product was months away from going live, with a single customer and an ambitious roadmap ahead. Sapling, the design system, was the sole system used to shape the entire platform's UX/UI, supporting a core UI library and multiple micro-frontends.

While the component library itself was solid, documentation had become fragmented across six tools:

There was no clear source of truth, no documentation strategy, and no shared understanding of where decisions lived or how they evolved. As a result, teams struggled to confidently use Sapling, despite it being foundational to the product.

Defining the Problem

The problem was not a lack of documentation. It was a lack of cohesion, discoverability, and trust.

Designers, product engineers, PMs, and UI engineers had to visit multiple tools to answer basic questions:

• Does a component already exist?
• How is it meant to be used?
• Why was it designed this way?
• Has it changed recently?

This led to:

The source of truth was blurry, and decision history was effectively lost.

Research & Validation

Rather than assuming the problem, I validated it through deep qualitative and quantitative research:

Key insights emerged consistently:

• Engineers often bypassed documentation entirely because it was outdated or hard to find
• Storybook was trusted most, but lacked context, rationale, and discoverability
• Designers and engineers wanted everything in one place, without losing role-specific detail
• New hires had "nothing" to onboard from
• Teams wanted documentation to reflect how things are actually built, not idealized intent

Goals

The goal was not to replace existing tools, but to make the system legible.

Strategy & Principles

Rather than forcing teams to abandon tools they already relied on, I designed a documentation site that reflected and surfaced content from multiple sources, bringing it together into one coherent experience.

Three guiding principles shaped every decision:

This allowed us to improve clarity and trust without disrupting existing processes.

Solution: A Purpose-Built Documentation Site

I designed and built a Documentation Site for Sapling (DSD) from the ground up.

The site:

• Acts as a centralized hub for all design system knowledge
• Embeds Storybook directly into the experience
• Surfaces Figma specs, design tokens, usage guidelines, and standards
• Provides direct links back to source repositories when deeper detail is needed

Teams no longer needed to remember where something lived, only what they were looking for.

Execution

Contributions & Governance

Another challenge was enabling non-technical contributions. Originally, I explored building a CMS to support federated documentation ownership. While viable, it introduced long-term maintenance complexity.

Advances in AI tooling allowed a better solution:

• Documentation changes can now originate from Jira tickets, threads, or files
• AI agents generate or update content directly in the site
• Humans review and approve changes before publishing

This approach:

Results & Impact

Challenges & Tradeoffs

Reflection & Legacy

This project elevated Sapling's perceived maturity and reinforced a critical lesson:

What I'm most proud of is not the site itself, but the shift in mindset:

This work represents how I approach design systems holistically, as products that serve organizations, not just interfaces.

Visual Artifacts