From
Fragmentation
to
Foundation.
Three generations of a content previewing tool — and what it took to finally get it right. Designing the platform-level solution that replaced 20-minute iteration cycles, four fragmented studio workarounds, and a decade of compounding production risk.
A problem that refused to go away — and four teams who stopped waiting for someone else to solve it.
The legacy tool was powerful but fundamentally mismatched to how creators actually worked. Every preview required loading a full production level — sometimes over an hour. Every change, every tweak, every lighting adjustment meant starting over.
“You make one small change — a lighting tweak, a character position adjustment — and you wait 20 minutes to see if it worked. Then you wait again.”
Preview an asset and see the result — fast
Test changes without risking production data
Share a specific test state with a teammate
Iterate freely without fear of a crash
Full level load required — every single time
No isolation — changes touched live production data
Crash risk was real — cost hours when it happened
No shareable state — no way to say "load exactly what I'm seeing"
The fear was a feature.
A full level load every time. Sometimes over an hour. Every change, every test, every tweak.
Not carelessness — rational survival. Years of data loss risk had trained this behavior into the team.
No temporary workspace. No throwaway environment. Every test ran live, against real source data.
When the platform doesn't solve it, teams solve it themselves.
Four studios across the engine stopped waiting for a platform-level answer. Each built their own. Real ingenuity — but unsustainable fragmentation. Four codebases to maintain. No shared learnings. The same gap still open underneath all of them.
Forge Studios
Custom extension for object placement workflows
MMAXX Studios
Lighting workflow branch — never reintegrated into mainline
Ignition Studios
Extended Forge Studios' approach for asset placement
Full Throttle Studios
Sequence container built for cinematic editing
This was the clearest possible signal that the ecosystem needed a real response. Every new production team that joined the engine had to either adopt someone else's workaround or start building their own. Not because they wanted to — because the platform had left them no other option. That ends with Canvas.
Generation 2 — Designing the Bridge
I came into this as the designer on Staging — the first purpose-built, isolated sandbox for previewing assets in the engine without loading a full production level. This was also the first time a design and engineering team had formally collaborated on this problem.
The problem wasn't just technical. It was behavioral. Years of 20-minute cycles had shaped how people worked — manual backups, conservative testing, reluctance to experiment. Those weren't bad habits. They were rational responses to a dangerous environment.
“The tool needed to earn back the trust that the old workflow had destroyed.”
A transient environment that mirrored production but was entirely separate. Changes inside couldn't touch the live layer.
Accidental edits blocked structurally — not by a warning, not by a modal, by the architecture.
For the first time, a creator could save and send a specific preview state. "Load exactly what I'm seeing."
Left control panel, main viewport, timeline controls — all built from existing engine conventions.
When engineering proposed a new data inspection view, I pushed back — advocating to reuse existing patterns.
Down from 15–20 minutes. A full preview cycle in the time it previously took to start loading.
“Staging was the bridge. Canvas is the destination we'd been heading toward the whole time.”
“Good platform design compounds. A pattern solved well in one context becomes the foundation for the next problem.”
Canvas — designed as the response to everything that came before.
I returned to this work as the designer on Canvas, carrying the full context of what Staging had taught us. Canvas was not a patch or another team-scoped workaround. It was a platform-level answer. Every decision maps directly to a documented pain point from the legacy era.
New functionality surfaced during implementation. The design had to keep pace.
After the initial Canvas handoff, two new capabilities emerged from engineering: transform offset for prefabs, and the World Picker. Both introduced interaction modes that didn't yet exist in the design system.
The challenge wasn't just visual. It was communicative. How do you signal a mode shift to a creator who is deep in a workflow — without interrupting their flow or introducing patterns they've never seen before?
The answer came from a different project.
Input Auditioning — a project I worked on the previous year — had solved a closely related problem: communicating to users that they had entered a temporary, purpose-specific mode. The mode indicator and hamburger panel patterns from that work became the direct inspiration for Canvas's transform offset and World Picker states.
“Good platform design compounds. A pattern solved well in one context becomes the foundation for the next problem that looks different on the surface but is fundamentally the same underneath.”
Using Figma Make to explore what the design system hadn't solved yet.
Both new modes required color-based communication to signal state — and neither color existed in the existing design system library. Rather than guessing, I used Figma Make with targeted prompts to isolate the concept, generate design-system-compliant color variations, and rapidly explore accessible options before any decisions were locked.
Prompted Figma Make to focus specifically on mode-state communication. Keeping the prompt scoped meant the output stayed useful and evaluable.
Used Figma Make to produce color options aligned with the existing design system's principles. Accessibility contrast requirements built into the prompt constraints.
The goal wasn't to ship what Figma Make produced. It was to have something real to react to, compare against, and use as a starting point for the conversation with engineering.
AI used as an ideation tool, not a decision-maker. Figma Make was used to accelerate exploration of color and mode-state patterns at a stage where the design system had no existing answer. All final decisions were evaluated, refined, and validated through the standard design and engineering review process.
Design system gaps filled. New patterns established.
Both post-handoff challenges resolved with new color tokens and interaction patterns — now proposed for adoption across the broader design system.
Three generations.
One direction.
This initiative is a case study in what intentional, iterative platform work actually looks like over time. The design contribution across both generations wasn't just interface work — it was establishing the collaboration model, defending pattern consistency, and carrying the full context of the problem through every decision.
“The goal was never to build just a better tool. It was giving creators the confidence to iterate freely.”
The legacy tool. Powerful but mismatched to evolving needs. Its limitations became the clearest brief a designer could ask for.
The proof of concept. Isolated sandbox, 30-second cycles, the first design–engineering collaboration on this problem. The bridge.
The platform answer. Every studio, every content type, every workflow. Built on what Staging proved and designed to last.
Designing Success
Take a look at how I collaborate with teams across diverse industries — bridging research, strategy, and craft to ship products that matter.