Collage of Thinx UI

Thinx

Thinx

Building a scalable design system to unify the Thinx ecommerce experience, improve consistency, and enable faster, higher-quality product development.

Design Systems

eCommerce

UX/UI Design

eCommerce

Product Domain

ecommerce

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 BTWN, enabled tri-brand unification, and gave the team the infrastructure to ship faster, more consistently, and at scale.

BEFORE

Old Desktop Thinx Homepage

AFTER

Revised Desktop Thinx Homepage
Revised Desktop Thinx Homepage

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.

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.

Desktop Thinx Collections Page
Desktop Thinx Collections Page
Desktop Thinx Product Detail Page
Desktop Thinx Product Detail Page

What Was Built

The system covered the full scope of three ecommerce 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.

Desktop Thinx Shop 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, no alignment on what "responsive" actually meant in practice.

I worked directly with the front-end developers to establish that shared language. Component names in Figma matched component names in code. States, variants, and responsive behaviors were specified precisely, not left to interpretation. Regular design and development reviews kept the two environments in sync as the system evolved.

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.

Copyright © 2026 by Michelle Flacks

Copyright © 2026 by Michelle Flacks

Copyright © 2026 by Michelle Flacks