I developed this methodology as Design Director at Bohemia Interactive Simulations, where I led a design organization of 15 to 20 people across four offices, working on military training simulations used by more than 50 nations. It grew out of the techniques I first wrote about in 3 design techniques we use to keep VBS3 development on track, became a week-long, in-person course, and was later streamlined into a mentor-led onboarding series: new designers worked through exercises on a practice project, with a short mentor review after each one.
This is the public edition, rewritten for anyone to use. It is written for whoever decides what gets built: a systems designer in game development, a UX designer, a product owner or product manager, or a business analyst. This methodology calls that person simply the designer.
What “Mission-Centered” Means
Every product exists to help someone accomplish something in the real world. That outcome is the mission: a training objective for a military unit, an operational task in the field, or simply the job a customer is paying your product to do.
User-centered design puts the user’s experience at the center. Mission-centered design keeps users firmly in view, but puts the outcome they must achieve at the center, along with the customer, contract and business realities around it. The mission is why. Users are who. Requirements, features and tasks are how, and they only make sense when traced back to the mission.
The idea comes from defense tech, where software that misses the mission can cost far more than a bad review. It applies just as well to any product.
Where It Comes From
Scrum tells a team how to plan and execute work, but says little about deciding what to build. This methodology fills that gap. Rather than inventing something new, it distills what already works:
- Experience: what worked across the most teams over many years of building military simulations.
- Professional frameworks: business analysis (BABOK), project management (PMBOK), Scrum and Agile, lean production (the Toyota Production System), and user experience design.
- Game development practice: game design and production, which are useful but less formally defined.
The biggest influence is business analysis, the discipline of identifying what a customer needs and working out a solution. The methodology uses a simplified version of it, roughly a third, and keeps business analysis names for its techniques so you can look them up in that literature. Its starting point, the business need, is what this methodology calls the mission.
It was built for simulation and game-based training software, but most of it applies to any complex product where requirements are vague, stakeholders are many, and users’ real needs are easy to miss.
A Note on Terms
The methodology grew up in a military simulation company that used game industry job titles and terms, and some of them remain throughout. In particular: a producer is the person who owns releases and their deadlines (in other industries, a release manager or delivery lead); playtesting means trying the product the way users will, against its use cases (user testing or acceptance walkthroughs elsewhere); and pre-production and production are the design-and-plan and build phases of a project.
Core Ideas
- Start from the mission. Understand the real-world outcome before deciding what to build. Requirements, features and tasks only make sense when traced back to it.
- Scope is always in people’s heads. If you remember only one idea, make it this one. Techniques come and go with each project; this is true on every project. The designer’s main job is to turn many different mental pictures into one shared, written vision.
- Give people what they need, not just what they asked for. Requirements are a low-resolution image of a real need. Find the need behind them.
- An approach, not a process. Building software products is too complex to reduce to a process, just as there is no process for winning a war or a chess match. What you can have is an approach: a strategy, plus techniques you choose for each situation. Every battle is unique too, yet militaries still train doctrine, because doctrine passes on what experience has taught. That is what this methodology is.
- Agile still has limits. Budget and deadlines are real. Agile handles unknowns as you go; it doesn’t make them disappear.
Contents
- 1 The Designer RoleWhat a designer is responsible for, whatever their title, and how they help a development team.
- 2 Core ConceptsProjects and constraints, why scope is the hardest thing to pin down, and how Agile fits within real budgets and deadlines.
- 3 The Project LifecycleThe six phases of a project, from estimate to maintenance, and the goal of each.
- 4 The Estimate PhaseWhy you can’t estimate until scope is defined, how to estimate projects, and the mistakes new designers make.
- 5 Pre-ProductionTurning scope into well-defined tasks: definition of ready, iterative design, traceability and the UX design process.
- 6 ProductionKeeping scope tight during sprints, slicing work, triaging bugs and tracking real progress.
- 7 Release and SupportReleasing, documenting and validating what you built, then supporting it in the field.
- 8 Use Case DocumentsA practical template for the most useful design artifact in the methodology, with a worked example.
- 9 Technique LibraryDesign, analysis and collaboration techniques, each with why it matters, what it is and how to do it.