RiseSmart: Designing for scale: 100+ countries, 28 languages, and WCAG 2.2 compliance

Context

 

Risesmart’s platform supports career transition services for users worldwide. As the product expanded across geographies and into larger enterprise deals, we faced increasing complexity: multiple languages, regional expectations, and rising accessibility requirements.

Without a shared foundation, the interface began to diverge across the product, making it harder to maintain quality, scale efficiently, and meet enterprise standards.

 

My role

 

  • Led and managed a 4 person product design team

  • First design leader, built out design practice, including new user research function, sprint-based processes, collaborative rituals (retrospectives and reviews), career development, and design systems.

  • Led the initiative to establish a scalable, accessible design system and global product standards.

 

Impact

 

  • Created a design system used across the product

  • Enabled faster feature development across teams

  • Improved support for multilingual users

  • Advanced the product toward WCAG 2.2 compliance

  • Helped address accessibility gaps impacting enterprise sales

 

The Problem

 

As Risesmart expanded internationally and upmarket, several issues emerged.

 

1. Inconsistent UI across the product

 

Due to regulatory, service capability, language, and customer differences around the world, we had a highly flexible product but it was brittle and inconsistent. This created:

 

  • Fragmented user experiences

  • Redundant design and engineering work

  • Difficulty maintaining quality at scale (or often even knowing what a specific end user would see)

 

2. Internationalization exposed structural issues

 

Supporting multiple languages introduced complexity we weren’t prepared for:

 

  • Text expansion (e.g., German strings 30–40% longer)

  • Layout breakage in translation

  • Hard-coded strings

  • Components not designed for dynamic content

 

Every localization effort required manual fixes.

 

3. Accessibility gaps were limiting growth

 

As we pursued larger enterprise contracts, accessibility became a critical requirement. We identified that:

 

  • The product was not aligned with WCAG 2.2 standards

  • Accessibility was inconsistently handled (or not considered) across features

  • We lacked a systematic approach to accessibility in both design and engineering

 

This had real business impact because we were losing or at risk of losing enterprise deals due to lack of demonstrated accessibility compliance.

4. Product velocity was slowing

 

Teams were repeatedly solving the same problems:

 

  • Rebuilding common UI patterns

  • Debating already-solved design decisions

  • Fixing inconsistencies and accessibility issues retroactively

 

This created friction and slowed delivery.

Identifying the Opportunity

Rather than addressing each issue separately, we reframed the problem:

 

Risesmart needed a scalable product foundation that supported global, accessible experiences by default.

 

This required:

 

  1. A shared design system

  1. Internationalization-ready components

  1. Accessibility built into the system (not added later)

  1. Clear product standards across teams

 

The goal was to make quality, accessibility, and scalability the default outcome.

 

Approach

 

1. Audit the existing product

We conducted a comprehensive audit across the platform.

 

We evaluated:

  • UI components and patterns

  • Layout systems

  • Internationalization readiness

  • Accessibility gaps (contrast, semantics, interaction patterns)

 

This revealed:

 

  • Significant duplication and inconsistency

  • Widespread accessibility issues

  • Components not built for dynamic or global content

 

2. Define core design primitives

 

We established foundational design rules that supported both scalability and accessibility.

 

Typography

 

  • Scalable hierarchy

  • Readability across screen sizes

  • Consideration for legibility and contrast

 

Spacing system

 

  • Consistent spacing scale

  • Predictable layout behavior, especially when certain sections were enabled / disabled

 

Color system

 

  • Standardized tokens

  • Designed to meet color contrast requirements (WCAG 2.2)

 

This created a cohesive and accessible visual language.

 

3. Build accessible, reusable components

 

We developed a core component library with accessibility built in.

 

Examples:

 

  • Buttons

  • Form inputs

  • Alerts

  • Navigation components

  • Data display elements

 

Each component included:

 

  • Defined interaction states (hover, focus, error, disabled)

  • Keyboard accessibility considerations

  • Semantic structure guidance

  • Accessibility requirements aligned with WCAG 2.2

 

This ensured accessibility was systematically applied, not dependent on individual designers or engineers.

 

4. Design for internationalization

We built global readiness into the system.

 

Flexible layouts

  • Components adapted to variable text lengths

 

Text expansion testing

 

  • Simulated longer translations during design

 

Localization support

  • Externalized strings

  • Avoided layout assumptions tied to English

This reduced localization friction and rework.

 

5. Partner with engineering on implementation

 

Adoption required tight design–engineering alignment.

 

We collaborated with engineering to:

 

  • Map react components to frontend architecture

  • Ensure reusable, accessible implementations

  • Align on standards for semantic HTML and interaction behavior

 

The goal was to make the system:

The fastest, safest way to build UI that’s accessible.

Results

 

Increased product consistency

A unified design language improved the overall user experience across the platform.

 

Faster development and reduced rework

Teams reused established components instead of rebuilding patterns, reducing redundancy and improving speed.

 

Improved accessibility approach

Accessibility became part of the product foundation rather than an afterthought.

 

  • Reduced risk in enterprise sales conversations

  • Established a path toward WCAG 2.2 compliance

  • Increased confidence in meeting accessibility expectations

 

Better global scalability

The platform handled multiple languages more reliably, with fewer localization issues.

 

Stronger cross-functional alignment

The design system created a shared language across design and engineering, reducing ambiguity and repeated decision-making.

 

What I Learned

Designing for scale means designing for constraints:

 

  • Globalization

  • Accessibility

  • Organizational complexity

 

A design system is most effective when it encodes these constraints into the product itself.

 

The key insight

Accessibility and internationalization shouldn’t be separate initiatives, they should be built into the system that defines how the product works.