Project Overview
TL;DR: Match.com and the brands under Match Group each maintained their own component library, on both the design side and the development side. I helped build one enterprise design system that could be themed to every brand, so a component was built once and an identity was a theme. Alongside it, I redesigned the .mobi site, carried that look into the Android app, and built a working prototype that ran with no connection for a commercial shot in NYC.
Role: Sr. Product Designer, member of a 5-person design team at Match Group, the company behind Match.com, Tinder, Hinge, OkCupid, Plenty of Fish, and more.
The Challenge & Context
Every brand had its own copy of everything.
Match Group is a family of brands, and each one had its own component library in design and its own in code.
Match.com, Tinder, Hinge, OkCupid, Plenty of Fish, Meetic, DisonsDemain, LoveScout24, Neu.de, The League, Azar, Pairs, BLK, Chispa, Her, Archer, OurTime, BlackPeopleMeet.
That meant the same button, form field, and profile card was built and maintained many times over, and every copy drifted from the others. A fix to a shared pattern turned into 100's of separate changes across each site's individual libraries, with design and engineering both redoing the same work. Brand teams could not easily reuse what another team had already solved, and consistency depended on who remembered to update what.
The real problem was not that the brands looked different. They should. It was that looking different had been solved by rebuilding everything, instead of changing only what needed to differ.
The Process & Decision-Making
Decide what is shared and what is themed.
Separating what a component does from how it looks
I audited the existing libraries to see where components overlapped and where brands genuinely differed. The central tension was how to be consistent without making every brand look the same. Tinder, Hinge, and Match.com serve different people with different personalities, so a shared system could not be one look applied everywhere.
The answer was to draw a line down the middle of every component. Behavior, structure, accessibility, and interaction states are built once and shared. Color, type, spacing, and shape live in brand-level tokens that each theme overrides.
A token architecture that makes theming a data change
To make that line real, the system is organized in layers. Global tokens hold raw values. Semantic tokens give them meaning, like the primary action color. Brand tokens override those meanings per theme. Components only ever read tokens, never raw values, so changing a token once updates every component that uses it, in every theme.
Designing one component for every context it will live in
A component is never one screen. A text field has to work on a 360px .mobi page, in iOS with Dynamic Type, in Android with Material 3, and on a desktop at 1280px and up, and in each of those it has to hold up in its default, focus, error, and disabled states. I designed and tested each component as a single matrix of product, viewport, platform, and accessibility state, instead of as a set of isolated screens, so a gap in any cell showed up before it reached production.
Building the design and code libraries together
I worked with engineering to build the coded library alongside the design library, so both were organized around the same names and the same tokens. A designer and a developer could refer to button.bg and mean the same thing. Rollout was carfully planned as each site needed to now reference the new components. A backend unification effort was also taking place concurrently, so the front-end was refactored to acoomodate the new design system.
The Figma library and the coded library share the same vocabulary. A Figma button with variant, size, icon, and state properties maps one to one onto the props of the React Button, and the same component appears in Storybook with its controls, docs, accessibility checks, and visual tests. Its background reads from a CSS custom property, var(--color-action-primary), which resolves through the brand tokens. An engineer opening Figma and a designer opening Storybook find the same names in both places.
The Solution & Final Design
One component set, many identities
The same components, with only the theme changed, produce a distinct identity per brand: a different primary color, typeface, corner radius, and surface. Adding or restyling a brand became a theming task rather than a rebuild, and a fix made once reached every site that used the component.
Beyond the component library
A library of buttons and fields does not solve the problems product teams actually have. Searching and filtering, validating a form, showing an empty state, and handling loading all behave the same way across products, and each team was solving them again. I defined these as interaction patterns that sit above the components, and mapped how they build up into full flows like onboarding, matching, and a safety check-in. Teams could then solve a flow once and reuse the answer, instead of rediscovering it per brand.
Documentation that removes the guesswork
Every component ships with usage guidance, dos and don'ts, anatomy, code, and accessibility rules, in the same place the code lives. For the text field that meant a plain rule for each failure we kept seeing, such as never relying on placeholder text as the only label, along with the accessibility requirements: a 4.5:1 minimum contrast, a visible focus ring, a textbox role paired with a label, and a 44 by 44 pixel target size. The goal was that no engineer or designer had to ask how a component should be used.
Adoption and governance
A design system has no value if teams ignore it, so I treated adoption as part of the product. Contributions followed one path: a team proposes a need with its use case, design and engineering review it in a weekly triage, the contributor builds it in Figma and code, it ships with a version number, a changelog, and an announcement, and office hours and migration help support the teams moving over.
When a team pushed back, the response was to show the cost of duplicated work and QA time, offer a pairing session instead of a mandate, and take the missing need in as a contribution.
Retiring old patterns without breaking production
Replacing more than sixteen libraries meant the old patterns could not simply disappear. Each one followed the same path. The current pattern stays stable in every live app. A release ships the replacement and marks the old component deprecated, with warnings in the console and the docs. A codemod rewrites usages so teams can move on their own schedule. The old component is removed only once its usage reaches zero in telemetry. [Add: how you actually tracked usage and which breaking changes were hardest.]
Mobile that feels like one product
On mobile, I started with a complete redesign of the .mobi site, working closely with the web team and aligning with the iOS and Android teams. Later I took what I had implemented on .mobi and carried the overall look and feel to Android, focusing mainly on the browse page and settings. A member moving between the .mobi site and either app should see one experience, not three.
The key screens, shown on iOS.
A prototype for a commercial, with no connection
Match was filming a commercial in NYC, in a place without reliable service. I built a working, clickable prototype that could be loaded straight onto a phone and ran with no internet connection. It was based on the content Match was targeting in the commercial so the experience on camera was stable and effective for the shoot.
A video portal for a marketing partnership
I also worked with the marketing teams on both sides of a partnership with Matthew Hussey, where Match and Matthew released a series of videos. I built a microsite video portal to house them, with creative calls to action.
Impact, Outcomes & Learnings
One system to maintain.
Without hard metrics, the change is still concrete. Where each brand once maintained its own library, there is now one system to maintain and update, and a fix made once reaches every site that uses it. The commercial prototype gave the production team a reliable experience to film, even where there was no connection.
Building one system for many brands taught me that a design system's real job is deciding what must be shared and what must stay different. Putting behavior in the component and identity in the tokens let each brand keep its personality while the maintenance burden dropped. The offline prototype taught the opposite lesson from a different angle: sometimes the most useful thing a designer can build is the smallest thing that works reliably in a hard situation.