Good Ideas make for Bad Designers — (Part 2 of 3)
A love letter to people who pointed out my mistakes and helped me get better.
Game designer, or simply designer, is not an easy job to explain. For how many times I’ve tried to explain it to my parents and their friends, I know it is a way more abstract activity than Artist, Programmer, or even Producer. I usually describe it as “defining the rules of the game, the way the different systems should behave and interact, in order to create the intended experience for the player”. Sooo clearly, it doesn’t dispel all questions.
And so I get why you could try to reduce it to “imagining games” or “having ideas for games”. But as we explored in part 1, there is little base in reality, if any, to support the belief that the role of designers is to have ideas or that successful projects are based on good ideas.
And we could stop here, but I argue that we should actively challenge this perception. We should not settle for this oversimplified version of reality because this perception shapes more than just how we explain design. It shapes what aspiring designers expect, what we expect from them, and how we perceive the role of all the other actors of the industry as well.
Failing to live up to the story.
Remember when I said becoming a game designer, things never clicked how I hoped they would? Well, here’s the part I haven’t told you about:
This made me terrified.
For months, I refused to ask for help, to show my work early for fear of being judged. For fear of being uncovered as a fraud. What would they think of me if they realized my ideas didn’t work? That I sometimes had no ideas? This led to catastrophically bad decisions, terrible designs, and those mistakes being more exposed and visible than ever as a result, which fed into the negativity cycle of doubting myself and my abilities.
Hopefully, it eventually got better. My design began to work as I hoped it would. On the first try, sometimes. My mistakes were smaller and easier to address. So what happened? I got used to it? I got more experienced? None of that.
No, what changed is I got help. I was lucky enough to be a part of one of the most amazing teams I have ever worked with, and they realized that I needed help even when I myself would not admit to it. And they provided that help without any judgment. They showed me the way by showing me their work and asking me for feedback. I realized that even designers with almost ten years of experience still made mistakes and benefited from feedback and help. And so I slowly started to heal from these toxic beliefs I used to hold.
And I know I’m not the only one who has experienced this.
This story is bad for everyone.
Stories and myths we believe and repeat are not just that. They inform a vision of reality that is easier to grasp, less complex than the real thing, and often more satisfying and compelling in its structure. Because of this, they become easy and convenient reference points about a topic, a historical event, a concept, or anything else.
This, however, can become problematic when the myth becomes the only or the most dominant reference point for people who do not know the reality and haven’t experienced it for themselves. At this point, the story actively clashes with the reality it is about, as it shapes people’s expectations and actions based on what they believe to be an accurate representation of reality.
And from my own experience and many testimonies I heard, I am convinced this myth is doing exactly that. It is informing an inaccurate representation of what game development looks like, reinforcing counterproductive behaviors and practices and unfair expectations, impacting everyone, from designers, to the team, to the industry as a whole and the project itself.
Bad for designers
You might think this story is actually very comforting and ego-boosting for designers. After all, they’re the heroes in this story; they’re the people being looked up to, the ones getting credited for the success of the game.
But no matter how flattering it might sound, I want to argue that having good ideas is a very unfair and discouraging standard to hold or to be held against. It is most often seen as an innate quality and highly dependent on luck. It is not something you can train or gain control over. And when we only judge the idea, it is as much a judgment of the person having the idea as it is of the idea itself. The fact it is a compelling narrative might make it even more destructive to young designers.
In Redirect: Changing the Stories We Live By, psychologist Timothy D. Wilson highlights how we shape our actions to preserve the narratives we tell about ourselves. And how when we fail to meet those criteria, we feel like we don’t live up to who we thought to be. Studies he and his team conducted show when met with failures, students who attribute success to innate qualities like intelligence tend to think that they are simply not intelligent enough to succeed and are then more likely to give up and drop out.
If the success of the experience relies solely on the idea, then if it doesn’t work, it means it was based on a bad idea. If it was based on a bad idea, then I had a bad idea, and I am not as good a designer as I thought. If I’m not a good designer, I’ll never have good ideas, and I have no place here.
I’m still drawn to this idea even today; I still doubt myself when I propose something and hear someone else instantly demonstrate how flawed it is and make a perfectly viable counter-proposition. But now, I fight back against this feeling. Because I know that every time someone shows me a mistake I made, I become a better designer as a result. Because, and that’s the real important lesson here, having ideas is NOT my job. My job is to fix problems.
The true job of a designer is about problem-solving. Good Ideas make for Bad designers because you only progress and get better when you face challenges and work to solve them. You become a designer when the idea fails and succeed when you MAKE it work. Not because it naturally works.
Also, remember when I said the myth of the lone genius was not unique to games or design and existed in science and other domains also? Well, it’s destructive here, too, it seems.
And if this perception of creation puts a lot of pressure on the shoulders of designers, it also deprives this credit of all the other members of the team.
Bad for the team
Ideas are uncollaborative by nature. A plan, a design, a solution, all those things can be crafted by many people. But when we speak about ideas, we mean the first impulsion someone got, a proposition just one individual made. And so, when we praise the idea, we praise this individual contribution only.
It turns creation into a zero-sum game. If two or more people propose ideas and one works, then it means this person and only this person solved the problem. This is a heavily egotistical and self-centered approach to what is supposed to be a team activity. It makes us less likely to accept feedback and propositions from other team members because we don’t want to feel useless, and worse, it often makes us happy to see other people’s ideas fail because it makes us feel useful and justified.
But none of that is true. Providing the feedback that will help identify the issue, participating in the discussion, proposing solutions, implementing it, and testing it to see if it actually solves the problem, why should we celebrate one of those steps above all else? Well, because this is how we (most often) envision creation.
But even among all the jobs undermined by the belief that their success relies solely on ideas, one is the most criminally underestimated: the role of the testers.
Bad for testers, especially
A recurrent element among all the success stories we’ve looked at is how the turning point in developing all those projects always comes with acknowledging the project’s problems. Recognizing and working toward fixing those mistakes is demonstrably what made those projects work, not the initial idea they were based on. And that’s why it is so unfair that the people whose job it is to identify and point out those problems are the ones whose jobs are seen as the less valuable.
I remember reading many articles when I was trying to get into the game industry about QA Testing being an entry-level job toward becoming a real game designer (strangely enough, I also remember many articles saying the same about level design). Today, I feel like it is much more understood that level design, game design, and other specialties are simply different disciplines, each with their own set of skills and challenges. But the same cannot be said for QA testing yet. I still occasionally stumble across “inspirational” stories of QA Testers being so good at their job that they’re promoted to Designers.
The thing is, most QA Testers I’ve worked with indeed expected to move on to another job at some point. And I can’t blame them, seeing how they’re being treated and seen as expandables in most companies. I’ve worked at companies whose entire test team was comprised of interns (even the team lead), and others where we simply didn’t have any testers (so I can really appreciate the value a good tester brings to a team, believe me). And what’s making my blood boil is looking at all the stories we’ve mentioned so far: they are always the unsung heroes. Not only do they get no credit for their input to the game, but they get most of the blame and hate from the players whenever something goes wrong.
In every story, the turning point that made the game a success didn’t come with the genius lead of the director or the inventive ideas of a designer. No, it always came with feedback highlighting the issues to be addressed. And of all the team members, the testers are the most likely to identify those problems. They know the game better than anyone else but have a distant enough vision to avoid most of the biases designers have for their own work. Whether they are playtesters or QA testers, their feedback demonstrably impacts the game and its direction. And it’s a shame that the role is not more credited, paid, and recognized for its value.
Because it leads to invaluable people being exploited and burnt out to the point of leaving the industry, which is both unfair and a loss for them, the team, and the project.
Bad for the industry
Finally, and this seems almost too obvious to say at this point, but when we only praise the people at the top and neglect to mention the people working under them, we praise and present a portrait of what a “good designer” looks like that is incredibly narrow. We reinforce the biases that make people of a certain gender/race/else more likely to get management jobs by only celebrating people who match those criteria as responsible for the success of their projects. Representing the whole industry only by the 1% that sits at the top.
The game industry is already lacking a lot of diversity in more ways than one. And while this is clearly not solely responsible for this, it doesn’t do anything to make it better either. And I want to clarify that this doesn't say anything about whether the people we praise are skilled and if they are indeed giving all they have to the project. I’m not saying those people do not deserve to be praised and recognized for their work.
But by only crediting those few people, neglecting all other persons and factors contributing to success, we miss how necessary they are to reproduce this success. We evaluate a project's potential based only on who is leading it and not who are building it.
And this isn’t good for anyone because those people we praise are, in fact, as fallible as anyone else.
I am now convinced this belief is unhealthy and leads to unhealthy expectations and practices that make the work of everyone more unnecessarily difficult.
But even if you do not care for workers, for unfair expectations, uncredited and undervalued work, and all you care about is the game itself, this, is still a problem. This is still something to be concerned about because of the amount of control and trust we put in the hands of people who ultimately cannot make the success of a project on their own.
And this is what I intend to demonstrate in part 3. Why this is also ultimately bad for the game itself, and thus, for the players as well.
