Tactile Core

It began as separate tools and spreadsheets on a default Bootstrap theme. It worked — it just didn’t hang together. The problem was never the UI. It’s utilitarian software.

Making it cohesive was the job. First move: one rail across every tool, plus a switcher to jump between games.

Pick the resources to test, add groups, set weights — the whole experiment on one screen. The heavy machinery of an A/B platform, made to feel like filling in a form.

Each group is a single card: its weight and split, its journeys and tracks, and its livenumbers — DAU, ARPDAU, revenue diff — right there. You compare Control against Treatment without leaving the card.

Dense signal in a small card, without it feeling heavy — the part I enjoy most.

A tool is mostly its edges — the empty first-run, the confirm modal, the randomization seed, the in-between card states. Getting these right is what makes it feel finished.

I built our Core Design System from scratch — MUI underneath, themed after Untitled UI — and spent too long perfecting components before anyone needed them.

You only need the basics up front: inputs, tables, buttons, type, colour.

The real work is the patterns and rules — written down from day one. The rules are the product.

Scheduled Features puts every event and offer, across every track, on a single timeline with a “today” line through it. Ops sees the whole calendar at once instead of reading a list.

Underneath, an offer is a wall of nested JSON. The tool’s job is to make that editable by a human — a form, a timeline, a set of states — instead of a text file someone edits at 2am.

A small donut per overlap, real percentage beneath. A dense comparison you read in a second — the kind of tiny, information-rich component I could design all day.

Details, usage, last-run results, the many-segments case, the two-segments case, the kebab menus, the add-button state. A real tool is the sum of its small, correct moments.

I chased uniformity — every tool identical. Wrong. A timeline and a support inbox are different tasks, different mental models, different users.

Only the basics should match — saving, modals, destructive actions, empty states. The rest should be free to be itself.

Naming, shortcodes, package + certificate config, team permissions. Enough hand-holding that a brand-new game (or an outside studio) can get running without someone walking them through it.

Permissions, template containers, the fingerprint section — assembled from the same Core parts, so a new flow inherits the system instead of reinventing it.

Not a gallery to skim — the point is the surface. One person, one system, this much ground, from 2021 to 2025.

Two I’d take back. Uppercase buttons, straight from MUI, are now permanent — we tried sentence case and people had gotten used to the shouting. And the purpleleans too hard in places because we followed MUI’s theme instead of our own judgement.

The bigger one: I designed the system but under-taught the why. I did it one-on-one when I should have built it into how the whole team thinks. That’s the part I do properly now.

No clean number to give — too much changed at once to pin adoption on the redesign, and I’d rather be honest than tidy.

The real outcome was a surprise. The craft — design andengineering — got good enough that a games company started seeing itself as a SaaS one. Good internals other studios could run on. That’s where it’s headed next.