Prioritization Framework for Game Design Features

Workgroup Members

  • Mariana Boucault, Osama Dorias, Chandana Ekanayake, Zack Hiwiller, Marcus Montgomery
  • Additional Contributions: Jennifer Ash, Alexei Pepers, Ian Schreiber

The Problem

Creativity is always a leap of faith. You’re faced with a blank page, blank easel, or an empty stage.” – Julia Cameron

The beginning of a game project is always fraught. Sometimes you have a completely blank page with an idea. Sometimes you have to build off another work to make a sequel or something that affirms a genre. Regardless of your base assumptions, you have to start somewhere. Often, that presents a chicken-egg paradox where you don’t feel comfortable starting Feature B until Feature A is done, but you really don’t know how Feature A should work until you feel out Feature B.

These problems are common in professional game development, but there have only been ad-hoc ways to address them that can be contradictory when combined. This paper attempts to give tools to the starting game team that will help them understand and prioritize their early game and prototype features.

There are two common frameworks that already exist for this problem, but both tend to lie in opposition to each other. The first is what could be called functionally-wide prototyping. In this, teams build the most foundational features first in order to have a robust testing bed in which to experiment with new features. 

A major drawback method to this is that it is slow to get to the unique features of the game you want to make. For instance, if your plan is to make a groundbreaking take on American Football that aims to dethrone the Madden franchise, you first have to make a game that simulates American Football, which has a complicated rule-set, the need for multiple player types each with their own AIs based on selected plays or other assignments, and an expectation of an animation system that allows players to understand their options in real time. That’s a tough sell, and may be why we don’t see a lot of challengers to the crown. Just building the playground where you could add your own unique selling points would take a long time.

Another method would be to create a robust vertical slice. In doing this, you ignore the wider requirements of the final game and instead focus on making a short-duration sample of what the game would be, usually picking the set of features to feature in the sample that would best show your unique selling points.

The drawback with this is that the vertical slice is fragile. What happens if the features you choose to focus on turn out to be too complicated, not fun, or not representative of the experience you wish to make? Since you are only building the scaffolding to support your chosen set of features, it is likely you have to go back and rebuild for whatever your playtesting reveals needs to change. If you already perfectly understand what you are going to make, a vertical slice can be very helpful. But if you are facing a blank page, it doesn’t lend itself to experimentation.

What we need is a framework that allows a team to best prioritize the game features they plan on making while allowing for the experimentation and iteration necessary in games, but that also allows teams to be cost-effective and agile. This framework is an attempt to bridge the gap. We desire a system that both allows us to plan effectively and react creatively.

Normally, this kind of longer-term planning is seen as a task for producers, not designers. However, what we are proposing must be reactive to how the design unfolds in practice. The people making the prioritization calls must be knowledgeable both on the relative costs and benefits of features and the impact those features would have on future experimentation. This is knowledge that only designers can effectively juggle, usually with help from the other disciplines on the team.

Hopefully, the framework we present below will allow designers new tools to consider the relative importance of the tradeoffs in early prototyping allowing for a more flexible, a more transparent, and ultimately, a more effective game development process.

Overview of Framework

This framework allows the user to organize their design work and prioritize the efforts through lenses agreed upon by the team.  There are 4 steps to this framework.  Each step is crucial to informing the subsequent step.  

  1. Identify Your Features
  2. Determine Assessment Criteria
  3. Stack Rank features by importance and risk
  4. Consider project logistics

1 – Identify Your Features

This is the easy part.  List out all the design features needed for your game. Think deeply about each feature and list out all subfeatures as well. Ex: You need a combat system, that means that you’ll need the following systems as well: damage, death, hit react, knockback, etc…

Make sure to break apart any feature that is not distinctly linked to another, and to note any dependencies. 

It’s very unlikely that you’ll get this right on the first pass. You’ll likely need to break down features into smaller features as you go, and will also likely revisit this list as you remember more items that you require. 

2 – Determine Assessment Criteria

After completing the list of all intended features, we can analyze and categorize them.  The categories defined in this step help you organize your features into clear categories to help you rank them in the next step.  

2.1 – Feature Categories

