After six years of working as a game designer on a live title and after forty or so updates, there is one learning I believe I share with everyone that has been in a similar position; the game design is a messy process.

Maybe you start off with an idea for a cool game feature, maybe you start off with a gaping hole in one of your metrics, maybe you start off with a vague set of goals… You brainstorm, you toss and turn the original idea, you add to it, and subtract. You iterate, you negotiate with your developers and artists. More often than not you end up running in circles. More often than not the end result turns out to be a horse designed by a committee, or even worse, a camel designed by a committee.

Anything that can streamline this process, that can make it less convoluted is always welcome. In talking to my coach I came across something that I found interesting and applicable. The GROW model has been a part of the corporate coaching toolbox for about three decades, since it was published by John Whitmore in his 1992 book Coaching for Performance and Max Landsberg in The Tao of Coaching, 1996.

The GROW model is a goal setting and problem-solving method that consists of four distinct steps, which produce the letters of its acronym:

It is an intuitive yet versatile framework that can be used for a wide variety of practical problems. In what follows, I’ll elaborate my take on how this method can be applied to game design tasks.

G is for Goals

A video game is not a monolithic piece of software. Neither is a single chunk of design. Rather, it is an intricate system composed of a series of interconnected features. Here a feature can be anything, from the control scheme, or a gameplay mechanic, to a bit of UI.

Let’s assume that you want to add a feature to your game. I am speaking from the experience of creating features for an already published title that we maintain and develop as a live service. Now is a good time to remember the writing advice formulated by Kurt Vonnegut: “Every sentence must do one of two things — reveal character or advance the action.”

Every feature in the game needs to have a purpose for its existence. Every feature needs to fit in with the rest of the big picture. Features need to communicate with other features. They are interconnected in a myriad of ways. New features are often built on top of another already existing one.

Therefore, your design process by necessity begins with a set of goals. At a first glance, this may sound obvious, yet in practice, it is so many times overlooked. I have seen teams get into a design process with a very ill-defined loose set of goals that can even be contradictory, or even worse, jump straight from an idea to intricate the design without giving much of a thought about the purpose of the thing that they are designing. This is the first and biggest pitfall! Avoid it at all costs!

Spend time defining a set of goals that your design needs to fulfill! This can in itself be messy, but spending time at this part of the process, will save you an immense amount of wasted effort later down the line! Your design can try to hit several goals, however, it needs to have at least one. Goes without saying that one should be mindful of focus and avoid trying to impose too many goals on a single design.

The very act of spelling out and writing down a set of goals is the first step in bringing clarity to the design process. There are many ways how one can go about accomplishing this task, but there is one particular method that is worth looking into. If you have any experience of working in a big company, chances are you have encountered the notion of SMART goals as a part of your yearly evaluation process. I know that this acronym can bring a sense of cold dread, but bear with me.

The letters in this acronym stand for the following:

These categories can be directly applied to goals suitable for a design of a game feature.

Specific — your feature needs to have a specific purpose, it can be adding new functionality, creating a particular kind of user experience, modifying player behavior in some way, etc.

Measurable — you need to be able to define at least one quantitative metric by which you are going to evaluate the performance of your design. This can be any of usual KPIs (Key Performance Indicators), such as engagement (a percentage of eligible players that chose to interact with the feature), day two, day seven, or day thirty retention, same monetization metric, or anything else that is applicable.

Attainable — in a practical sense, the goal needs to be attainable with the resources you have in the time frame that is at your disposal.

Relevant — no feature exists in a vacuum. Every feature is a piece of a bigger system. The goals that it needs to satisfy, must be aligned with the goals of the larger product. You can specify a valid goal that is simply irrelevant to the overall structure which you are building. This is something to be avoided.

Timeboxed — time is one of the most common development constraints. It is also one of the most useful constraints, that forces the team to stay focused and keep the scope manageable. In practice, the schedule for designing and developing any individual feature usually needs to align with an overarching development schedule, for example, a release cycle, or development milestone deadlines.

If after applying this methodology, you end up with a list consisting of a handful of goals that satisfy these criteria, you are on a good footing to take the next step of the process.

R is for Reality

If the previous step, the goal-setting was about deciding where you want to go, this step is all about determining what is the actual starting point of your journey. This in itself is a multifaceted phenomenon.

As we already noticed, no feature exists on its own. Most likely it is built on top of existing features and needs to fit in with numerous others. It is likely that it itself will be used as a platform for further development. Map out these dependencies the best you can. Even though some connections between features might not be instantly apparent, creating a canvas of obvious ones should help to untangle the hidden ones.

This step of the process will, by necessity, involve taking stock of the current state of the project. It will also likely include examining the state of the infrastructure that the future development will make use of.

The design process is often iterative in nature. It is unlikely that the design that you are working on is already fully formed at this stage. List the open design questions and, if anyhow possible, prioritize them according to the expected impact on the rest of the designs.

