Case study · EA Frostbite
Zone Streamer
Designing a pattern that scales, not just a fix. A redesigned system for editing zone, neighbor, and volume relationships, anchored by a confirmation pattern that gives users visibility and control that didn't exist before.
The situation on arrival
Configurations reassigned by hand every time the map changed.
Fine at three zones. Broken at thirty. The representation didn't scale.
No checkpoint, no review, no undo before commit.
The real problem
Zone Streamer handles how zones, think of them as hexagonal slices of a world map, their neighbors, and their groupings (called Volumes) stream together across a game world. A zone can represent something as small as a street intersection, used to trigger game logic: environmental procedures, camera or lighting setups, day-night cycles, weather patterns, whatever needs to change when a player crosses a threshold.
The tool predates this project. My team picked up this specific work in January 2026 after Battlefield developers asked for support improving it. A designer on that team had recorded himself manually reassigning neighbor-zone relationships across more than thirty configurations. Every time the map changed, he had to start over.
This wasn't a missing button. The underlying representation didn't scale: fine at three zones, broken at thirty, and real world maps run at double or triple digits of zones, reconfigured constantly as a level evolves.
The process
I got close to the actual workflow, not just the ticket. This was co-designed with two other engineers: I worked in Figma, VS Code, and Claude Code, while one engineer built a parallel prototype directly in HTML.
At one point we diverged without realizing it. I was heads-down in Figma while he explored an approach of his own. We reconverged the following week and reconciled the two directions into one shared reference we worked from for the rest of the build.
The solution: Zones, Neighbors, and Volumes
The interface splits editing into three focused modes, Zones, Neighbors, and Volumes, where Volumes is the new capability: the ability to define and edit a grouping of zones as a single unit, rather than reassigning each zone's relationships one at a time.
A confirmation pattern that didn't exist before
Underneath the three modes sits a full-width review screen: one more look at every zone, neighbor, and volume relationship about to be applied, before it's committed. What used to be a fully manual, unreviewable process now has a checkpoint.
A note on ownership, precisely stated
I didn't invent the Neighbor Volumes concept. I led the experience design and strategy behind how it works and how it's presented. Any team managing zone-based world data can inherit this pattern automatically, which is the point: one team's problem becomes every team's solution.
Validating with real users
Design work is complete and heading into engineering handoff. Right now this is in phase-one usability testing: 11 people who have previously used Zone Streamer are reviewing a demo recording and test build, against a feedback gate closing this week to protect an early-October ship.
Feedback so far has largely been clarifying questions, with real positive support, validating the original ask: giving users the ability to modify zone-to-zone neighbor relationships and how zones group into volumes.
Prior Zone Streamer users in phase-one usability testing.
Designed to be inherited by any team managing zone-based world data.
Target ship, with design complete and in handoff.
Reflection
Zone Streamer is the real work: shipping, validated with real users, built to be inherited by other teams. The assistant below is what I chose to build on top of it, on my own time, to show how I would think about this exact problem if it were actually my job.
Exploring an AI assistant layer
Everything in this chapter is not commissioned and not on any roadmap. It's exploratory work I built independently, on my own time, on top of the real design work above. It's consistent with something a few other designers on our team have been experimenting with: what does AI-assisted workflow actually look like, applied to a real problem instead of just described?
Two use cases, two kinds of decision
I built two scripted flows to demonstrate a retrieve, reason, flag-or-recommend interaction pattern for a technical artist working inside this tool.
UC1
Time-of-Day Calibration
A hard-rule case: a zone-crossing threshold conflicts with a fog-trigger dependency. There's exactly one correct resolution, so the assistant doesn't offer a bypass. A deliberate design choice, not an omission.
UC2
Weather and Lighting Pairing
A judgment-call case: a developer asks whether snow can fall during sunset lighting in a region, or whether that forces a winter profile. The assistant plans, checks three sources, and surfaces a conflict, but here the artist can deliberately override it, and that choice gets logged as intentional, not left looking like a mistake.
Both flows run the same loop: retrieve, reason, then flag or recommend. Step through the stages below, or watch the full recordings.
UC1 flow · Time-of-Day Calibration
UC2 flow · Weather and Lighting Pairing
That asymmetry is the point: not every AI decision should be enforced the same way. A hard technical dependency and a creative judgment call need visibly different treatment.
The pivot that mattered
The first version of this demo was a linear script on a timer. The content was fine, but it didn't read as an orchestrated agent doing anything.
I diagnosed seven concrete reasons why: no visible plan, no visible tool selection, sources named but never used, decorative "thinking" states bound to nothing, a flag that just appeared with no synthesis, dead-end actions, nothing persisting across a frozen frame. Then I rebuilt UC2 around the fix: plan, dispatch three named tool calls, synthesize, flag, execute and confirm.
How I worked with AI to build this
I ran the same plan-verify-checkpoint discipline on the AI coding agent that built this that the demo itself demonstrates for the end user. Every on-screen string traces back to a single source-of-truth document. If a beat's wording wasn't written there, the build stopped and asked instead of inventing it. Every decision, and why, is logged. Every step that ran is logged, in order.
Then I audited my own build
I didn't want to grade the work by feel. So I built a small audit dashboard that scores this build against 21 real evaluation criteria, each one checked against the actual running code, with nothing rounded up: ambiguous status gets marked partial, not covered.
It flagged an inconsistency between the two flows and told me where the last few hours were best spent before anyone else saw it.
Being precise about what this is
There's a single orchestrator dispatching a fixed sequence of tool calls: retrieve, reason, then flag or recommend. That's one coordinator running a sequence, not multiple autonomous agents negotiating, and the distinction matters more to me than claiming the more impressive-sounding version.
Each step's output in this demo is hand-authored rather than a live model call, by design: the goal was to demonstrate the interaction pattern and reasoning loop clearly. In production, each step would be a real tool call, potentially with different models depending on how much reasoning a given step needs.
Final thoughts
Two pieces of work, held to the same standard.
The design work
Zone Streamer is the part that ships. It started as a support request about one painful workflow and became a representation change: a way to edit a group of zones as a single unit, with a review step before anything commits. The pattern isn't scoped to one team. Any team managing zone-based world data inherits it. Design is complete and in engineering handoff, validated with eleven prior users, targeting an early-October ship.
The exploration
The assistant layer is the part I built to think out loud. It isn't commissioned and isn't on a roadmap. I wanted to show, not just claim, how I would approach an AI-assisted version of this tool: a retrieve, reason, flag-or-recommend loop that treats a hard technical rule and a creative judgment call differently, built with the same logged, checkpointed discipline I would expect from the feature itself. If this became my job, this is where I would start.