Pex Product Redesign
Ground-up frontend rewrite and UX redesign for a music rights tracking platform.
Context
Pex is a content fingerprinting and tracking platform. Music labels and publishers register their content, the system fingerprints it, and Pex's scraping infrastructure surfaces matches across user-generated content platforms. Clients review those matches and take action externally, primarily through YouTube's Content ID. Pex's recognition technology was the most accurate in the space, consistently surfacing uses that native matching and other vendors missed.
The product had been in beta for years, with workflows proven by a small base of heavy users: copyright claiming teams at major music publishers and labels. The customer base sat around 10 clients, small in count but significant in scale. The largest processed hundreds of matches a day. Speed and accuracy were what mattered, because every match was a potential revenue line.
The product was functional but fragmented. Pages used different spacing, different UI patterns, and different visual conventions for the same components, the result of iterative expansion as the product grew. That approach had been right for shipping an MVP and proving out workflows, but with those workflows validated and the product preparing to scale, the inconsistency was holding back the next phase.
Before the company could scale its user base, the product needed two parallel rewrites: a modern frontend stack and a redesigned user experience. As the sole product designer on the team, I led design on the rebuild. I partnered directly with the founder, working alongside one remote frontend engineer.
Making the case for user research
User research wasn't yet a regular part of the product process at Pex. The founder held the customer relationships directly and had a strong product vision. As we prepared to scale, I started advocating for more direct customer access so design, product, and engineering could all build from a shared understanding of how customers worked.
A trip to New York to visit our largest customer came together a few weeks later. I spent the day with the claiming team and their manager, watching them work. The goal was to understand jobs to be done, how the work was structured, how it was divided, what the flow looked like from match to claim.
What I learned helped reframe the rewrite. Pex's biggest customer wasn't using Pex's UI to do their work. They had built their own internal review portal that ingested Pex's match data and presented it in a workflow their team could move through at volume. The Pex interface was more of a data source than a tool.
"The Pex interface was more of a data source than a tool."
Even if the goal wasn't to replace their portal entirely, the implications for scale were clear. The next wave of customers wouldn't have the resources to build their own tooling. If Pex was going to serve them, the product needed to handle those workflows itself: context for verifying matches, organizational logic for divvying up work, fast tagging to clear queues at volume. The trip also opened the door for user research as a normal part of the product process going forward.
Three product bets
The redesign came together from several streams: backlog items the founder had collected from client interactions, usability issues I'd identified through testing the existing product, missing capabilities like proper asset organization, and the workflow observations from New York. Three product bets emerged as the spine of the rewrite.
Match detail modal
The original match feed surfaced copies as rows in a list with a crude review modal. The redesigned match detail gave users an optimized workflow to review and process copies: synced side-by-side video playback of the asset and the copy, paired timelines, and keyboard shortcuts for quick tagging.
Tagging system
Tags were how users got their assigned feed of copies to inbox zero. Every match needed to land in a bucket: claim, dismiss, escalate, hold for review, and other custom tags. The system was designed for keyboard-first speed so a queue of hundreds could be processed without leaving the modal flow.
Expanded collections
Collections gave customers a way to organize their assets into meaningful groups: by team, by catalog, by release. The match feed could be filtered by collection, so a reviewer could easily see and track progress on their assigned copies. Expanded asset management functionality and bulk actions were added to speed up the time needed to create and populate collections.
Together, the three bets reframed Pex from a data source into a tool.
A modular visual language
The existing UI had grown organically through years of beta iteration. Pages had been built one at a time with different page widths, different typographic scales, different conventions for the same kinds of components. That had been fine for the MVP, but with the product validated, the inconsistency was holding back the next phase of growth.
I designed a unified visual language built on modular, card-based components composed from a set of reusable building blocks. Roboto for legibility across data-heavy screens. A clear typographic hierarchy that worked for both lightweight account pages and dense match-review surfaces. Component patterns that could be composed into new flows without redesigning from scratch each time.
Designing the system, not just the screens
The rewrite needed to move fast, with one frontend engineer carrying the implementation. Pixel-perfect designer-to-engineer handoff would have been a bottleneck. We needed a faster loop.
I co-designed a spacing system with the frontend lead, built around repeatable tokens we could both reference. This was pre-Tailwind, before token-based design systems had widespread adoption and standards. The system used a color-coded shorthand: I could sketch a screen, label spacing with the shorthand, and he could implement directly without me producing precise mocks for every screen.
Storybook was the source of truth. Components lived there as a living repo rather than a static document, giving design and engineering a shared reference. Design effort went into refining hero screens and the components themselves; connecting flows only needed enough fidelity to communicate functionality.
Holding the rewrite together
The rewrite was at risk of stalling. The engineering timeline had proven optimistic, multiple work areas sat at 80–90% complete with little shipped, so progress was hard to feel. I stepped in from the design side to help restructure the work: discrete features completed fully before moving to the next, with weekly commitments tight enough to close out. My frontend literacy let me engage with implementation tradeoffs as a peer and brought the rewrite back on track.
Rollout and outcomes
The new product rolled out in parallel with the legacy version, giving customers time to migrate before the legacy build was eventually retired. The rewrite covered the full product surface: match feed, review modal, tagging, collections, asset management, and account flows.
The transition went smoothly. No customer complaints about navigation, missing features, or workflow disruption: the kinds of pushback that would have been reasonable for a product this central to their daily work.
The rewrite encoded the largest customer's workflows into the product itself: context for verifying matches, organizational logic for divvying up work, fast tagging at volume. Functionality that had previously lived in custom external tooling became part of the product, so the next wave of customers could run their full workflow within the Pex ecosystem.
The visual language and interaction patterns are still in production at Pex today.