Building a scalable, multi-brand design system in Figma to unify three e-commerce platforms under a single component architecture.
Design Systems
e-Commerce
UX/UI Design
Branding
Product Domain
Design Systems
Role
UX/UI Designer
Company
Thinx Inc.
Industry
Health & Wellness, Consumer Products
Impact
Increased total revenue by $1,024,950 within two months of launch
Speax conversion rate reached 4.32% (+105.7% uplift)
Improved product clarity and reduced friction across PDP, education, and checkout flows
Enabled faster iteration and consistency across three brands through a shared system
Reduced reliance on one-off design and manual updates across the platform
Overview
When I joined Thinx, the design process was inherited from a print and brand team. Pages were designed in Illustrator and handed to developers as PDFs and JPEGs. There were no reusable components, no shared tokens, no documentation, and no responsive logic. Every design decision was a one-off.
As the company scaled into three distinct brands, this lack of system created friction across both the user experience and internal workflows.
By the time we finished, we had built three interconnected component-based design systems on top of a shared universal foundation. These systems powered the redesign of Thinx, Speax, and Thinx Teens, enabled tri-brand unification, and gave the team the infrastructure to ship faster, more consistently, and at scale.
BEFORE
AFTER
My Role
I was the UX designer responsible for the component architecture, interaction design, and design system development across all three brands. I worked within a cross-functional team that included a UX research director, a UX researcher, visual designers, a creative director, and a development team. My work sat at the intersection of research, product, and visual design: I translated behavioral insights into UX structure and component logic, and collaborated directly with visual designers and developers to bring the system to production.
This work also spanned the team's transition from Sketch to Figma, which I led, rebuilding the component library as a cloud-native standalone file for the first time and establishing Figma as the team's authoritative design and system tool.
The Problem
Thinx had grown quickly from a single direct-to-consumer brand into a three-brand company but the product experience had not scaled with it. We served distinctly different customer segments: Thinx for period underwear, Speax for bladder leak underwear, and Thinx Teens for teen period underwear. Each brand had its own website, its own visual identity, its own customer, and its own set of purchase barriers.
The design process hadn't kept pace with that growth. Without a component system, every new page required rebuilding from scratch. Design inconsistencies accumulated across the product. Developer handoffs were slow and imprecise. And when we needed to roll out changes, there was no leverage: a fix on one page had to be manually replicated everywhere else.
The goal of the design system work was not just to make design faster. It was to create the infrastructure that would allow three distinct brands to feel coherent as part of a single company, while each maintaining the specific visual and tonal identity its customer expected.
The Approach
Rather than building three separate systems independently, I approached this as a two-layer architecture problem.
The first layer was a Universal Design System: shared foundations that applied across all three brands. This included the structural logic of the components, the interaction patterns, the spacing and grid system, the accessibility rules, and the responsive behavior across breakpoints. The universal layer established the rules that all three brands would follow.
The second layer was brand-specific: each of Thinx, Speax, and Thinx Teens had their own token sets applied on top of the universal foundation. Color, typography, iconography, and visual tone varied by brand. But the component structure, the interaction logic, and the responsive behavior were consistent underneath.
This architecture meant that a developer building a product card for Speax and a developer building a product card for Thinx were working from the same component. The brand layer made them look different. The universal layer made them behave the same.
Thinx Desktop Collections Page, Thinx Desktop PDP
System Architecture
The system covered the full scope of three e-commerce platforms:
Core foundations: color tokens, typography scales, spacing system, grid and layout, iconography, accessibility standards (WCAG 2.1).
Navigation components: tri-brand navigation, brand-specific navs, mobile navigation, account and cart integration.
Commerce components: product cards, collection page layouts, product detail pages, size selectors, color swatches, quantity controls, bundle builders, add-to-cart flows.
Content components: homepage modules, editorial layouts, educational content templates, FAQ components, review systems with fit indicators.
Supporting flows: checkout, account management, referral, post-purchase, email capture.
Each component was designed for all breakpoints simultaneously, documented with usage guidelines, and built in close collaboration with the development team to ensure design and code stayed in parity.
The system was built as a standalone Figma library file, separate from all product and project files, and published across three brand workspaces. Components followed atomic design principles: base elements like color, typography, and spacing tokens formed the foundation, with molecules and organisms built on top. Brand-specific token sets for Thinx, Speax, and Thinx Teens were applied as overrides at the brand layer, meaning the same button component rendered correctly in all three brand expressions without any structural changes to the underlying component.
Thinx Desktop Meganav
The Challenge of Three Brands
The hardest design problem in the system was maintaining brand differentiation without creating three entirely separate codebases. Each brand needed to feel distinct, because their customers are genuinely different: a Speax customer is a woman in her 50s managing a sensitive health condition, a Thinx Teens customer is a pre-teen buying her first period product, and a Thinx customer is a younger woman who identifies with the brand's activist positioning.
The solution was deliberate constraint. I defined which variables were allowed to differ by brand (color, typography, photography style, iconography tone) and which were fixed across all three (component structure, interaction patterns, spacing, accessibility behavior). This gave the visual designers meaningful creative latitude within each brand while keeping the system coherent and the development implementation efficient.
Working with Developers
One of the most important parts of this project was building a genuine working relationship with the development team. Before this work, design and development operated largely in silos. Developers received finished designs and built them as best they could. There was no shared vocabulary, no component naming convention, and no alignment on what responsive actually meant in practice.
To close that gap, the team adopted Storybook as a shared reference layer between design and code. Component names in Figma matched component names in the Storybook library. States, variants, and responsive behaviors were specified precisely in both environments, not left to interpretation on either side. This gave developers a single source of truth that lived alongside, and stayed in sync with, the Figma system.
Regular design and development reviews kept Figma and Storybook in parity as the system evolved. This handoff protocol became the standard across all three brands.
Impact
The system shipped as part of the full Thinx Inc. redesign, which produced these results across all three brands within two months of launch:
Total revenue increase: +$1,024,950. Speax +15.9%, Thinx +14.7%, Thinx Teens +27.1%. Speax conversion rate 4.32%, a 105.7% uplift.
Beyond the launch metrics, the system's lasting impact was operational. New pages and campaigns could be built from existing components rather than from scratch. Design changes could propagate across the platform through the token layer rather than requiring manual updates to every screen. The development team could ship faster and with fewer inconsistencies. And when new designers joined the team, the system gave them a clear vocabulary for the product.
Reflection
The thing I underestimated going into this project was how much of design system work is change management rather than design. Building the components was the tractable part. Getting a team that had never worked with a component-based system to actually use it consistently, and getting developers who were used to building from PDFs to trust Figma as a source of truth, required a lot of ongoing communication and relationship building that I didn't initially plan for.
If I were doing it again I'd start the developer collaboration earlier. We lost time rebuilding things that had already been designed because the handoff process wasn't established yet. Getting that alignment in place from the first sprint would have compressed the timeline significantly.