Why Prioritization Matters
We will never be able to create exactly the game we hope to make. We will never be able to add everything we want, to iterate as much as we should, or to polish to the extent the game deserves. Life happens.
That’s why we prioritize.
Prioritization is incarnating your core to the best extent possible within the constraints of your environment – be they time, money, tools, people, or sanity.
To me, this is the very heart of what makes an indie game an indie game. A product manager would have a very different definition of prioritization, focused on optimizing revenue, engagement, daily active users, marketability, or any number of business related goals over realizing the game’s core. Regardless of company size or financing, for me an indie game is one whose creators champion the play experience over (but rarely to the exclusion of) other influences.
Production vs Design
Most schools of thought advocate having the producer and designer be VERY different roles played by VERY different people. A producer is someone who fights for the deadlines, who says ‘no’, and who protects the product against feature creep and randomization. A designer is someone who fights for the game’s integrity, who says ‘please’, and who protects the user experience against quick fixes and low hanging fruit. Prioritization is the result of their constant battle.
I like playing both roles. It forces me to deeply understand the impact each feature is going to have on user experience and the relationships between those features. It forces me to think on my feet when delays pop up, and be able to point and say, THIS feature is the most important of the three on your plate – do that one; that second one sets the foundation for five other features, but their impact will be virtually null if we lose this moment at the beginning.
Be a responsible designer. Know the impact your decisions will have on workload and deadlines. Learn to prioritize. As Stephen King says, kill your darlings.
So what does this actually look like?
This is another process-that-happens-largely-unconsciously, but here’s an attempt to get it down:
Figure out your influences
This step sets the stage, defining the space you have to work and what you plan on doing there.
Influence is just a broad term for anything affecting your priorities:
- Things you want to accomplish with your game (Goals)
- Things that hold your game back (Constraints)
Here’s a list of some of my major influences, and their order of importance.
- December 10th Deadline – This is the GDIAC showcase for my awesome Cornell team. If the game isn’t done by then, they don’t pass.
- Affective Design – The core of the game. Making people feel curiosity, wonder, solace, and smallness.
- Team’s Technical Capacity – We’ve got two MEngs, one of which knows Xcode, and two undergrads. There’s going to be a steep learning curve.
- Usability/General HCI – This is an umbrella for several goals: no text, quick to complete, holistic aesthetics (audio, visuals, narrative, gameplay all mesh together)
- iPad’s Processing Power – As much as I want this to be beautiful, there are only so many particles or simulations the iPad can handle at a time.
Figure out your features
You’ve got to be prioritizing something, right? If you’ve already got a concept doc, you’re set. If not, starting from the shiny ideal game in your head, mind the goals and constraints and come up with a reasonable feature set.
Here’s a few groups of features from Project Aurora:
- Interactions: Walking, Swimming, Calling, Activating, Collecting
- Usability: Tutorial, Touch feedback
- Aesthetics: Aurora Borealis, Flocking Shards, Light rays, Binaural score, Dynamic shard sounds, Audio filters unique to location, Mountain top moment
Figure out your feature impact
This is my baseline for prioritization.
How much is this feature going to impact the user experience? I usually average effect and frequency with some fudging. Frequency is how often the user engages with the feature, and effect is how much the presence (or absence) would affect them.
|Walking||Very High||Medium||Very High|
|Swimming||High||Very High||Very High|
|Aurora Borealis||Very Low||Very High||Medium|
|Flocking Shards||Very High||Medium||Medium|
|Light rays||Low||Very High||Medium|
|Dynamic shard sounds||Medium||Medium||Medium|
|Audio filters unique to location||Medium||Low||Low|
|Mountain top moment||Once||Extremely High||Very High|
NOTE: This is a rigid structure, and I tend not to think quite so concretely. For instance, even if I have several low impact (but very cool) features, I will try to highly prioritize at least one. To me, those tiny details speak volumes about our craft. While not everyone will notice those additions, their absence, I strongly believe, is always felt.
Figure out the effort required
In college, this was called the “Awesomefort” score, and I’ve stuck with it since. If we think of Impact as “Awesomeness” and dev requirements as “Effort”, it’s pretty self explanatory (and superior to the “Effsome” score, which got us some funny looks).
This doesn’t normally change my priorities, but occasionally you’ll be able to nix a low impact/high effort feature, or realize that you can do five low impact features for the price of one medium.
|FEATURE||IMPACT (Awesome)||COST (Effort)||PRIORITY|
|Dynamic shard sounds||Medium||Medium||P3|
|Audio filters unique to location||Low||High||P4|
|Mountain top moment||Very High||Medium||P1|
Figure out your feature dependencies
In the sample list, I only had room for “walking” – but this is actually the root feature of several others: running, idling, trudging, and stopping. None of the latter features can exist without walking, so I know walking has to be prioritized first. Revise your list with dependencies in mind.
Work with your deadlines
Deadlines, for the most part, shouldn’t matter. If you know your priorities, then you know what needs to be done in what order, and it’s just a matter of figuring out how much of your process you can get through by what date.
There might be some instances where you’d rather have features Y and Z complete for a beta and leave higher priority X until it can be fully functional and polished for a later milestone. I tend to think of that more as “temporary reprioritization” though – and stay away from it when possible. That’s the first step down the long and troubled path of randomizing your devs.
Adjust for the bumps
If we suddenly realize that our walking algorithm causes the game to lag to 4 fps, we have a problem. Is it more worthwhile to spend three weeks fixing it, or nix walking altogether in favor of having a swimming only game? What about two weeks? One? As a designer, you get to draw the line.
TL;DR – Here’s all the factors I consider when prioritizing features:
- Project Goals: What features best accomplish the goals?
- Project Constraints: What features are realistic given the time, money, people, tools, and sanity we have.
- UX Impact: How much will feature’s presence or absence affect the user.
- Dev Cost: How much effort is it going to take to implement?
- Dependencies: What features does this unlock? Or what are its prerequisites?
- Deadlines: Should we put off this big feature in favor of having something more stable for a milestone?
Much love to everyone who’s encouraged me to keep this up. Next week is going to be on project management. Stay tuned!