When designing a new feature, a useful approach is to design it in tiers. This helps focus your intention, prioritize tasks for implementation and lets you react to scope changes while preserving the spirit of the feature.
Feature Clarity#
While it is naturally enjoyable to prototype, theorycraft and bluesky about what a new feature might be and how it could work, there’s a point where you need to know what the absolute core of the feature really is and where it fits into the experience.
What is its primary purpose in the game? What are its secondary interactions with other game systems? What is important here and what is simply nice to have?
During this process I typically use a three tier system:
Feature Core#
This is a small list of only the most essential pieces of the feature to make it functional in the game. At this stage there’s effectively no realisation unless it’s absolutely required for the feature to be understood.
Important#
The next level up is the list of things that will flesh out how the core of the feature works and begin adding additional signs and feedback. Natural extensions of the feature can be documented here, but limited to those that add the most value to the experience.
Nice to Have#
This list includes all of the polish tasks, additional player comfort and further opportunities where the feature can intersect with other aspects of the game in secondary or tertiary orders.
How you choose to divide up the various levels of realisation will, as always, depend on your studio, project and personal preference. For example, it could be a five tier system with more granularity to each tier or a two tier system that focuses only on what is absolutely required and what is polish beyond that. At this stage however, I would suggest avoiding making this list too finely grained - for now, buckets that clarify the relative importance of the pieces of the feature is enough.
Where each aspect of the feature lands within your chosen tiering system will reveal whether the intersections between features that you foresaw are really as important as you first thought. Perhaps they are, but perhaps not. You will need to be brutally honest with yourself during this process and be willing to rate that idea you thought was brilliant as a nice to have if that’s really what it is.
Prioritization by Design#
Once you have tiers assigned to each aspect of the feature you can naturally begin prioritizing what to implement first. This prioritization should begin with your most important tier and naturally progress to the least important. Within each tier you can then rate the order you feel tasks should be implemented in.
This will give you some level of control over the evolution of the feature and let you review it at each step of implementation to ensure it’s meeting expectations and aligning with the overall experience in the game as well. It also ensures that if changes are needed to the feature, you can discover that much sooner than you otherwise might.
When working in a team, it’s likely there will be some conversation about the prioritisation you’ve proposed. It’s important to be somewhat flexible here while still ensuring the feature shapes up as you expect. There may be tasks that happen out of order due to implementation dependencies and that’s ok! As long as the tiers are tackled in order you’re still on track to deliver the feature as expected. If that’s not happening though, sitting down with both stakeholders and implementation specialists to discuss why and come to agreement on all sides, is worth doing.
Surgical Cuts#
Let’s face it: having to cut part or all of a feature can be hard, but it’s a fact of life in game development. As a result, you’ll need to consider what will happen to the player experience, if you’re still able to achieve the vision and whether or not it leaves a gaping feature-shaped hole in the game overall.
By designing in tiers you’ll have a better idea, in advance, which aspects of the feature are at risk of being cut because you’ve already done the work of deciding the importance of each and guided the implementation order of things thus far. You’ll know ahead of time which of the remaining tasks are really critical and which can be let go or put in a backlog for consideration in a future update, if that’s applicable.
This information, while not infallible, is inherently valuable. You can propose changes to the feature that meet scope, have honest and informed conversations about the remaining work and your teammates will appreciate your ability to adapt to evolving conditions without being shocked or surprised by the changing realities of production.
Natural Growth#
Another benefit to this approach is that it will help avoid subtractive design. While design by subtraction can be a useful tool, allowing you to find or strengthen the core elements of a feature, it often results in cut content, wasted work and an impact on team morale. Instead, starting with a small spark - the core of the feature that you can prove works without all of the polish and intersecting systems - allows the feature to mature and expand in a visible way, making decisions in the process to help course correct with minimal disruption.
Designing this way is like planting a seed and watching it grow. You’re building a feature out from a solid, proven core to a certain deliverable level, with a roadmap of how to further enhance the feature. This is a reliable way to achieve a strong design that fits more naturally into the experience.