Tokens
Colours
Typography
Icons
Spacing & Radius
Buttons
Input Field
Badge
Dropdown
Alerts
Building PL Prepaid Design System
Creating a scalable, token-driven design system for a fintech prepaid card product — from audit to platform adoption.
Company
Pine Labs
Role
Senior UX Designer
2025 - 2026
Scope
Design System · Component Architecture · Documentation · Design–Engineering Collaboration
Overview
Background
Pine Labs Prepaid is a comprehensive prepaid and consumer engagement ecosystem for businesses. It offers solutions spanning gift cards and prepaid programs, loyalty and rewards, digital wallets, marketplaces, B2C platforms such as Woohoo, and commute solutions such as Bharat Yatra. Together, these products help businesses manage stored value, rewards, distribution, and consumer experiences across online and offline channels.
System Scope
A complete token-driven design system for Pine Labs’ prepaid product — covering colour architecture, typography, spacing, elevation, and 18 component families from buttons to data tables. Every element is accessibility-tested, documented, and production-ready.
Component Categories Designed & Coded
Buttons
Dropdowns
Toggles
Avatars
Alerts
Notifications
Tabs
Tables
Empty States
Chips
Input Fields
Checkbox & Radio
Tooltips
Tags
Toast
Badges
Button Groups
Pagination
Breadcrumbs
Modals
18
Component Families
160+
Design Tokens
300+
Variant Configurations
98%
WCAG AA Compliance
6 mo
Zero to Production
Discovery
Visual Fragmentation over 5 Years
With 3 decentralized product design teams shipping features independently, the core experience fractured. Designers spent time reinventing layouts, and engineers spent up to 40% of their sprints custom-styling components like dropdowns and action buttons from scratch.
Friction metrics identified:
47
Button styles shipped
12
Shades of Brand Green
40%
Developer sprint waste
“We use separate open-source libraries across different products, so we don’t have a single master library. Components are built as requested for each project.”
— Engineering Lead
“Visual inconsistency in our product pages is eroding user trust. Users ask if they are two different sites.”
— Product Manager
Competitive Benchmarking Grid
Polaris (Shopify)
Dense Admin Layouts
Excellent merchants data layout; inspired our density tokens.
Carbon (IBM)
Technical Data Density
Highly structured state naming; inspired our token naming system.
Material Design
Flexible Platform Reach
Too generic for fintech, but helped establish our Android layout grids.
Lightning (Salesforce)
High Utility Controls
Heavy enterprise logic; helped shape our filtering systems.
Process & Planning
Atomic Build Order
We prioritized components by frequency of use and dependency chain - building the most reused, least dependent pieces first.
Phase 1 - Primitives
Month 1-2
Buttons (5 hierarchies × 5 sizes × 4 states), Checkbox/Radio, Toggle switches.
Phase 2 - Form Controls
Month 2-3
Input fields (text, textarea, verification code), Dropdowns (standard, filter, input dropdown with search).
Phase 3 - Feedback
Month 3-4
Alerts (4 types), Toast notifications, Notification banners, Badges, Tags/Chips.
Phase 4 - Navigation
Month 4-5
Tabs, Breadcrumbs, Pagination, Button groups.
Phase 5 - Complex Patterns
Month 5-6
Tables (with sort, frozen headers), Modals, Empty states, Avatars, Tooltips.
Library Stats
Component families
18
Variant configurations
300+
Months to production
6
COLOUR MODES
2
Solving the Variant Explosion
Our button alone needed 300 configurations. Instead of 300 separate frames, we used Figma’s component properties:
• Boolean props - toggle leading/trailing icons, error, link style
• Instance swap - swap icon components dynamically
• Variant props - hierarchy, size, state
300 frames → 1 component
Token Architecture
Separating Value from Intent
Instead of hardcoding colors, we built a 2-tier token hierarchy. This decoupled basic CSS values from functional design intent. When brand colors change, updates take seconds, not sprints.
Real-world Validation
“When we changed our primary brand green to Pine Green during refinement, it propagated across 340+ component files in Figma automatically in under 5 minutes.”
2-Tier Hierarchy Spec
1. Primitives (Values)
Raw value definitions
pinegreen-600: #005656
accent-600: #0172CB
2. Semantic Aliases (Intent)
Role & usage definition
color.foreground.primary
color.text.link
Components
v0.1 — TOO RIGID
Month 1
Forced everything into strict nested structures. Designers bypassed the library because it stifled creative exploration on specific layout options.
v0.5 — TOO FLEXIBLE
Month 2-3
Detached and broken buttons returned. Designers had too much freedom to overwrite sizes and styles, leading back to visual fragmentation.
v1.0 — THE SWEET SPOT
Month 4-6
Established clear constraints. Strict spacing and global colors, but with customizable slot areas for flexible layout exploration.
Internal Alignment and Objections Overcome
Cultural Frictions
• Color naming wars: Spent 3 weeks aligning engineering and design on a semantic palette naming convention.
• Dropdown disaster: Component was too complex, requiring 6 nested sub-components and 3 redesigns.
• Spacing theology: Deep arguments over whether 4px base grids are more flexible than 8px.
Resolving Pushback
• Eng: “No time to refactor.” We demonstrated a 40% reduction in average UI sprint development time.
• PM: “Users won’t notice.” A/B testing revealed a 12% improvement in client check-out conversion.
• CEO: “Why not Material?” Showed that custom styling matches our brand value, preventing generic look.
Creating trust through absolute precision.
The system is now adopted by 100% of our active product development lines, facilitating continuous design-to-code syncing.
Testing
TESTING METHODOLOGY / 4 PILLARS
Visual regression testing
Chromatic snapshots on every PR, catching unintended style drift instantly across themes and component state changes.
Accessibility audit
WCAG 2.1 AA compliance — contrast ratios, focus rings, keyboard navigation, and screen reader labels verified programmatically and manually.
Cross-browser validation
Verified across Chrome, Safari, Firefox, and Edge on desktop; optimized for iOS Safari and Android Chrome on web targets.
Developer usability testing
5 engineers completed product screens solely using DS components to measure first-time developer ergonomics and build speeds.
Real-world QA Resolutions
01 / Accessibility Fail
Focus ring colors failed AA contrast on dark backgrounds. Redesigned to an innovative dual-ring system (inner white + outer brand green).
02 / Keyboard Traps
The dropdown component trapped keyboard focus on mobile web. Implemented 3 key interactive navigation patterns previously omitted.
03 / Dataset Stress
Our raw table component struggled under 200+ rows. Created a frozen-header viewport variant with virtual list scrolling to ensure stable fps.
Usability & Coverage Metrics
98%
WCAG AA Compliance across core atoms
0
Visual regressions shipped in 4 months
67%
Faster dev build speed in sandboxed testing
Governance
2-TIER CONTRIBUTION ECOSYSTEM
Tier 1 / Command
Core Design System Team
2 dedicated designers and 1 frontend steward who maintain, update, and manage global tokens, base components, and official documentation.
Tier 2 / Propose
Ecosystem Contributors
Product designers across vertical squads who submit changes, propose net-new components, or optimize variants using the official RFC template.
Tier 3 / Apply
System Consumers
Everyone else inside product lines. Consumers rely on published nodes, import packages natively, and report production edge-cases.
The RFC Lifecycle Flow
1
Proposal
2
Review
3
Feasibility
4
Build
5
Publish
Our Versioning follows strict Semantic specs (major.minor.patch). Breaking releases provide a step-by-step upgrade guide. Major changes deploy quarterly; minor updates publish monthly.
Decision Log Excerpt
v1.2.0
Added advanced Prepaid Input Dropdown component (RFC-007)
v1.3.0
Deprecated old toast variations in favor of structured Banners
v1.4.0
Propagated accessible Dynamic Type scaling across mobile endpoints
System Rituals
• Bi-weekly design system sync (30 min) to review inflight proposals.
• Monthly component health metrics and performance checks.
• Quarterly executive adoption reviews with PM partners.
07 / DOCUMENTATION & ADOPTION
Documentation & Hand-off
Interactive Anatomy
Labeled component blueprints explicitly explaining slot layouts.
Documented padding, spacer dimensions, and token mapping rules.
Design guidelines illustrating both active and focus states.
Usage Guidelines
Explicit ‘Do vs Don’t’ interactive examples showing spacing constraints.
Guidelines indicating when to opt for specific visual variants.
Standard placement rules on mobile viewports and dialog popups.
Props & Variants
Storybook mappings aligning Figma component names to code endpoints.
Detailed props tabular list including types, defaults, and usage contexts.
Integrated design-to-code testing with automated Playground widgets.
3-Phase Adoption Strategy
Phase 1: Seed / Months 1–2
Piloted the initial release with 1 product squad focused purely on card activation flows. Discovered and resolved 22 early API integration edge cases.
Phase 2: Grow / Months 3–4
Expanded component deployment across 3 major teams covering payments, user onboarding and profile management systems.
Phase 3: Scale / Months 5–6
Achieved full organization-wide migration. Deprecated legacy design systems, with all new design sprints running on the official system.
Business Adoption Impact
78%
Adoption within 6 months
-52%
Reduced design-to-dev handoff delay
-34%
Reduction in core UI bug tickets
Learnings
01
Start with tokens, not components.
Tokens are the DNA. Components are the organs. Get your base design-to-code properties mapped cleanly first, and components will practically form themselves.
02
Sell the system to engineers first.
Figma updates please designers, but clean code adoption saves actual sprint money. Find engineering advocates early and work directly on Storybook.
03
Perfect is the enemy of shipped.
Our first release was incomplete, but shipping early sparked the direct cross-team discussions we needed to iron out structural issues.
04
Name things for intent, not appearance.
Using ‘comp.button.primary.fill’ is completely robust. Hardcoding colors like ‘mint-400’ directly breaks on the first brand overhaul.
05
Document the why, not just the what.
Anatomy drawings are helpful, but the rationales detailing usage contexts are what actually helped developers implement design patterns.
What I would do differently:
• Codify contribution guidelines on day one rather than waiting until Month 4.
• Integrate end-to-end automated visual regression testing from the start.
• Build a weekly design system digest to boost organizational visibility.
A design system is never finished.
It is a living product that grows with the team, the brand, and the users it serves. Adopting it yields immediate consistency.