• Case study • Design system •

Aphrodite

Role

Lead UI/UX Designer → Head of UI/UX

Date

2023 – 2025

Responsibilities

Design leadership
System strategy
Team development

Timeline

2023 – 2025

Context

Aphrodite is the design system I built for AskGamblers, a high-traffic review and comparison platform operating across regulated, multi-market environments. The wider portfolio ran its own system in parallel. Aphrodite's architecture fed the system behind the group's other sites, but they were never the same thing. The portfolio teams named their systems after Greek mythology, so I named ours into that tradition: Aphrodite, for beauty. This page isn't a tour of the tokens. It's the story of the calls I made, the resistance I met, and what I'd do differently.

The situation

Before Aphrodite, design here was one designer executing whatever sat on the product owner's agenda. Work was designed page by page and shipped feature by feature. A UI kit existed, but it trailed the live product by two or three versions. It documented the past, not the present. The codebase was legacy, layered, and maintained by many hands, and an earlier attempt at a system had produced a PHP kitchen sink with multiple competing implementations.

The cost became visible during the redesign. A new design language for the main pages took close to a year to implement. A thoroughly redesigned filtering experience came back only loosely following the designs. Even basic components like chips and dialogs drifted, because every developer rebuilt the same primitives from scratch. The developers were frustrated, we pushed back, and the business went live with a half-baked implementation because the delay was blocking other initiatives. We agreed to fix it iteratively. I took away a different lesson: the problem wasn't effort. It was the absence of a shared system, and of a design voice inside product planning.

That changed. I moved from executing designs to sitting in the product team that decided what we would build, how, and when. Aphrodite started there.

The calls I made

Two decisions defined the system. Both had credible alternatives, and one of them I never formally won.

Adapt Carbon rather than build our own

When the Catena–GiG–Gentoo transition put most product work on hold, I used the pause to define the system properly: first mapping where inconsistencies actually occurred, then studying how mature systems solve them. We tried building custom. I evaluated Material, Ant, and Spectrum. I chose to adapt IBM's Carbon. Its token semantics were clean without being overbuilt, the colour layering matched how our surfaces worked, and its typography split into productive and expressive styles, which matched our two very different reading contexts. The choice meant we didn't rebuild a UI kit from zero. Basic components adapted well, and developers could import and adapt most of the CSS. The costs were real too: every PHP component still had to be built from scratch, and we inherited Carbon's assumptions where they didn't quite fit. The system stayed open to better ideas. We later borrowed Spectrum's button variation model when it solved a problem more cleanly than ours did.

Hold the token layer through a framework fight I didn't win

One of the lead developers wanted to rebuild the frontend in Next.js with Tailwind, and the CTO backed Tailwind. I argued against it: utility-first classes bypass the semantic token layer, and with it every consistency guarantee the system was built on. My preferred route was to fork the React components already built for Carbon rather than reinvent them. His counter was bundle weight. Carbon's React layer is heavy, and he was partly right. The debate was still open when the CTO shut the Next project down; I never formally won it. What mattered was what happened next: the developer who took over implemented the system in Laravel, faithful to the specification. Aphrodite survived a framework war it had no say in. That told me the specification, not my argument, was carrying the weight.

How adoption actually happened

The system had no mandate from above. After the acquisition, the group's C-level was sceptical and pushed to run things the way the group usually did post-acquisition. My backing was local: AskGamblers product and management, and some of the developers. I pitched management on the benefits and the downsides, as a fix for part of the problem rather than all of it. I think that honesty is why it held. The group's view changed later, at Gentoo, once the results were visible.The developers were never conceptually against the system. The fight was over how. They carried huge backlogs, and design moved faster than they could absorb; Figma files sometimes changed in the middle of development and testing. Figma doesn't impose versioning discipline; you build your own and stick to it, and for a while we hadn't. So the first fixes were on my side of the fence: versioned files, branches for exploratory changes that merged only once agreed, and a standard for how designs were structured and handed over. Errors on the development side dropped once the changes on ours did. I sold the system as something that would eventually speed things up considerably, and "eventually" was doing honest work in that sentence.The resistance wasn't only downstream. One of my own designers debated every foundation: auto-layout versus frames, the point of variables, the point of components. I didn't win that by argument either. I led by example, set the standards, and let the results and peer pressure from the other designers do the rest. He came around when the speed and consistency gains were his too.Governance stayed deliberately light. I maintained the system, later joined by a designer who had been dedicated to the portfolio's system and grew into a systems specialist across both. Changes lived on branches until agreed, then went to development. No review board, no rituals. At our scale, continuous communication was the governance; a review board would have been theatre. My team was seven people including two team leads: one ran AskGamblers with a junior designer, the other ran the designers covering the portfolio's other sites. Nothing meaningful ever shipped around the system.

Results I can defend

The adoption numbers come from Figma analytics and I'll stand behind them. They're adoption evidence, not impact claims. A component inserted 320 times a week means designers chose it 320 times, and that's the only vote that matters in a design system.

5

teams using the system

93,950

inserts in the past year

122

components

320

inserts weekly

278

variables

We never measured development time or time-to-market, so I won’t quote either. What I observed: features that used to begin with rebuilding primitives began from assembled components, and implementation fidelity rose. Page loading speed improved measurably during the migration. The system’s consolidation was one contributor among several, so I claim a share of that, not the number.
The strongest evidence arrived after I left: sections designed a year earlier were implemented, with modifications but recognisably to spec, without me in the building.
This is the abridged version. The full case study, including token documentation, component library structure, and file organisation, is available on request.

A system that only works while its author watches isn’t a system.

What I'd say about it now

The system was understaffed, and that was the real failure. Building it was only possible because I spent an organisational lull on it. Maintenance is a different discipline, and it never got its own headcount; the development side never had a dedicated systems person at all. Next time I'd fight for both roles on day one, not after the system proves itself.

I'd restructure the team by speciality rather than by site: systems, research, product design. I proposed it; it stayed a proposal. I still think it's right.
Next.js was the right direction for the frontend, just not with Tailwind. I'd make that argument again, earlier.

And I'd formalise the design-side discipline a year sooner. The developers' frustration was partly of our making; the standards that fixed it should have existed before the resistance had a reason to exist.

When I left, the product's technical future was still being decided a level above the system: full integration into the group platform, a Symfony-to-Laravel rewrite, or something else. Aphrodite was built to survive that kind of weather. So far, it has.

Hiring a design leader, or need one for a while?

Let’s talk.

Get in touch

Marko Rosić PR Beyond Clicks Studio · MB 67353170 · PIB 114143089
Cara Lazara 26/21, 34000 Kragujevac, Serbia