Design system

Grove Design System

Bloomerang · Design Systems Lead · 2023–Present

Grove is Bloomerang's internal design system — the shared language between design and engineering across three products: CRM, Volunteer Management, and Fundraising. I inherited a partial component library with no system underneath it. What I built is the infrastructure that turned a sticker sheet into a scalable, AI-consumable design system.

3 products CRM · Fundraising · Volunteer

1 token system Powering all three product contexts

Storybook-ready Piped into engineering's AI workflow

Before

What I walked into

When I arrived, Bloomerang had just renamed its system to Flora. What existed was a foundation in name only — icons, logos, colors, and a type scale living in flat Figma frames with no documentation structure and no token layer underneath them.

Before that, component work had been happening in a disconnected sticker sheet: over 20 individual button color hex values defined in isolation, no shared palette, no naming convention, and nothing that could be consumed by engineering without manual translation.

The sticker sheet era — buttons each carrying their own hex value. — The sticker sheet era — each button state carrying its own hex value. No token layer, no aliasing, no system. Just a growing list of one-off color decisions with no way to change them at scale.

Flora — colors and type documented, but still a reference sheet. — Flora — one step better, but still a reference sheet. Colors and type documented, components starting to appear, but no atomic methodology, no naming conventions, and nothing connecting components to a shared token foundation.

The most important decision wasn't a component

The infrastructure underneath everything

The single most impactful thing I built in Grove wasn't a component — it was the variable architecture underneath them.

Three product modes (CRM, Fundraising, Volunteer), each with their own primary color aliases mapped to a shared brand token layer. One component, three product contexts, zero duplication. This structure is what eventually made it possible to pipe Grove into Storybook for AI-assisted development.

Hero imageDS_Variables.pngSave as images/ds-variables.png

The Alias collection in Figma's variable panel — 39 alias variables mapping three product modes to a shared brand token layer. CRM resolves to green, Fundraising to blue, Volunteer to purple. Change the alias, everything updates.

Methodology

A shared mental model

Before Grove had a methodology, "component" meant different things to different designers. I introduced atomic design as the organizational framework — atoms, molecules, organisms, templates, pages — not because it's clever, but because it gave the team a common vocabulary for how the system should grow.

The methodology also gave engineering a predictable mental model for consuming the system. Atoms map to tokens. Molecules map to components. Organisms map to patterns. That clarity is what makes AI-assisted development possible.

Flora's atomic design documentation — atoms, molecules, organisms, templates, pages. — Flora's atomic design documentation — the framework that replaced "here's a bunch of components" with a system designers and engineers could reason about together.

The work

Components on a token foundation

Components built on a token foundation, documented for multi-product use.

01 — Atoms

Spacing

Spacing increments defined at the atom level and demonstrated through molecules and organisms. The redlines aren't documentation for documentation's sake — they're the contract between design and engineering. Smaller increments (4–20px) for internal component padding. Larger increments (24–40px) for layout and outer margins.

Proxima Nova type scale across four weights using a Minor Third ratio.

02 — Foundation

Typography

Proxima Nova across four weights — Light, Regular, Semibold, Bold — scaled using the Minor Third ratio of 1.200. Every style tied to a corresponding Figma text style, documented for both web and mobile. The typescale isn't arbitrary: the ratio creates visual hierarchy that stays consistent as the system grows.

Font Awesome Pro 6 icon system with sizing specs and per-product nav sets.

03 — Foundation

Iconography

Font Awesome Pro 6 as the standard icon system, with sizing specs (20×20 and 24×24 as the most-used sizes), per-product left nav icon sets documented, and legacy MUI icons flagged for deprecation. The page also establishes the Icon Hover State pattern — a detail that lives in the Button component's parent context.

Text fields and dropdowns across default, focused, error and disabled states.

04 — Molecules

Input fields

Text fields and dropdowns across all states: default, focused, error, disabled. Basic and small size variants. Two searchable dropdown states. The kind of component that looks simple until you try to make it work consistently across every form in three products — then it becomes one of the most important things in the system.

After

Where it is now

Grove today — components built on a token foundation, documented for multi-product use, and piped into Storybook for engineering's AI-assisted development workflow.

The current Grove component library — buttons, chips, navigation, modals, dropdowns, date pickers and status indicators. — The current Grove component library — buttons, chips, navigation, modals, dropdowns, date pickers, and status indicators, all resolved through the token layer.

Impact

What it changed

Grove went from a partial component library with no system underneath it to a scalable, token-driven design system that Bloomerang's engineering team is now piping into Storybook for AI-assisted development.

The variable architecture that powers multi-product theming — one component, three product contexts — is what made that possible. Designers spend less time making decisions that should already be made. Engineers spend less time translating design intent into code. The system does that work.

It's still growing. That's the point.