This is the key step in determining the priority of each feature. You need to describe how you will organize and prioritize your game features.  For each of your features you’ll need to label them with one of the categories listed below.  

  • Core Mechanics – Any gameplay mechanics that will stand up the core gameplay experience of your game.
  • Core Fantasy – Any features that would help sell the core experiences or emotional aesthetic of the project. 
  • Hard Constraints –  Features that are necessary to ship, but not core to the experience, such as Contractual Obligations, TRCs (Technical Certification Requirements) etc…
    Ex: Your product must use the Kinect. Your game has to be localized in a specific region.
  • Soft constraints – Features that may be necessary to ship, but are more likely self-imposed or publisher imposed and that may change. Number of playable characters in your fighting game, or number of crafting materials in your economy.
  • Expectations – Tables stake features or any core expectations of the genre. Features like Drop In, Drop Out play in multiplayer, cloud saves, or the like.
  • Embellishments – This is a class of features that are somewhat luxuries in production.  This contains things like Easter eggs or additional content.  
  • Quality of Life – These features are not crucial but would improve the experience of the player.  Ex: A feature that allows selling the items in batches instead of individually.
  • Polish – Things that refine the experience.

2.2 – Importance Buckets

Next step is to order your Feature Categories within their Importance Buckets (or tiers,) to help you understand how meaningful your Feature Categories are relative to each other. There are three importance buckets:

  • Essentials – The set of features that are crucial to the creation of the game.  Without these features the game could lose its unique selling points or worse, be canceled.
  • Baseline – These are the minimum set of features to have a complete game.  
  • Accessories – These are a set of features that are not necessary to ship the game.

Each Feature Category is conveniently categorized within these buckets like so:

  • Essentials
    • Core Mechanics
    • Core Fantasy
    • Hard Constraints
  • Baseline
    • Soft Constraints
    • Expectations
  • Accessories
    • Embellishments
    • Quality of Life
    • Polish  

These are fixed classifications that must be adhered to, however the Feature Categories within each bucket may be placed either above, below, or alongside each other within their respective Importance Bucket. Below you’ll find a few examples of how this can differ from project to project:

3 – Stack Rank and Assign Risk

In this step you will stack rank each feature against each other, then assign each of them a risk factor.

3.1 – Ranking Features

With each of your features classified to a Feature Category, we can now begin stack ranking the features.  

3.2 – Assigning Risk

With each of your features you will then assign a Risk Level.  Label each risk with a letter A through D.

  • Terminal (A) – Without this feature you can’t ship the game. You have no alternatives or workarounds for this feature. It is a must have.
  • Alternatives (B) – This is a feature where you have a clear alternative solution in the case where the initial plan does not work out.  
  • Safe Implementation (C) – This is a failsafe implementation plan. Typically a solution that mimics a feature or solution from another game.
  • Safe to Cut (D) – If you don’t implement this feature, you can cut it without consequence. The game can ship without it.

Typically all features in the Essential bucket will get assigned a Terminal (A) label.  

The Safe to Cut (D) label will most often be applied to features in the Accessories bucket.  However, Accessories may also be labeled with Safe Implementation (C) labels.  

Some examples:

4- Consider Project Logistics

Above are a set of guidelines to help prioritize your implementation efforts.  However there are many other factors that may influence your priorities throughout development.  It is important to keep each of these in mind.  

  • Living document
    • Your game design is a living breathing thing.  As your design focus changes and you update your documentation, you may need to revisit your priorities.      
  • Other Feature Dependencies
    • Some of your design features may require other features to be implemented and completed before you can start to focus on those particular design features.  You’ll need to identify those feature dependencies and keep them in mind.
  • Alignments with other teams
    • Game development can be a team effort, and as such you may need to coordinate your feature creation with other members or team disciplines.     
  • Production Considerations
    • There could be a myriad of other production realities your team should consider.  In doing so, you should make sure to discuss them with your production staff to work out those issues.


Congratulations, you now have a list of features prioritized by your design needs. This list will now help your team spend their time and effort where it matters most, to mitigate design risk and reach your project-specific targets as efficiently as possible.

Note that this is a guideline to create early prototypes and development states. Priorities will change during the course of development according to new findings and new constraints that will appear and it is normal to have to reprioritize in cycles with the team. 

Notes on Polaris

This paper was produced by a workgroup of senior game designers at the 2023 Polaris conference. The non-profit Polaris Game Design conference seeks to gather the industry’s top designers in order to first, discuss our toughest problems and second, share this deep wellspring for the benefit of game teams everywhere.

In 2023, this work was made possible in part by our sponsor Xsolla and others.