Genesys UI React components library

React component library that provides accessible, consistent UI elements for enterprise apps, with interactive Storybook documentation for easy use.

ReactStyled componentsTypeScriptStorybook

Github repository SB documentation

My Role

I co-created a React-based component library built with TypeScript and Styled Components to unify Devo's design system across products. My goal was to ensure design-code consistency and improve the developer experience.

Overview

The component library was conceived as a bridge between design and development at Devo. Built with React, TypeScript, and Styled Components, it formed the foundation of our design system, enabling consistency and scalability across products.My role combined design leadership with front-end implementation, ensuring visual fidelity and usability were preserved from Figma to code.

The initiative wasn't just about components, it was about building a shared language between teams. By aligning design tokens, interaction patterns, and documentation, we created a unified toolkit that accelerated delivery and simplified collaboration.

The Challenge

Before the library existed, each team developed its own UI elements, resulting in fragmented user experiences and inconsistent visual quality. Design handoffs were time-consuming, and developers often had to rebuild components from scratch without a clear source of truth. Maintaining cohesion across multiple products became increasingly difficult.

BeforeTwo examples of sections before Genesys UI. Components were defined inconsistently: varying font sizes, help blocks, filters, etc.

AfterTwo examples of sections after Genesys UI. We now use the same components across the product, greatly improving consistency.

Process & Collaboration

I worked directly on the codebase with frontend engineers, creating components, writing documentation, and setting up Storybook as the central hub for the design system. This hands-on approach bridged gaps, addressed challenges in real-time, and ensured the library met both design and technical standards.

In addition, there was close collaboration between designers and engineers. We mapped existing inconsistencies, defined shared goals, and translated the visual language into reusable patterns. Regular design-dev syncs, version reviews, and feedback loops validated every decision.

Design & Code Alignment

Colors, typography, spacing, sizing, transitions, shape, and elevation were defined as tokens to ensure consistency and flexibility. Tokens were integrated in both Figma and code, allowing designers and developers to work with the same visual language.

The design tokens library output was integrated with Figma using variables. This ensures the same theme in React components and Figma, maintaining 100% design-to-code fidelity.

Design tokens documentationDesign tokens documentation created in Storybook, so both designers and developers can check the available tokens for colors, typography, spacing, sizing, etc. We have an advanced search system to find tokens easily; for example, filtering by text, regex, schema (dark/light), format (JS, JSON, CSS...) and by the naming category."

Single source of truth for Design tokensThis a detail of the Figma library showing the design tokens integrated as Figma variables. This way, designers can use the same tokens defined in code, ensuring 100% consistency between design and development.

Development Approach

The library was built in React with TypeScript using Styled Components for modular, themeable styling. Each component resides in its own folder (logic, styles, and stories combined) making the codebase predictable and maintainable.

I helped shape a monorepo architecture designed for scalability and collaboration. Each package has a clear purpose: core components, utilities, tables, uploaders; all aligned under a single design language.

This is the main structure of the project:


  / (root)
  ├─ .github/
  │   └─ … (workflows, templates)
  ├─ .storybook/
  │   └─ … (Storybook config)
  ├─ packages/
  │   ├─ core/
  │   ├─ color/
  │   ├─ upload/
  │   ├─ datetime/
  │   ├─ code/
  │   └─ table/
  ├─ stories/
  │   └─ getting-started/
  ├─ test/
  │   └─ … (several tests)
  ├─ CHANGELOG.md
  ├─ README.md
  ├─ package.json
  ├─ tsconfig.json
  └─ … other configuration files (prettierrc, npmrc,…)

And this is the main structure of the core package:


/packages/core
├── /src
│   ├── /components
│   │   ├── /Button
│   │   │   ├── /components
│   │   │   │   ├── /ButtonAddon
│   │   │   │       ├── ButtonAddon.tsx
│   │   │   │       ├── StyledButtonAddon.ts
│   │   │   │       ├── declarations.ts
│   │   │   │       └── index.ts
│   │   │   │   ├── /ButtonAddon
│   │   │   │   ├── /ButtonBadge
│   │   │   │   ├── /ButtonContainer
│   │   │   │   ├── /ButtonDropdownIcon
│   │   │   │   ├── /ButtonIcon
│   │   │   │   ├── /ButtonLabel
│   │   │   │   ├── /ButtonLoader
│   │   │   │   ├── /ButtonSelection
│   │   │   │   └── index.ts
│   │   │   ├── Button.mdx
│   │   │   ├── Button.stories.tsx
│   │   │   ├── Button.test.tsx
│   │   │   ├── Button.tsx
│   │   │   ├── constants.ts
│   │   │   ├── declarations.ts
│   │   │   ├── helpers.tsx
│   │   │   └── index.ts
│   │   ├── /Input
│   │   ├── /Modal
│   │   ├── ...
│   │   └── index.ts
│   ├── /constants
│   ├── /declarations
│   ├── /helpers
│   ├── /hooks
│   ├── /styled
│   ├── /typeFunctions
│   └── /utils
│   ├── /stories
│   │   ├── /components
│   │   │   ├── /StoryWrapper
│   │   │   └── /styled
│   │   ├── /partials
│   │   └── /utils
├── package.json
├── tsconfig.json
├── README.md
└── … other configuration files (prettierrc, npmrc,…)

Anyway, this is just an excerpt of the project structure to give you an idea of how it's organized. This is the link to Github repository in case you want to check more details

Storybook served as both a documentation hub and a testing environment, allowing teams to preview props, states, and variants interactively. Components were versioned and published via npm, ensuring smooth updates and CI/CD integration across multiple applications.

Impact & Outcomes

Consistency and accessibility

The new system reduced handoff time and unified over 100 screens under a single visual language using the same UI components. In addition, all components meet AA accessibility standards.

Ready-to-use

Beyond metrics, the system strengthened collaboration. Engineers benefit from reliable, flexible components ;while designers are confident in implementation. Specially, due to I was implementing and creating the documentation of the library. It also improved onboarding for new team members, who could now build with clarity and consistency from day one.

Consistency and accessibility

Components and documentation facilitate long-term maintenance and easy scaling across applications.

Storybook documentation for componentsTwo examples of the Storybook documentation for one of the system components (Button), showing the different properties and states the component can have, as well as usage examples. The component page is usually structured in these sections: how to import, basic usage, variants and states, usage tips, internal and related components as well as its props table.

Playground for components in StorybookThis is a detailed view of the props playground in Storybook, in this case, the Button component. It represents one of the core sections of every component in the library, where designers and developers can interactively test different properties and instantly see the results. They can also copy the corresponding code snippet for any selected configuration.

Complex componentsThe library doesn't just include foundational components (Button, Badge, Tag, or Input), it also supports complex, composite ones. The example above shows a date-time range floating picker, a good demonstration of how these advanced components are built from smaller, foundational pieces within the same atomic ecosystem.

Learnings & Next Steps

Building the component library showed that the challenge extends beyond the code. Documenting everything: use cases, naming conventions, feedback loops ensures alignment and long-term success.

Next steps focus on improving consistency across components: prop naming, interfaces, hook usage, and internal structure. We also plan to phase out Styled Components in favor of a class-based approach powered by a custom PostCSS library.