Work
Discovery / Research / Implementation QA
Thrive
Study Case
Strata - Thrive Design System
Client
Thrive
Technology Used
Figma / Contrast WCAG Tool / Miro
As Staff Product Designer, I led the creation of Strata — Thrive’s modern design system. Our shift from Ember.js to Tailwind and ultimately to Mantine enabled full componentization, theme scalability, and WCAG accessibility across products.
BACKGROUND
The company, a SaaS platform with a mature Ember.js frontend, faced challenges maintaining and scaling their product. Modernizing to React offered:
- Better access to talent in the market
- A broader ecosystem
- More flexibility for future growth
As the lead product designer, I worked closely with engineering to ensure our approach balanced user experience, accessibility, and operational efficiency.
THE FIRST ATTEMPT: TAILWIND CSS
Our initial plan was to pair React with Tailwind CSS, leveraging its utility-first approach to build a fresh, modern UI. The design team loved the flexibility — it aligned well with our new design system vision.
However, we quickly encountered a migration bottleneck:
- Developers needed to manually build every component from scratch.
- Tight sprint cycles left little time to design, build, test, and polish new components.
- Ensuring accessibility for each component increased QA time.
The lack of a mature, consistent component library was slowing the migration — pushing timelines and increasing operational costs.
THE CHALLENGE
What do we want to accomplish?
Our goal was to accelerate the React migration by creating a design system that balanced developer speed, accessibility, and brand consistency.
We wanted a system that:
- Enabled engineers to build without relying on custom components for every feature
- Ensured accessibility and WCAG compliance across reusable UI
- Reflected our brand visually but was flexible for growth and white labelling
- Reduced onboarding time for new team members
- Lowered long-term design and QA cost
My Role:
As the sole designer, I was respondsible to work with engineers and managers to conduct research and discover forthe desired outcomes for the design system and what we can do better. I was responsible for the execution of the visual assets and documentation
THE APPROACH
AUDIT AND PREPARATION
Laying the groundwork to scale
When I joined Thrive, Inherited an undocumented group of bootstrap components that would quickly buckle under the weight of designs. Over my first year I used Atomic Design Principles to standardize typography and colours to create/update reusable components to increase consistency across design and implementation. However the inherited components themselves were brittle and did not cascade, and as a result it was costly to make even minor adjustments to fix errors in the components.
Phase 1: Tailwind CSS
Our initial plan was to pair React with Tailwind CSS, leveraging its utility-first approach to build a fresh, modern UI. It aligned well with our Design System Vision Statement:
To esablish a lightweight, utility-first design system that empowers developers to build accessible, consistent, and scalable UI componenets with flexibility - enabling faster delivery during the Ember-to-React migration while laying the groundwork for a robust long-term design language.
THE VISION
We envisioned a design system that:
- Used Tailwind's composability to define shared patterns (buttons, forms, cards).
- Maintained visual consistency with our legacy Ember components
- Empowered developers to work faster with minimal abstraction
- Embedded WCAG-compliant accessibility into every base component.
Tailwind's configurability allowed us to define design tokens (e.g. spacing, colour palette, typography, border radius etc) that matched both our branding and the look and feel users were accustomed to.
WHAT WORKED - AND WHAT DIDN'T
While the approach gave us flexibility and design control we experienced bottlenecks as the business grew and sprints became feature focused.
- Developers were spending significant time rebuilding Ui patterns.create
- Accessibility required manual implementation andQA for each component.
- Reusable components like modals, dropdown, and date pickers were time intensive to build and test.
- With pressures to deliver features fast, the utility-based system created velocity drag.
TAKEAWAY & LEARNINGS
The rapidly evolving buisness needs revealed that we needed a more scalable, opionated solution that didn't compromise quality or delivery speed.
This realization led us to evaluate component libraries that could bridge the gap between control and speed - ultimately guiding us toward Mantine
Phase 2: Adopting Mantine - Balancing Speed, Flexibility & Product Quality
Following the slowdowns we faced during our Tailwind-first approach, we revisited our strategy. Our product team had a clear mandate:
Ship faster, without compromising accessibility or maintainability.
As a SaaS startup, we needed to reduce operational complexity and move quickly — especially as our customer base expanded and feature demands accelerated.
WHAT WE WERE SOLVING FOR
We set out to find a component library that would:
- Accelerate feature delivery without needing to reinvent UI primitives.
- Support accessibility out of the box, so we weren't QA-ing every ARIA label manually.
- Offer a flexible design system, so we didn't lose the visual consistency we'd established with Tailwind.
- Align with out previous Ember component patterns, easing the mental load for both designer and developer.
EVALUATION PROCESS
We compared several leading React UI llibraries based on:
WHY WE CHOSE MANTINE
Mantine hit the sweet spot:
- Speed: Developers could use Mantine Components (e.g., Button, Modal, Card) with sensible defaults and ship in hours, not days.
- Theming: We could mirror our existing Tailwind styles with Mantine's theme provider, giving visual consistency without rigid constraints
- Flexibility: Matine support both prebuild and headless patterns - so we weren't locked in, but we weren't starting from scratch either
- Accessibility: Inputs, dialogs, menus, and transitions were WCAG-compliant out of the box, drastically reducing time spent on edge cases and QA.
- Developer Onboarding: New engineers picked up Mantine quickly, accelerating onboarding and reducing context switching from Ember.
RESULTS
40-50% faster feature development
Feautre velocity noticeable improved - product teams were able to deliver new pages and flows in significantly less time
Reduced Design & QA overhead
Reusable, styled, and accessible components meant less review time from design and QA - freeing teams to focus on higher leverage work.
Consistent
Feautre velocity noticeable improved - product teams were able to deliver new pages and flows in significantly less time
Creating a component library of 55+ components
Using the Mantine UI kit as a baseline, each component was meticulously analyzed and optimized to modernize our previous look and feel while minimizing the engineering effort to deploy components.
1000+ variants to hold component states & variables for easy component modification
Using the Mantine UI kit as a baseline, each component was meticulously analyzed and optimized to modernize our previous look and feel while minimizing the engineering effort to deploy components.
DOCUMENTATION
Creating a Source of Truth
A design system is the source of truth for your company's visual design language. Working closely with front-end engineers to realize their main goals for the design system:
- Create robust documentation on usage of different styles and components across products
- Create design tokens that would match their respective CSS styles across codebases
- Allow this to be a tool to onboard new engineers into our org
Why are we documenting?
A design system is more that just a UI kit. Every UI component would have detailed usage documentation for designers, engineers or any team member to understand. Mantine components allows for design updates to base components that align closer to the original brand while maintaining a updated and modern poslished feel.
Using Design Tokens
Design tokens are an integral part to creating a cross-functional design system. I worked with the engineers to understand the naming conventions fo their CSS classes. Using those classes I was able to construct design tokens that would easily match those CSS classes to create value for both designers and engineers.
RESULTS
40-50% faster feature development
Feautre velocity noticeable improved - product teams were able to deliver new pages and flows in significantly less time
Reduced Design & QA overhead
Reusable, styled, and accessible components meant less review time from design and QA - freeing teams to focus on higher leverage work.
Consistent
Feautre velocity noticeable improved - product teams were able to deliver new pages and flows in significantly less time
