Design Library
Design system for SaaS ERP platform
Overview
As a frontend engineer at Springbrook Software, I inherited and then maintained the design library powering Cirrus, an ERP product used by 1000+ organizations. I did not originate the system; my role was long-term stewardship of its components and core concepts, with ongoing improvements to architecture, accessibility defaults, and adoption patterns across teams.
What was built
An enterprise design library with reusable components, tokens, and adoption guidelines.
Key constraints
Large legacy surface area, cross-team adoption friction, and accessibility requirements.
Outcome signal
Improved consistency and delivery velocity through component-first product development.
Technical artifacts and implementation status
Technical artifacts
Publicly shareable artifacts
Private enterprise artifacts
- Component-library repository and production modules are proprietary to Springbrook.
- Normally shared artifacts would include component contracts, migration plans, accessibility test reports, and adoption dashboards.
Implemented
- Shared component system and usage guidelines
- Design tokens for type, color, and spacing
- Accessibility defaults in common components
In development
- Incremental migration of legacy views
- Ongoing component coverage expansion
- Team adoption feedback loops
Planned
- Deeper pattern library documentation
- More automation around visual regressions
- Additional layout and data-density patterns
Component hierarchy diagram
Design tokens
Type, color, spacing, elevation
Primitive components
Buttons, inputs, modals, tables
Product modules
Cirrus features with shared UX patterns
Decision log
| Problem | Options considered | Chosen solution | Rejected alternatives | Why this won | Accepted tradeoffs | Result after implementation |
|---|---|---|---|---|---|---|
| UI inconsistency across multiple ERP modules and teams. | Team-by-team conventions or centralized component library. | Component-first design system with shared tokens. | Uncoordinated local component implementations. | Scaled consistency and reduced repeated UI decision cost. | Initial migration cost and longer component design cycles. | Higher consistency, faster implementation, lower review friction. |
| Accessibility regressions appeared when implemented ad-hoc per screen. | Late QA checks or accessibility in base components. | Accessibility defaults embedded into base components. | Optional accessibility reviews after feature completion. | Moved compliance from optional step to default behavior. | More complexity in foundational components. | Stronger WCAG baseline across newly delivered features. |
| Legacy UI surface was too large for a big-bang migration. | Full rewrite or incremental rollout. | Incremental migration by feature and module. | Single release cutover of all legacy screens. | Reduced delivery risk and protected roadmap throughput. | Temporary coexistence of old and new patterns. | Steady adoption without blocking ongoing product delivery. |
The Context
What is Cirrus?
Cirrus is Springbrook Software's enterprise ERP platform for municipalities, school districts, and other organizations running mission-critical workflows across finance, HR, procurement, and operations.
The Challenge: Consistency at Scale
Before the formal library, modules evolved independently and UI drift accumulated. Inconsistent patterns increased user cognitive load and reduced confidence in product reliability.
The Opportunity
A formal system needed to deliver five outcomes:
- Improve user experience through consistency
- Accelerate development by providing reusable components
- Reduce technical debt and maintenance burden
- Enable scalability, with new features built on solid foundations
- Improve product quality and user confidence
Design System Approach
Auditing the Existing Product
Before building the design library, I conducted a comprehensive audit of the existing Cirrus codebase. The goal: understand what components existed, how they were implemented, and where inconsistencies had accumulated. This audit revealed:
- Buttons implemented in 5+ slightly different ways across the app
- Form components with varying patterns and behaviors
- Inconsistent color usage and typography
- Missing accessibility features in many components
- Duplicate code that could be consolidated
Designing the System
Based on the audit, I designed a comprehensive design system that included:
Typography System
Defined font scales, line heights, letter spacing, and weight usage. Clear rules for headlines, body text, and labels improved readability and reduced style drift across modules.
Color Palette
Established a primary color system, secondary colors, and semantic colors (success, warning, error). Every use of color across the application was standardized. This improved consistency and made it easier to update the entire product's aesthetic through centralized changes.
Component Library
Built reusable components: buttons (with all variants), form inputs, cards, modals, navigation, tables, and more. Each component was designed with accessibility built-in, not bolted on.
Spacing System
Defined spacing increments (8px base unit) used throughout. This created rhythm and visual harmony. New developers could build layouts that felt cohesive without designer oversight.
Documentation & Guidelines
Wrote comprehensive documentation: when to use each component, how to use them, accessibility considerations, and code examples. Good systems are useless if nobody knows how to use them.
Implementation Strategy
Rather than requiring a complete rewrite of Cirrus, I took a pragmatic approach:
- New Development: All new features built using design library components from day one
- Incremental Migration: Existing components gradually refactored to use the library
- Backwards Compatibility: New component system can coexist with older implementations during transition
- Team Training: Documented how to use the library and why consistency matters
Technical Architecture Decisions
Component Structure & Reusability
Decision: Build each component with clear input/output contracts, making them reusable across different contexts.
Example: The Button component accepts size, variant (primary/secondary/danger), disabled state, and icon props. By being specific about what can be customized, we prevent the proliferation of button variants while remaining flexible.
Benefit: Developers do not have to make styling decisions for every button, the library makes those decisions. They can focus on functionality and behavior.
Accessibility as Foundation
Decision: Every component includes accessibility features by default, including proper ARIA labels, keyboard navigation, and focus management.
Why It Matters: For an enterprise product, users include people with disabilities. Making accessibility optional means it gets neglected. Building it into every component means the entire product is accessible.
Implementation: Components tested with screen readers, keyboard navigation tested, color contrast verified against WCAG standards.
Responsive Design
Decision: Design all components mobile-first, ensuring they work on all screen sizes.
Reality Check: Enterprise applications are traditionally desktop-focused. However, end users increasingly access systems on tablets and mobile devices. Building responsive from the start prevents problems later.
Outcome: Cirrus works on mobile and desktop with shared component behavior, reducing separate UI implementation paths.
Impact & Outcomes
Development Velocity
With the design library, new features could be built faster. Developers did not need to design buttons or form inputs, they used library components. This freed time to focus on business logic and user workflows rather than low-level UI decisions.
Product Consistency
The product looked cohesive. Users navigating different modules recognized consistent patterns. This reduced cognitive load and increased confidence in the product. Enterprise customers appreciate this consistency, it signals professional quality.
Scalability
As new developers joined the team, they had clear guidance on how to build UI components. The design library ensured that new code followed the same patterns as existing code. This reduced code review friction and onboarding time.
Accessibility Compliance
By building accessibility into components, the entire product became accessible by default. This was foundational. Enterprise customers, especially government and education institutions, have accessibility requirements. This improved Cirrus's product quality and reliability.
Brand & Visual Identity
The design system created a cohesive visual identity for Cirrus. Users recognized the product's aesthetic across all interfaces. This contributed to brand strength and professional perception.
Challenges in Driving Change
Challenge: Adoption & Buy-In
Problem: Existing code didn't use the design library. Different developers had different preferences for how to build components. Getting everyone to adopt the system required coordination.
Solution:
- Led design system workshops to explain adoption rationale and migration path
- Made adoption practical: clear documentation, good examples, quick onboarding
- Started with new features (no migration burden, just new patterns)
- Gradually encouraged migration of existing code
Challenge: Balancing Flexibility and Consistency
Problem: Design systems can be too rigid. Developers sometimes need components that don't fit the standard patterns. Overly restrictive systems breed workarounds.
Solution: Built components with appropriate customization points. Buttons can take various sizes and variants, but not arbitrary styling. Form inputs can be customized, but within the design system constraints. This gives flexibility while maintaining consistency.
Lesson: Good systems provide guidelines, not barriers. They enable developers to work efficiently while maintaining quality.
Key Lessons & Engineering Insights
1. Design Systems Are Organizational, Not Just Technical
Building a design system is not just about creating components, it is about establishing shared conventions that help teams work together more effectively. This requires change management, communication, and alignment.
2. Consistency at Scale Requires Structure
As products grow and teams expand, maintaining consistency becomes increasingly difficult without explicit structure. Design systems provide that structure. They prevent the slow accumulation of inconsistencies that make products feel unpolished.
3. Accessibility Should Be Foundational, Not Afterthought
Building accessibility into every component, from the start, is easier and more effective than retrofitting it later. When accessibility is a core principle of the design system, it becomes mandatory by default.
4. Documentation Determines Success
A design system with poor documentation is ineffective. Comprehensive and clear documentation, with examples and usage guidelines, determines whether developers actually use the system.
5. Design Systems Enable Team Scaling
As teams grow, coordinating on UI/UX consistency becomes harder. A good design system scales, new developers can join and immediately understand "how we do UI." This is critical for scaling teams efficiently.
6. Enterprise Products Benefit Most From Systems
Enterprise products with broad module surfaces accumulate inconsistency quickly. A design system is the mechanism that keeps behavior and UI predictable as teams and features scale.
What This Project Demonstrates
My maintenance ownership of the Springbrook Design Library shows:
Leadership Without Title
Led a system-wide initiative that changed team execution patterns without requiring formal authority.
Systems Thinking
Prioritized interoperable patterns and consistency rules across modules, not isolated component wins.
Change Management
Drove adoption with documentation, workshops, and migration patterns instead of top-down mandates.
Enterprise Product Thinking
Applied accessibility and consistency as hard product requirements for enterprise workflows.
Team Productivity Multiplier
Reduced UI rework and increased delivery speed by standardizing high-frequency interface patterns.