The tool every King designer uses, and the AI layer built into it.
The Level Manager runs every level across King's games. I owned its UX end to end, then designed King's first AI feature on top of it: Tweaks, which A/B tested all 18,000+ Candy Crush levels at once.
At a glance.
Nine months. Five games and change. The first AI-powered feature King shipped, and the tool it shipped into.
Reach
Designers, developers, operators and PMs across more than five of King’s games, Candy Crush and Soda among them.
Testing
Tweaks ran variants across the whole Candy Crush catalogue, more than any team could work through by hand. Candy Crush was live on it when I left, with Soda mid-rollout.
First
King’s ML engineers owned the model and the prompt logic. I owned the UX, including the review gate that keeps a designer approving every tweak before it goes live.
Situation
- Joined King to redesign the Level Manager, the internal tool designers, developers
and operators use to build every level across King's games.
- Candy Crush was the largest at over 18,000 levels.
- The UX had real debt, and AI landed on the roadmap at the same moment.
Task
- Owned the Level Manager's UX end to end
- Feature-parity redesign
- UX for King's first AI-powered feature. King's ML engineers owned the model and the prompts.
Actions
- Ran 1-to-1s with different profiles across the games and departments.
- Set up a weekly session across six teams, so alignment and feedback had somewhere
to happen instead of arriving second-hand.
- Designers' complaints from every team went into one list: how elements showed in the working panel, and the shortcuts for working with them. That list became the scope of the redesign.
- A/B testing levels was an evident pain point across different games. Designers set up every test and applied every tweak by hand.
- At the same time, one of the ML engineers was exploring how tweaking could be done with AI.
- Kept: feature parity, not a rebuild. 100+ people built levels in the tool every day, and they had shaped it around their own needs, so most features had to exist in both versions. A rebuild would have stopped production.
- Killed: what nobody used. The level category field, for one: it had been planned, plans changed, and it stayed in the tool.
- Created Tweaks, an A/B testing feature: the system tests variants of a level, and
the winning change, the tweak, gets applied to it.
- The designer sets a target Average Passing Score.
- The system generates test variants and applies the tweaks.
- The designer picks the winning variants to go live.
- Kept a designer approving every tweak. Levels need personality and human judgment. Left to the AI alone, levels risked starting to look like each other. The designer keeps some random variance in, and keeps each level on its narrative line.
Results
Tweaks A/B tested all 18,000+ Candy Crush levels at once.
- 18,000+ levels, at once. That's the whole Candy Crush catalogue, tested in parallel. By hand, designers set up each test and applied each tweak themselves, so no team could have worked through that volume.
- Tweaks took the mechanical half of testing off designers. The system sets up the test and applies the tweak, and a designer still approves every change before it goes live, so their time goes to the part that needs judgment.
- Candy Crush was live on the redesigned Level Manager and on Tweaks by the time I left. Soda was mid-rollout.
- King judged Tweaks on Candy Crush gross bookings. Build speed was never the goal: the focus was level quality.
- The weekly session worked well enough to get replicated on other projects. It also became the place we taught people how to use new tools and features.
What went wrong
- We couldn't measure level quality. Quality was the point of Tweaks, not speed, and we tried to measure it. We never found a measure that held up, so there's no number for whether the levels themselves got better.
Shipping an AI feature is a date on a calendar. Adoption is the only result that counts. If you’ve shipped one nobody’s using, let’s talk.
Let’s talk
