Building the FanBank's Design System

When I joined Pumpjack Dataworks, FanBank had just pivoted from a niche fan analytics tool to a full-blown data platform. With that shift came a flood of features: Audience filtering, trait monetization, data exchange, visual analytics. We had functionality, but no system.

Our files were getting messy. Components were reused, but never consistently. Developers were duplicating components. Designers were tweaking designs manually.

We needed a way to scale with sanity. So, my Lead and I set out to build a design system. One that wasn’t just documented, but actually used.

Our vision was clear:

• Speed up design and dev cycles

• Maintain visual and functional consistency

• Support white-label branding

• Bake in accessibility from day one

• Make it collaborative, not a design artifact, but a shared language

This wasn’t a one-off library. It was the foundation for FanBank to grow.

And it had to scale with the team. When we expanded to a team of five designers and multiple interns working on different modules, the system proved its value, serving as a shared foundation and guiding new contributors without confusion.

The first step was figuring out what we already had. I ran an interface audit across multiple product modules: the Audience Selector, Analytics Dashboards, Value Engine, and Marketplace.

I cataloged:

• Buttons, forms, tables, overlays

• Color usage and spacing rules

• Chart components, tooltips, headers

Patterns emerged. So did chaos. This audit helped us define what needed to be standardized and what needed to be reimagined.

We didn’t start designing components immediately. We defined the principles behind our system:

• Consistency builds trust

• Design for reuse

• Every component solves a real use case

• Accessibility is non-negotiable

• Build for evolution, not just MVPs

These weren’t just nice ideas. They were filters. If something didn’t support these, it didn’t go in the system.

For development:

• React + Storybook.js for building and documenting components

We created a shared repo that housed both the design and dev components, one source of truth.

Our stack at the time:

• Sketch + Abstract for design and version control

• Origami for advanced interactive prototyping

• React + Storybook.js for dev builds and documentation

This meant designers and devs worked off the same source of truth. Components were version-controlled, documented, and previewed with real states.

We followed Brad Frost’s Atomic Design model, which gave our system structure:

• Atoms: Colors, text styles, icons, spacing units

• Molecules: Buttons, toggles, inputs, dropdowns

• Organisms: Form sections, filter panels, tables

• Templates: Reusable dashboard layouts, analytics shells

• Pages: Fully built views (e.g., Audience Selector flow)

Each component was:

• Documented in Sketch and Storybook

• Built in React with props and variants

• Aligned with accessibility standards (color contrast, keyboard support, screen reader compatibility)

Grid: 12-column responsive grid with 8px baseline

Spacing System: 4px scale, mapped to design tokens

Typography: Standardized text styles for headings, body, labels, captions

Elevation and Shadow: Defined levels for overlays, modals, and depth cues

FanBank is a data-heavy product. I created consistent patterns and rules for:

• Data tables with sortable headers and status badges

• Chart types: bar, donut, Sankey, cubehelix gradients

• Responsive legends, labels, and tooltips

• Consistent use of whitespace and alignment to avoid visual noise

We applied WCAG AA standards across the board:

• Verified color contrast across light and dark backgrounds

• Designed for keyboard navigation and focus states

• Ensured form components were screen-reader compatible

• Provided ARIA labels and semantic markup guidance to devs

This wasn’t bolted on later. It was built in from the start.

FanBank was designed to be whitelabeled. That meant every UI element needed to:

• Support dynamic theming (custom color palettes)

• Maintain contrast and usability regardless of brand colors

• Use design tokens to enable branding overrides safely

We started with a default "Pumpjack Blue" palette and built theme slots for client overrides without breaking structure or legibility.

A design system is only as useful as it is understandable. So we documented everything:

• Usage rules for each component

• States and variants

• When to use what (and when not to)

• Naming conventions and contribution rules

Storybook became our dev-facing guide, while Abstract and Sketch libraries were the design-facing libraries.

• 30% faster dev cycles with ready-to-use components

• New designers onboarded 2x faster using the library

• System scaled across 7 modules

• Consistent UX across product features

• Improved collaboration between design, PM, and dev

• Smooth onboarding and collaboration across 5+ designers and interns

This wasn’t just a design artifact. It was a system that supported people.

We didn’t aim for perfection. We aimed for growth.

And it all started with listening, breaking it down, and building it back up the right way.