There is no right way to be a designer in the abstract, just as there are no good designs in the abstract. Context is everything. Today, I’m going to discuss one particular context – the role of the designer on a small team. By small team, I’m referring to a development team of under 20 – this might be a startup group, a splinter team off of a larger group doing preproduction, or a live team environment. The key factor here is a scarcity of resources. As a game designer, you’re a problem solver. That means solving game problems, but it also means solving development problems.
1. Justify Your Existence
On a small team, the game designer has another title. ”The guy (or gal) who can’t write code or do art.” Awkward.
This isn’t to say that game design isn’t a critical skill and meaningful art to deploy in a small team environment. But when the results of your labor do not immediately impact the quality of the build, it can be very easy to slide in to a directorial role, and that’s not where you want to be at all.
Instead, look at your team’s process, and search for ways to improve the lives of your teammates. Maybe that means acting like an associate producer and running down tasks and dependencies. Maybe that means busting out your limited art or programming skills and pitching in wherever you can. Maybe that means running out for donuts. The point is, you want to stay on the team, not above the team. And you do that however you can.
2. Think small. Act small.
One of the big advantages to being on a small team is that you’ll get the opportunity to get to know the strengths and quirks of each of the individual members of your team. Take the time to find out how best to communicate with each of them. If you’re writing a doc for an engineer, take the time to find out how that specific engineer likes to have information presented.
Especially when the scope of the project is relatively small, spend a little more time down in the weeds. Worry about details. Focus on the details that might get overlooked because your small team lacks specialists in certain areas. Going without a dedicated UI specialist? Spend more time working on interface design. No audio engineer? Spend some more time writing up the detailed needs for sound and music when you outsource it. (Did your team totally forget about audio? Whoops. Don’t feel too bad. You’re not the first.)
3. Prepare to not be small.
When preproduction ends, your team is going to grow. When your demo gets you a second round of funding, your team is going to grow. When your indie game hits it big, your team is going to grow. In the business world, if you’re not growing, you’re probably dying. So, as a small team designer, think about what that growth looks like. As you approach the cusp of growth, find the person on your team who has lost the most hair in the last three weeks. (That’ll be your producer.) Make time to help create a transition plan. You’ll be in an excellent position to know which areas of the game are going to benefit most from growth, and which areas of the game should stay small, and which individuals would be best suited to stick with what systems, and what skillset new people on the team will need to have to fill gaps.
Sound like a lot to keep track of? That’s small team design. Lots of hats, lots of surprises. Good times.