Take stock of available resources, including the technical resources, but also the skills of the team members. Make an inventory of tools at your disposal.

All this will help you get an understanding of what are the missing elements, what are the pieces of the feature that yet need to be created, what are potential design problems need to be solved and what are tools and resources that you might require to accomplish your goal. You should be ready to take the next step.

O is for Options

After the previous two steps of the GROW method, you should have an understanding of the goal of your development journey and of your starting point, the proverbial points A and B.

In the terms of the roadmap metaphor, the third step of the process is about getting a clear picture of various paths that can take you from point A to B, or at least figuring out what are possible next steps that you can take to get you closer to your goal.

Sometimes, these paths can be obvious. Sometimes, you are dealing with known quantities, and the road ahead is clear. In this case, the rest of the process is all about execution.

In other cases, your task at this stage will be to actually come up with a set of viable options. The corporate coaching and performance improvement literature have a considerable body of work on various methods that might be used. Many game design teams actually make intuitive use of some of them. I will list just a few.

Five Options Approach — is what you should be doing if you already have lots of possible ideas floating around. It is supposed to bring order into the chaos. Write down, list, and enumerate ideas. List the pros and cons of each one. Prioritize them according to some criteria, such as the difficulty of implementation, the chance of success, or expected impact. Perhaps, apply some other well-known formalism to them, such as SWOT analysis.

Brainstorming Approach — is the polar opposite of the previous one. It is most useful when you have only a high-level understanding of the goal of the design, but you lack a clear set of ideas. There are many methods proposed elsewhere to efficiently run a brainstorming session in order to produce high-quality ideas, however, this discussion is beyond the scope of this text. Keep in mind though, that the result of this brainstorming will most often need to be pruned in some way.

Obstacle Approach — is applicable in the case when you encounter an obvious roadblock on your journey and you don’t have a clear idea how to remove it. The key idea of this approach is to imagine the roadblock magically removed. Try describing the reality without the big boulder in the middle of the road. What does it look like now? Ideally, this mental trick would allow you to move beyond the point at which you were stuck. By shifting the focus, you might be able to figure a way to circumvent the problem in the first place, or at least it would allow you to apply your resources on something else, potentially worthwhile.

Ideal Future Approach — involves a mental trick similar to the one that we just described, yet targeted at the even more distant point on the path. Try to imagine what the ideal outcome of the process should look like. What the reality of your project would look if you manage to achieve your design goals. Ideally, this would allow you to work your way backward, mapping out the path from the end to the place where you are standing now. This is a formalism that is akin to the way labyrinth puzzles in kids’ puzzle books are solved.

Transformative Approach — is applicable when you have something that already exists that can be used as a starting point for further development. Perhaps you already have a feature that is addressing similar problems to the one you are trying to build. Perhaps all that is needed is to boost its performance or to modify its functionality in some way to make it perform on another level. This is surprisingly often the case when dealing with established projects and live service. However, this is an equally valid approach in salvaging elements of canceled projects. Before building something from scratch it is often worth looking into what already exists that can be repurposed.

W is for Will

The result of the previous step of the process should be a list of options that you might take. In contrast, the final step of the process is about actually choosing the option that you are going to take.

Your task, therefore, is to make an informed choice, ideally the best possible one, based on your understanding of the Goals, Reality, and Options.

This choice can sometimes be hard, especially if you have several concurrent options that are competing for the same pool of resources. You might want to apply some prioritization method using some formalism designed for this purpose. For example, you might associate two numerical values to each of the possible options, one indicating the expected impact, and the other difficulty of implementation. Plotting these value pairs on a 2D diagram can help you get a clear picture of which steps you should take next.

This formal approach is reductionist by definition. Just two variables might not be enough to sufficiently describe your decision landscape. You might want to consider the alternative values, such as probability of success or risk. This process is also dependent on the precision with which you are able to determine the quantitative values you are associating with your options. This can be as much a result of guesswork as it is an exact science.

To avoid at least some of these problems, use the case by case approach.

Ultimately, when the choice is made, the remaining part of the GROW method is equivalent to forming an action plan. In most design teams this step would tap into the normal process of roadmap creation, sprint planning, and task breakdown.

Conclusion

The key takeaways — keep this picture in your wallet!

The goal of the method that I just described is, above all, to bring some structure into an otherwise messy process of game feature design. This is not a magical solution, it is not a silver bullet that will automatically solve all your design problems. It is not even meant to be. In practice, it might not be applicable in all of its aspects, yet hopefully, it might be a useful way of looking at things.

I need to make one additional disclaimer. I am not a big fan of dogma and the dogmatic application of rigid frameworks. Every method needs to be adapted to the reality of each individual design team and a concrete game design process.

Useful Links