Goal-Based Design is a term of my own construction - a description of the design process I have been using in my professional life for more than ten years. It is a top-down process, primarily focused on putting effort and attention onto the most important elements first, and then filling in around them. It stands distinct from other popular game design paradigms, such as Modular Design, Holistic Design, Milestone Schedules, or Distributed Design Practices.
A Popular Focus
It has become very popular, in an online world of attention-getting headlines, to declare one element or another to be "the most essential" feature of any project. In the 90's we had vague declarations that "graphics" or "processing power" or "gameplay" was the most important feature of any game. By 2000 we had added "interface" and "camera system" and "licensed engine" as possible contenders. These days concepts like "user retention" and "analytics" are getting serious attention as the most essential feature.
Obviously only 1 thing can actually be "the most important" - that's just math and/or basic syntax. And I think any calm person would probably admit after just a moment's thought that what, exactly, is "most important" is probably different for different types of projects. But simply saying "it depends" is a pretty unsatisfactory way to leave things - humans crave answers! So is there something useful (and by that I mean actionable) we can say about games in general? I have an answer in the form of two statements.
The two statements which drive Goal-Based Design:
1 - Your goals determine which elements of the project are essential and which are not.
2 - Therefore, every discussion should begin with an agreement on goals.
It's likely that these statements seem a bit simplistic at first glance. Aren't goals obvious? Doesn't everyone agree that just making a good game is the goal? In my experience, the answer to both questions is no.
Let me give you some real-world examples of how people can spend days or even months working without a goal:
Goal-less Example #1 - task tracking gone awry
Three designers sit down to have a start-up meeting for a new project. Ideas and concepts fly around the room without any sort of organization, but everyone has a good time. After an hour or two, one of the designers says something to the effect of "we've got some good ideas here, let's write them down." All three then work to painstakingly remember their best ideas, any maybe a few other things that struck their fancy during the brainstorming session.
The next day, the designers meet with the producers, to go over the ideas from the list. The producers break the list into chunks, so each producer can come up with a plan & budget for each concept. Senior management then meets to discuss the feasibility of each plan, and eventually votes on one to move forward with, along with a preliminary budget.
This budget then comes back to one or more of the designers, who is asked to make a feature and asset list that fits within the pre-production budget... and from that point on the paperwork tracking things has become so distributed that nobody in the entire company has enough authority to ask questions like "Why are we doing this?" or "Is this the best use of our time?" Bureaucracy breeds bureaucracy.
Goal-less Example #2 - synecdoche
A designer, fed up with her lack of recent success, looks to a recent hit game. She tries to distill down the essential components of that game, and declares that they are so simple that anyone with some real design skills could build a hit game around them.
The team gets to work building prototypes of these essential systems, one or two of which really hit and produce some fun interactions. This early success galvanizes the team, and new features start to roll in at a breakneck speed. Eventually some elements will fail to gell, and the design team will go back to the inspirational game, picking it apart to see how it solved the problem at hand.
For the entire life of the project, the reference game will be an authoritative guide to mediate disputes. In some cases the inspiration is not a single game but a blend of 2 games - that doesn't change the fact that it is the desire to mimic the success (commercial and/or critical) of the source game which drives production.
These two examples won't necessarily produce bad games - but they are at least as likely to produce a bad game as they are a good one.
What makes games Different
The really exciting thing about games - the attribute which makes them difficult and interesting as a professional interest - is the fact that they are both technically complex, and creatively complex. This means that not only are the goal which drive game development hard to perceive - there are usually two or more competing goals at any one time! Trying to make a "good" or "high quality" game is not specific enough - because engineering something in a high-quality fashion is totally different from creating something which is satisfying from a user perspective. The technical and aesthetic goals compete with one another.
Because there are usually two or more reasonable goals driving every decision, having a transparent discussion ahead of time about which goals are driving each step of the process is essential. It is essential not only to make sure that everyone on the team has a clear objective - it is essential because mechanics and aesthetics each need to take the driver's seat at different times during the project - you can't simply choose aesthetics and then use that to drive every decision in the game.
It is the complex systems which make games what they are which demands complex solutions, and shifting goals. Recognizing the importance of shift during development is what makes Goal-Based Design the only reasonable way to move forward with a complex game.
What Consequences does this bring?
So if using Goal-Based design is essential, the next question becomes: how is Goal-Based design different from what successful teams are already doing?
Every successful team I have been a part of, or had intimate familiarity with, has been successful because some members of the team were decidedly goal-based, and had enough authority to keep the project on track. The advantage of formally declaring that your project is goal-based is that it allows any member of the team to ask reasonable questions, and have a good chance at understanding the answers. It is very difficult, without open and transparent communication between team members, to distinguish between Goal-Based design and Despotism. Understanding the why of decisions is an important way to keep every specialist on your team moving forward, because a good why allows them to focus on their work.