Seven siloed internal platforms became one design system in seven weeks, giving Fanatics' Brands teams a single source of truth across design and engineering.
Fanatics is a global digital sports platform built around the fan: licensed merchandise and team storefronts through Fanatics Commerce, trading cards and memorabilia through Fanatics Collectibles, and a sportsbook through Fanatics Betting & Gaming. It holds long-term partnerships with the NFL, NBA, MLB, NHL, MLS, and the NCAA, and reported $8.1 billion in revenue in 2024.
Behind that consumer scale sits an operational one. Inside the Brands division, seven internal products carry the work of running merchandise at league volume, and three designers covered all of them, one each. Every product had been built by its own engineering team on its own terms. The fan-facing experience was consistent everywhere. The tools running it were not consistent anywhere.
The tools were inconsistent because the decisions were.
A company operating at league scale was running its internal tools like separate startups. The visible symptom was seven products that looked and behaved differently. The actual cause sat one level up, in who was allowed to decide what.
Each internal tool was owned by its engineering team, and the product owners were engineers. Design was included in some decisions and bypassed in others, so changes shipped that the design team never saw. The ratio told the same story: three designers against an engineering organization many times their size.
Because changes could ship without design's knowledge, Figma drifted out of sync with what was actually live. There was no dependable record of the product as built, which meant no dependable place to start a consolidation from.
Every internal product within Brands was designed and developed independently, with its own UI patterns and component set. Teams routinely solved the same UX problem twice and built the same component twice, with no shared vocabulary to stop them.
At least three engineering teams had already recognized the problem and started a component library of their own. All three were left unfinished, including the complex components internal tooling leans on hardest: tables above all.
UX and accessibility quality varied by who was available and how much time was left before ship. Both were a function of individual experience rather than a system default, so the baseline changed from tool to tool.
Drag the handle to see how a legacy internal screen changed, from a one-off interface built in isolation into the same tool assembled from the unified design system.
WANDR interviewed 12 internal employees across Product, Engineering, and Design, walked the platforms with the teams who own them, and audited the Figma components against what was actually live. The findings below are drawn from those conversations.
Across product, engineering, and design, the pain points converged: work being repeated, no agreement on which pattern was correct, and no clear owner for the answer. The disagreement was not about whether a shared system was needed. It was about who would give up autonomy to get one.
At least three engineering teams had independently started a component library and abandoned it. Tables, the most complex and most reused component in internal tooling, were incomplete in every attempt. The appetite was already there. The structure to finish the job was not.
The research surfaced what the system would need to survive handoff: usability, meaning a 1:1 match between the Figma library and the coded components; documentation on when to use which component; a design and engineering commitment to maintain it; and leadership buy-in to fund the hours. Three of the four are organizational, not visual.
Owns one of the internal products, alone. Needs components that behave the same in Figma as they do in code, and a decision on which variant is correct so the choice stops being remade every sprint.
Shipping features against a deadline, and has started a component library before and abandoned it. Needs a library small enough to finish and documented enough to trust.
Owns the product roadmap and, in practice, the design decisions too. Moves fastest by deciding locally, which is exactly the habit a shared system asks them to trade away.
Ant Design's breadth was the problem, not the solution. The system deliberately narrowed the component set, fixed when each one should be used, and limited the number of variations, so consistency came from having fewer right answers rather than more options. The same logic drove the table decision, where AntD and AG Grid were compared across seven working criteria rather than chosen on preference.
Rebuild the shared vocabulary from the bottom up, atoms into molecules into organisms into templates and pages, on an 8px spacing scale with defined grid and layout rules, so one change propagates instead of being repeated in seven places.
Write down who owns what. Design owns new and existing components in Figma. Development owns the coded components in Storybook and decides when to reuse rather than build. Leadership enforces the system's use and funds its maintenance. A design system with no named owner is a file, not a standard.
In execution that meant a unified Figma library built on top of Ant Design with styling and component selection specific to Fanatics, five product page templates rebuilt on it, and core components coded and documented in Storybook so designers and engineers were finally reading from the same source.
Fanatics' three designers did the difficult part willingly. They chose between competing patterns, gave up their own versions, and reached consensus on a single shared language across products they each owned alone. The engagement's closing recommendation named the gap plainly: we needed the same involvement from development. That asymmetry is what decides whether a design system is still in use a year later, and it is almost never a design problem.
It is a question of who owns the product, who is allowed to change it, and which leader funds the upkeep. Most organizations meet that question after the files are delivered. It is why we now scope governance into every design system engagement we run.
By the end of the seven weeks, Fanatics had one documented design system where there had been seven, templates its teams assemble instead of redraw, and a written answer to the question that had been sinking every previous attempt: who owns this.
Figures reflect the delivered scope of the seven-week engagement: 12 stakeholder interviews, one unified Figma design system, five product page templates, and core components coded and documented in Storybook. Per the agreed handoff plan, development of the remaining components passed to Fanatics' team. No post-handoff efficiency metric was captured by either side.
WANDR built our entire global design system. The consistency across our platform is something we couldn't have achieved without them.
