Process Breakdown
My design process was shaped over years of shipping content, absorbing feedback, and iterating under real constraints, until the steps that consistently reduced risk became muscle memory. It scales cleanly because the core questions stay the same: define the player promise, align on what “done” means, prove the experience quickly, then refine with evidence. Whether it’s one level or an entire zone, it’s the same loop, just more surface area and coordination.
Click each button to learn more.
Concept
Implement
Launch
Concept
Implementation
Polish
Launch
Research
Establish intent and feasibility before production cost.
- Clarify scope, constraints, and player promise (session length, replayability, social and solo expectations)
- Run cultural, biome, and POI reference study to ground tone, materials, and visual logic
- Use third-party expert review when authenticity, accessibility, or subject matter needs validation
Detailed rationale
I start by clarifying what the player experience is supposed to deliver and what constraints will shape it.
Research includes world references (biome and POI patterns), cultural grounding when relevant, and early checks for feasibility.
The goal is to define the rules that will make the space legible, coherent, and buildable.
Align
Create stakeholder clarity: what we are building, why it matters, and what done means.
- Pitch framing: elevator line, unique selling points, competitive context, target audience
- Production framing: MVP definition, stretch goals, collaboration plan, dependencies
- Early operational framing: initial QA runbook, timeline and cost assumptions, sign-on gates
Detailed rationale
Alignment is where ideas become commitments. I translate the concept into a pitch that stakeholders can evaluate quickly:
what makes it distinct, who it serves, what MVP means, and what tradeoffs are implied. I also establish early gates
so quality expectations are explicit (timeline assumptions, QA intent, and dependency risks). The outcome is shared certainty.
Define
Turn vision into an implementable plan that other teams can act on immediately.
- Creative rules: pillars, tone, art direction, mood boards, readability standards
- Gameplay rules: mechanics, economy and resource allocation, encounter logic, enemy and faction breakdowns
- Build rules: maps (biomes, top-down, golden path), asset requests, feature TDDs, naming conventions, how-to docs
Detailed rationale
Definition is documentation that production can execute. This is where pillars, art direction, narrative beats, mechanics, economy rules,
encounter logic, and mapping frameworks get locked into a usable structure. I focus on maps and authoring systems that keep designers aligned:
top-down layouts, golden path intent, landmark logic, POI roles, and predictable naming and implementation conventions.
Prototype
Answer feasibility questions fast: does the core interaction feel right at the intended scale?
- Stub mechanics to validate moment-to-moment loop and failure states
- Test scale, distance, and traversal timing to confirm pacing assumptions
- Identify constraints early (tech, animation, UI, AI, networking, performance)
Detailed rationale
Prototyping is a proof phase. I stub the mechanics, test the spatial scale, and validate travel times and pacing assumptions before content
multiplies. If something cannot be made fun quickly at the intended fidelity, it is either re-scoped or redesigned while the cost is still low.
Playable
Prove integration: an end-to-end slice that demonstrates systems, navigation, and onboarding.
- Validate core systems and tech features in a real player flow
- Ensure tutorials and FTUE are functional enough for unbiased testing
- Confirm content authoring pipeline and iteration speed before full production
Detailed rationale
A playable slice establishes end-to-end reality: navigation, combat rhythm, systems integration, and onboarding all function together.
It is the earliest moment where playtests become reliable because the player is not filling gaps with imagination. This slice also tests the
production pipeline: how fast changes land, whether tools are fighting the team, and what content types are risky.
Iterate
Use structured playtests and reviews to tune pacing, difficulty, clarity, and accessibility.
- Pacing and fatigue checks (travel time, encounter density, downtime rhythm)
- Difficulty balance and edge cases (solo vs group behavior, skill variance)
- Cross-discipline feedback loops (weekly reviews, 1:1s, stakeholder checkpoints)
Detailed rationale
Iteration is where opinions get replaced by evidence. I run structured playtests and review loops focused on pacing, clarity, difficulty balance,
and accessibility. I prefer changes that improve comprehension without flattening tone: better landmark logic, clearer signposting, and fewer
gotcha failures. Feedback becomes actionable when it is tied to observed behavior, not preference.
Polish
Unify the experience across disciplines so the player reads the space instantly and feels the intended tone.
- Integrate VFX, audio, animation, UI art, localization, and final writing
- Refine interactables and readability (signposting, silhouettes, lighting intent)
- Align marketing needs with accurate capture targets and messaging
Detailed rationale
Polish is cross-discipline cohesion. This is where VFX, audio, animation, UI, localization, and final writing come together so the player reads the
space instantly and the tone is consistent. I prioritize the last 10 percent that actually changes the experience: interactable affordance,
lighting intent, silhouette clarity, and final narrative touch points.
Ship
Close gates deliberately: stability, compliance, performance, and final content correctness.
- QA validation, performance checks, and final content gates (text, code, VO)
- Handoffs, documentation, and on-call readiness for launch support
- Launch notes framing and patch narrative that matches reality
Detailed rationale
Shipping is gate discipline. I focus on stability, performance, and correctness across content, text, and VO. Final QA passes are paired with clear
handoffs and launch readiness, including war room expectations and a plan for urgent fixes. Launch notes are written to match reality.
Learn
Convert launch outcomes into actionable improvements and future-proofed pipeline updates.
- Engagement and sentiment review across platforms (streams, community, reviews)
- Metrics and cohort reads to separate novelty effects from durable patterns
- Action list: reinforce successes, correct failures, improve tools and workflow
Detailed rationale
Postmortem is where the process pays dividends. I review engagement signals and sentiment across community channels and media, then tie outcomes back to
concrete metrics. The goal is an action list: what to repeat, what to correct, and what to improve in tools and pipeline so the next cycle is faster
and safer.
Live Ops
Operate the content responsibly with telemetry, community feedback, and controlled iteration.
- Telemetry review and economy balance, with clear hypotheses for changes
- Bug reporting and tracking discipline and prioritized fixes
- Updates, patch notes, and cadence planning that maintains trust
Detailed rationale
Live Ops is ongoing stewardship. I monitor telemetry, economy balance, and bug trends while staying connected to community feedback. Updates are treated as
controlled experiments: make changes with clear hypotheses, measure impact, and communicate results in patch notes that preserve trust. The objective is
long-term health.
Design Frameworks & Principles
How I think when making decisions and communicating systems
›
Design Frameworks & Principles
How I think when making decisions and communicating systems
Player & System Models
Frameworks are tools, not dogma. I use them to sharpen decisions, expose assumptions, and explain tradeoffs.
- Bartle Player Types to reason about motivation and long-term engagement across different player intents
- MDA (Mechanics / Dynamics / Aesthetics) to work backwards from player feeling to system behavior
- Skill Atoms Model to break interactions into teachable loops: action, feedback, and mastery progression
- Three-act pacing curves to shape tension, release, escalation, and fatigue across a full experience
- Game Feel to reason about moment-to-moment responsiveness, feedback, and player perception of control
- KISS principle to value elegance and simplicity in the final execution
Information Design and Documentation
Using the Edward Tufte model, I apply information design discipline to maps, flow charts, telemetry dashboards, and player-facing readability.
- Clarity over decoration. Remove noise. Keep the signal.
- Show comparisons, not conclusions. Let patterns reveal themselves.
- Integrate words, numbers, and diagrams. Context travels with the data.
- High data-to-ink ratio. Every element must justify its existence.
- Design for reasoning. Diagrams are thinking tools, not presentations.
Principles I Rely On
These show up repeatedly in shipped work because they reduce confusion, accelerate iteration, and preserve intent.
- Constraints breed creativity. Blue sky design is often paralyzing; clear boundaries force smarter, more elegant solutions.
- Rules are made to be broken. Break conventions when the design stays legible and intentional.
- WYSIWYG tooling is crucial. Iteration speed depends on what designers can see and change directly.
- Teach, don’t tell. Mechanics should be learned through play and environment, not text boxes.
- Diegetic > Non-Diegetic UI. Prefer environmental signals over on-screen prompts.
- Subtract until it breaks. A design is finished not when there is nothing left to add, but when there is nothing left to take away.
- Respect the player’s time. Friction should come from the challenge, not the interface, controls, or backtracking.
- Lead with empathy. Tailor assignments to match individual strengths and interests; excited designers build better features.
- Strong opinions, loosely held. Fight for your vision, but abandon it immediately when better evidence or constraints appear.
- Listen to the data, not the comments. Player behavior beats player speculation.
How This Maps to the Phases
- Concept: Define constraints to spark creativity, match team strengths to features (leading with empathy), and identify which rules we intend to break.
- Implement: Build teachable loops without text, insist on WYSIWYG tools for speed, and prioritize “showing” over “telling.”
- Polish: Subtract noise until the design breaks, remove friction to respect the player’s time, and force UI elements to be diegetic where possible.
- Launch: Validate with behavior data (not comments), and hold our design opinions loosely—abandoning them if the live evidence demands it.
The goal is consistency: a process that scales, plus a communication style that makes complex systems readable to players and teams.
Example Process Documentation
Representative Confluence-style documentation snapshots showing how I format intent, constraints, and implementation notes for fast team adoption.
More examples of Process & Documentation