9:14:05 UTC
Design System
RXDS - The system that scaled design across the organization
How I built and maintained the design system that powers every Ramco product - 50+ components, shared language, faster workflows.
Product
Ramco Xperience Design System
Role
UX Design
Timeline
1 Year
0+
Reusable Components
0%
Adoption Rate
0.0
Current Version
0 Month
To initial release
What is RXDS?
RXDS (Ramco Xperience Design System) is the enterprise design system used across the organization to standardize user experiences, accelerate product development, improve accessibility, and create a shared language between design and engineering.
I was a core contributor and maintainer — building and evolving the system alongside the design team. What started as solving design inconsistency became the foundation that every product team now builds on.
" Design systems are not about efficiency - they're about trust. When every component behaves consistently, teams can focus on solving real problems instead of reinventing patterns. "
What we were solving
Before RXDS, every product team was designing and building the same components in isolation. The result: inconsistent experiences, slow handoffs, and wasted effort.
Design inconsistency
A single button existed in multiple styles across products. No shared standards, no alignment, no efficiency.
Repeated redesign
Teams rebuilding the same UI patterns repeatedly. Every product reinventing forms, tables, navigation.
Slow handoff
Design-to-dev was painful. Every component needed redefinition, documentation, and implementation from scratch.
Accessibility gaps
No standardized WCAG compliance. Accessibility standards were inconsistently followed across products.
Wasted effort
Developers rebuilding components, designers recreating variants. No reusable foundation to build on.
No shared language
Designers and developers speaking different vocabularies. Miscommunication on every component.
What we built
RXDS is a complete design infrastructure: component library, design tokens, Figma structure, React implementation, accessibility guidelines, and governance process.
Every component includes anatomy, variants, states, interactions, usage guidelines, and accessibility guidance. This is not just a UI kit — it's a system for making decisions.
Foundation Layer
Design Tokens
Colors · Spacing · Typography · Shadows
WCAG Accessibility
AA compliance · Screen reader support
Custom Ramco Palette
Brand colors · Semantic colors · States
Component Library (50+)
Buttons, Links, CTAs
Primary · Secondary · Tertiary · Icon
Inputs, Selects, Validation
Text · Number · Date · Dropdown · Radio · Checkbox
Menus, Tabs, Breadcrumbs
Header · Sidebar · Pagination · Steps
Tables, Cards, Lists
Data tables · Card layouts · List variants
Toasts, Alerts, Modals
Success · Error · Warning · Info states
Grids, Containers, Spacing
12-column grid · Responsive containers
Shared React components
Every component in Figma has a matching React implementation. Design and code stay in sync. Developers import components from the shared library — no rebuilding from scratch.
Built with Tailwind-based design tokens, so when we update a color or spacing value, it propagates across all products automatically.
Design
Figma component library
Design token definitions
Usage documentation
Accessibility guidelines
Pattern examples
Development
React component library
Tailwind token integration
TypeScript definitions
Storybook documentation
Automated tests
How RXDS evolves
Design systems need governance. We built a process for how teams request new components, how we evaluate those requests, and how updates ship without breaking existing products.
01
Request raised
Team identifies a need for a new component or variant
02
Team discussion
Design system team reviews with the requesting team
03
Need validation
Is this a pattern other teams will need? Or product-specific?
04
Justification review
Does it fit system principles? Can we extend an existing component?
05
Design exploration
Iterate on variants, states, accessibility, documentation
06
Documentation
Write usage guidelines, accessibility notes, code examples
07
Release
Version bump, backward-compatible update, team communication
08
Component Published
Added to RXDS library, documentation, and release notes
RXDS 1.0 → 2.0
RXDS didn't launch perfect. Version 1.0 was the foundation. Version 2.0 came from real product feedback — new patterns, expanded variants, better documentation.
The biggest additions in 2.0: AI-specific patterns (confidence indicators, fallback states, human-override flows) that came directly from building Chia.
What building RXDS taught me
01
Design for scalability, not just current needs
Components must anticipate future use cases. If you design only for today's requirements, the system becomes rigid. Build flexibility in from the start — variants, tokens, and extension points that teams can adapt.
02
Consistency is a product strategy, not a visual decision
Design systems aren't about making everything look the same. They're about creating predictable, learnable patterns that reduce cognitive load. Users learn once, apply everywhere.
03
Documentation is as important as the component
A component without documentation is useless. Teams won't know when to use it, how to use it, or what accessibility requirements apply. Good documentation is the difference between adoption and abandonment.
04
The hardest part is keeping it current
Building RXDS 1.0 took 8 months. Maintaining it and evolving it to 2.0 is ongoing. Products evolve, requirements change, new patterns emerge (like AI workflows). A design system is never done.