Use case 02

Designing internal tooling for live game economies

B2B platform work spanning events, offers, segmentation, pricing, rewards, and publishing as Voodoo's portfolio moved into more complex live operations.

Scope

Internal platform module

Focus

Live ops UI, system patterns, and operational clarity

Outcome

~5% revenue uplift contribution

Campaign and offer list view inside the internal game economy tooling — The module had to connect global events, campaign structure, offer configuration, segmentation, pricing, rewards, and publishing into one coherent operating surface.

Context

I worked on expanding our internal B2B platform with a game economy management module. The goal was to move recurring live-ops work out of code and into a product surface that economy designers and QA could operate directly.

As the portfolio shifted from primarily hypercasual titles toward more complex hybrid casual games, teams needed much more than simple offer switches. They needed scheduled events, targeted offers, reward classes, pricing tiers, media slots, and publishing controls that could evolve over time without engineering support for every change.

The capabilities were adopted by titles such as Mob Control, Block Jam, and Monster Survivor, contributing to stronger revenue performance.

The product problem

The challenge was not one isolated screen. It was designing a system of connected surfaces: overview tables for live events, builders for campaigns and offers, entity relationships for segmentation and conditions, and product modules for pricing and rewards.

That made the work partly a product-definition problem and partly a UI-system problem. We needed to support higher complexity without making the operating model fragile, opaque, or exhausting for the people using it under production pressure.

Framing the system

We started with a broad benchmark across game systems and adjacent SaaS tools to understand expected capabilities, common interaction patterns, and where a more opinionated internal product could add value. The point was not to borrow screens directly, but to understand how other tools represented entity relationships, sequencing, and operational state.

From there, we moved into feature framing using affinity mapping and a method I developed called Cartesian mapping, where desired capabilities were plotted against benchmarked tools. That made tradeoffs easier to discuss, helped surface differentiation, and gave us a clearer implementation sequence.

We validated both through Figma prototypes and production-ready builds. That was important because several ideas that looked fine in prototype became much harder once they had to support real data, nested logic, and day-to-day operational use.

Benchmark examples from game systems used during framing — Benchmarking covered both game-side economies and adjacent ops tools.

Capability mapping of offers, store structure, segments, and conditions — Capability mapping clarified how events, offers, segments, and conditions related.

Global events table inside the game economy tooling — Overview tables had to expose event status, perimeter, time conditions, and modifiers without becoming noisy.

UI and design system work

Once the scope was clearer, a large part of the work became system design. We needed consistent patterns for overview tables, status taxonomy, segmented navigation, schedule inputs, pricing matrices, reward definitions, content fields, and media management.

The adapted design system mattered because the module was growing in multiple directions at once. Without shared patterns, each new screen would have become bespoke. With them, we could keep the product legible while still supporting nested logic and higher entity volume.

The output was less about a single polished screen and more about a coherent operational surface: lists that helped people scan, forms that exposed dependencies clearly, and builders that let teams understand where a change lived and what it would affect.

Global events view in the game economy tooling — The event overview made status, scope, timing, and modifiers scannable across many live entries.

Event configuration screen with schedule, segments, conditions, and classes — Configuration screens had to expose schedule logic, segmentation, conditions, and classes without losing clarity.

Campaign and offer list view in the game economy tooling — Campaign and offer lists used shared patterns for hierarchy, status, triggers, pricing, and quick comparison.

Offer builder with pricing and rewards configuration — Offer builders brought rewards, prices, labels, media, and content into one editable structure.

Offer builder with conditions, pricing and rewards inside the game economy tooling — Offer builders had to balance pricing, rewards, labels, media, and custom content in one editable surface.

Outcome

The work created a more capable product layer for economy designers and QA, while also improving the clarity and usability of the platform itself. It gave teams a way to operate more sophisticated live-game systems without relying on code changes for every adjustment.

The tool also contributed commercially. Around 5% revenue uplift was tied to new offer types and items created through it, effectively paying back the project.

The most durable value was structural: the project clarified what a mature internal product needed to support as the portfolio and monetization model changed.

Constraints and lessons

The service sat between the game back office and the client, which limited direct control over some behaviors and restricted available data. Early feature sizing also reflected how many entities teams had at launch, not the scale they would create over time.

That made capacity planning, scale assumptions, and adoption timing just as important as screen quality. Next time, the tool should support structured CSV ingestion from day one, assume higher entity volume earlier, and plan adoption paths that fit teams before they reach full economy complexity.