Building Rocket Lawyer’s First Design System

A strategic initiative to scale design, improve product consistency, and supercharge collaboration between design and engineering.

Client:

Rocket Lawyer

My Role:

Sr. Product Designer

Year:

2017

Team:

Jashan Gupta, Shawn Rosenberger, Courtney O' Connell

OVERVIEW

Rocket Lawyer was in a hypergrowth phase, doubling revenue from $50M to $100M in just two years. The design team grew rapidly from 2 to 6 members, but infrastructural investments—like a design system—were overlooked.

As a result, designers were recreating the same UI elements repeatedly, while engineers spent extra time coding variations of the same components. This slowed velocity, created inconsistency, and led to UX issues across products

PROBLEM STATEMENT

Rocket Lawyer lacked a design system, leading to:

  • Fragmented visual language

  • Inefficiencies in design + engineering workflows

  • Inconsistent user experiences across platforms

EVIDENCE

The same patterns, redrawn over and over.

RESEARCH METHODS

Auditing the existing UI, and learning from the best.

Internal audit

Audited Rocket Lawyer’s product suite for overlapping UI patterns.

Market Research Analysis

Studied leading design systems (Material, Polaris, Lightning) for inspiration.

MOTIVATION & BUY-IN

Pitching for a design system — and getting a counter-offer.

I pitched the need for a design system directly to the Chief Design Officer. While a formal team would take years to approve, I was challenged to prototype and prove the value first.

This became a strategic initiative:

  1. Build a design system for designers first.

  2. Use adoption and results to evangelize with leadership and engineers

PROCESS

Build for designers first. Use that to bring everyone else along.

1. Research

  • Audited Rocket Lawyer’s product suite for overlapping UI patterns.

  • Studied leading design systems (Material, Polaris, Lightning) for inspiration.

2. Define the Foundations (Atoms)

  • Colors, Typography, Elevation, Iconography, Illustrations.

3. Build Components (Molecules & Organisms)

  • Molecules: buttons, input fields, tooltips, banners, checkboxes, radios.

  • Organisms: CMS components, forms, responsive layouts.

4. Collaboration & Feedback

  • Weekly design critiques with CDO.

  • Monthly reviews with engineers.

  • Created scalable Figma libraries for design team adoption

Atoms — the foundational elements

Colors, typography, elevation, iconography, and illustrations — the building blocks every component is made from.

Molecules — composed components

Buttons, input fields, tooltips, radios, checkboxes, and banners — each made from atoms and reused across products.

Organisms — full patterns

Forms, CMS components, and responsive layouts — multi-purpose patterns built once and reused everywhere.

ATOMIC DESIGN FRAMEWORK

Atoms, molecules, organisms — building up to a system.

ATOMS — FOUNDATIONS

The building blocks every component is made from.

Brand, action, state, text, background, border, and social — every value tokenized so designers and engineers reference the same source of truth.

MOLECULES — COMPOSED COMPONENTS

Buttons, inputs, tooltips, and more — built once, reused everywhere.

Primary, secondary, large, medium, small — across default, hover, focus, pressed, disabled, and loader states.

ORGANISMS — FULL PATTERNS

Forms, CMS components, and library architecture.

Foundation Design System architecture

Organism components

CMS components

LIBRARY OVERVIEW

The complete system, on one canvas.

FROM THE TEAM

“Earlier what used to take us 2 weeks to complete, now can be done in a day.” — Shawn Rosenberger, Brand Design Manager

WHERE WE ARE NOW

Adopted by the design team. Now scaling to engineering.

All six designers are building with the system in their respective product areas, with shared Figma libraries replacing one-off mocks. An engineer is now wiring the same components into Storybook, with a Design System POC scheduled for executives to back further investment.

NEXT STEPS

Engineering implementation. Dedicated team. Cross-product process.

Ship the engineering implementation in Storybook. Stand up a separate, dedicated design system team. Establish processes to coordinate adoption across every product team — so the system stays current as Rocket Lawyer keeps growing.

LEARNINGS

Building from the ground up — and learning to evangelize.

This was my first time building a design system from the ground up. I learned a lot studying other systems (Material, Polaris, Lightning) and got far better at Figma's component model. Most of all: shipping a design system isn't a craft problem — it's a coalition problem. Cross-team collaboration, evangelism, and patient championing got further than any pixel ever did.

RESULTS

From inconsistency to a shared language.

14×

faster iteration on shared components

6/6

designers using it daily

Beyond the numbers, the system unlocked behavior changes across the team. Designers stopped recreating the same UI elements; engineers stopped coding variations of the same components; and reviews shifted from “is this right?” to “is this the right pattern?” Next steps: ship the engineering implementation in Storybook, and stand up a dedicated cross-product team to keep the system healthy as Rocket Lawyer scales.

Typography

Elevation

Iconography

Illustrations

MOLECULES — COMPOSED COMPONENTS

Buttons, inputs, tooltips, and more — built once, reused everywhere.

Buttons & Links

Input Fields

Tooltips