← Selected work

Design system · Scale & delivery

Turning recurring product decisions into a shared system

I built Estateguru’s design system from scratch in Figma, using variables, design tokens and reusable components to support investor web, mobile and internal tools. Frontend engineers then built it as a React component library, documented in a public Storybook.

RoleDesign system owner
ScopeComponents · tokens · patterns
PartnersFrontend · product teams
DeliverySpecs · review · design QA
Estateguru design system components: a dashboard card, status and loan tags, a form field with error and a section message, loan table cells, the Auto Invest strategy card, donut, progress and meter charts, and a payment breakdown popover
Built from scratchSketch-based library → new Figma system
Live in code56 components, 400+ documented states and variants
Web + mobile + opspatterns designed across product surfaces

01 · Problem

Visual consistency was only the visible symptom.

The previous UI library lived in Sketch. Rebuilding it in Figma was a chance to organize styles, component behavior and responsive rules around the needs of the actual product, rather than copying an old asset library.

System goal

Create one reusable design foundation with clear building blocks, product-specific patterns and implementation-ready states.

02 · Research

Before building anything, I studied how mature systems solve the same problems.

I reviewed three public systems that set the standard for product UI at scale: IBM Carbon, the Atlassian Design System and Google’s Material Design. I compared how each one names tokens, structures color and type, documents component states and connects design files to code, then kept what fit a regulated investment product.

IBM Carbon

Tokens named by role (text, background, layer, focus) instead of raw values, and one grid and spacing scale shared by design and code.

Atlassian

Semantic color tokens with a clear intent, such as subtle text or selected background, a defined elevation scale and guidance written for product teams.

Material Design

Tonal ramps built from a key color, a type scale named by role, and interaction states expressed as overlays on top of a color.

What I kept

Two-layer color naming, numbered tonal ramps, role-based type styles with mobile sizes, and hover and focus overlays as tokens.

03 · System principles

I built from foundations to page-level patterns.

States built in

Account for loading, empty, error, disabled and status states, including responsive layouts.

Atomic composition

Start with small reusable components, then combine them into richer controls and modules.

Figma variables & tokens

Define color, typography, spacing and other reusable values through Figma variables and design tokens.

Implementation review

Review built screens with engineers and refine components when real product needs expose gaps.

04 · Color

Brand names for people, semantic roles for code.

The palette works in two layers. Ten brand colors carry human-readable names that designers, marketing and product can talk about. Every color used in the interface is then referenced through a semantic role that matches code usage, so a designer picking “text secondary” in Figma and an engineer using the same token get the same result, and a later brand change touches the values, not the screens.

  • Ribbon Blue#244CFF
  • Imperial Blue#212F40
  • Frost Blue#CEE8F4
  • Cotton Blue#F2FBFD
  • Neon Green#DBFF76
  • Forest Green#1B9D46
  • Bicycle Yellow#FFE68D
  • Pink#FCD9D9
  • Vivid Orange#FE5F00
  • Lavender#AC69D9

Tonal ramps

Ribbon Blue expands into a primary ramp from 50 to 900, plus in-between 75 and 550 steps. Gray runs from 25 to 900. Success, warning and error each have their own ramp, and five decorative ramps serve illustration and highlights.

100500 · Ribbon Blue900

Roles and contrast

Semantic roles with their value and contrast against white
UseTokenValueOn white
Body text and headingsText Primary#212F4013.6:1
Supporting textText Secondary#58626F6.2:1
Links and actionsText Interactive#244CFF5.9:1
Error icons and bordersError 400#CF405C4.6:1
Success icons and bordersSuccess 400#1B9D463.5:1
Warning icons and bordersWarning 400#FE5F003.1:1

Text and action colors pass WCAG AA for body text, and white on a Ribbon Blue button reaches 5.9:1. Status colors at 400 clear the 3:1 minimum for icons and borders; their 50 tints carry message backgrounds. Interaction states are tokens too: hover and focus are 4% and 8% overlays of Ribbon Blue, the focus ring is Ribbon Blue at 25%, and the modal backdrop is Imperial Blue at 50%.

05 · Typography

Two typefaces, one scale, every style sized for desktop and mobile.

Wermut, a display face with character, is reserved for hero and page titles, where the brand speaks. Inter does the work everywhere else: its tall x-height and distinct digits keep dense financial figures, tables and form labels readable at 12–16px.

Type scale: size / line height in pixels, letter spacing where it is not zero
StyleDesktopMobileTypeface
Hero H164 / 80, −1.444 / 52, −1Wermut
H156 / 68, −1.240 / 48, −0.8Wermut
H236 / 4832 / 40Inter Semibold
H328 / 3624 / 32Inter Bold
H424 / 3222 / 28Inter Medium
H518 / 2818 / 28Inter Medium
P16 body16 / 2416 / 24Inter Regular
P14 body14 / 2214 / 22Inter Regular
P12M caption12 / 1812 / 18Inter Medium
B14M button14 / 24, +0.214 / 24, +0.2Inter Medium
Names that read as specs

Style names encode size, weight and line height, such as P14SB or B14M_20, so a token read in code tells an engineer exactly what it renders.

Responsive by default

Headings step down on mobile; body text stays at 14–16px so reading comfort never drops on a phone.

Tracking with intent

Negative tracking only on the large Wermut sizes, +0.2px on buttons for legibility at small sizes, zero everywhere else.

Grid and depth

A 4px base, 12 columns at 1200px and 960px, 6 on mobile; five standard shadows and four transparency steps.

06 · Architecture

Generic components and fintech patterns live in one library.

The system follows a practical hierarchy: foundations → layout primitives (box, stack, grid, page and section headers) → form elements → navigation → overlays → presentational components → data visualization. Product-specific components sit next to the generic ones instead of being rebuilt per page: activity, bonus and status tags, a Moody’s rating tag, primary-market loan tables, meters and donut charts for portfolio data.

Figma component library
Coded components from the Estateguru Storybook: activity tags Active, Awaiting Funds, Paused and Cooldown; an EG Bonus tag; an A1 Moody’s rating tag; warning and error section messages; a donut chart with a total; a circular progress indicator and a meter
Product components as they render in the coded library: investment status tags, bonus and rating tags, section messages and portfolio charts.
Design SystemsFigmaDesign TokensResponsive ComponentsStorybook

07 · Figma to code

The states specified in Figma became the coded stories.

I specified components with their states and responsive rules in Figma, clarified implementation details with frontend engineers and reviewed shipped interfaces against the design. The engineers built the system in React and TypeScript, with Emotion for styling and Nivo for charts, and documented it in Storybook.

Because states were part of the design spec, the code follows the same matrix. A form field exists as default, with helper text, error, warning, disabled and read-only, most of them with and without a label, so nobody has to invent a missing state during a sprint.

Form field states from the Estateguru Storybook: default, helper text, error with feedback text, warning with feedback text, disabled and read-only
One form field, six states, rendered from the live Storybook.
  • Component states and responsive expectations defined before build.
  • Shared token names between Figma and code.
  • Design review during implementation.
  • Library updates as new product patterns appeared.

08 · Impact

A system that supported product delivery, not a separate design-system project.

The rebuilt Figma library provided shared foundations, reusable components and responsive specifications across the investor portal, mobile app and internal interfaces. In code it is a public reference: 56 components, 6 layout primitives and 5 foundation pages, with more than 400 documented states and variants.

Open the live Storybook

Next case

Operations and back-office workflows.

Operations case →