Jackrabbit Design System

Company

Jackrabbit Technologies

Tools

Figma, Confluence, Storybook

Role

Owner & Contributor

Deliverables

Design library

Component guideline

Design tokens

Component documentation site

TL;DR

00 - TL;DR

Rebuilding Jackrabbit's most-used feature for scale.

Three products drifting apart, with no shared source of truth.

Challenge

Approach

Rebuilt the system with atomic design, one foundation composed up into every screen.

Method

Tokens, fully-documented components, reusable patterns, and content standards.

Result

60% UI QA issues, −40% design-to-dev time, +30% NPS, built to scale.

01 - The Problem

Three products drifting apart.

While exploring the existing brand assets and design documentation, I developed a clearer picture of the underlying challenges affecting team consistency and workflow.

Challenges affecting team consistency and workflow. Every one of them tracing back to the same missing source of truth.

Inconsistent UI Across Products

With multiple teams designing in silos, our UI components had drifted apart significantly. This lead to inconsistent experiences, duplicated efforts, and brand mismatch.

Lack of Source of Truth

Designers and developers lacked a shared up-to-date repository of components and styles. This led to guesswork during implementation and inconsistencies in both look and behavior.

Retrofitting vs. Building New

Balancing the need to standardize legacy UI with the desire to build future-proof components posed technical and design tradeoffs.

Accessibility Inconsistencies

Ensuring that all components met accessibility standards (e.g., WCAG) across different browsers and devices required a deliberate and often overlooked design/dev effort.

Consistency

Source of Truth

Tradeoffs

Accessibility

02 - Hypothesis

Hypothesis

inconsistent experiences and duplicated effort.

Problem

We noticed

that as our product offerings grew, each team was building UI components slightly different.

Resulting In

Solution

By introducing a

centralized design system with shared tokens, components, and guidelines, we can give teams a common foundation to build from.

Desired Results

We hypothesize this will

improve the visual and functional consistency across our platform and also speed up development time and make cross-team collaboration more smooth.

Every challenge traced back to the same gap: no shared foundation. I rebuilt the system with atomic design, composing small, reusable pieces up into full screens so all three products build from one source instead of three.

Atoms - Buttons, Inputs, Labels, Icons, etc

Molecules - Input field with a label

Organisms - Navigation bar with multiple buttons and molecules

Templates & Pages - Fully functional screens

Atoms

Molecules

Organisms

Templates

Pages

03 - The Approach

One system, built atomically.

Foundations are the shared language beneath every component. Color, type, spacing, and more, defined once as tokens so all three products stay consistent by default. Change a token, and every component using it updates in step.

04 - Foundations

The tokens everything is built on.

Colors

Primary Colors
Secondary Colors
Tertiary Colors
Slate Colors
Greyscale Colors
Success Colors
Danger Colors
Warning Colors
Informative Colors

Typography

Desktop Headlines
Body & Subtitle

Logos & Brandmarks

Logos
Brandmarks

Components are where the foundations become usable. Buttons, inputs, controls, built once with every state and variant defined. Nothing left to a developer's guess: default, hover, focus, disabled, error, and valid, all specified.

05 - Components

Every state, documented.

Buttons

Primary Filled
Secondary Filled
Tertiary Filled
Sizes
Spacing

Controls

Checkboxes
Radio Buttons
Switches

Foundations and components answer "what things look like." Patterns answer "how they work together." This is where I defined the reusable solutions to recurring product problems, so teams stop re-solving the same interaction from scratch

06 - Patterns & Workflows

How the pieces solve real problems.

Patterns & Workflows

Call To Action Placement
CRUD

Most systems stop at components. I built content standards in too. Voice, formatting, and validation language so the words stay as consistent as the UI.

07 - UX Writing

Content as part of the system.

Content

Rules

08 - Impact

One system, measurable results.

-60%

UI-related QA Issues

fewer inconsistencies

−40%

Design-to-Dev Time

reusable components

+30%

NPS Score

reported user satisfaction

+25%

Task Completion

across core flows

SPEED

Speed

Satisfaction

Usability

Internally, the modular design-system approach cut design and development time for future enhancements.

09 - Built to scale

I built the system to outlive any one product, so the next two could adopt it without a rebuild.

Structured so staff-facing workflows could adopt the same foundation directly.

Ready for the Staff App

Ready for the Parent Portal

The family-facing experience could extend from the same atomic base.

One Foundation, no Drift

Every future product draws from the same tokens and components.