At the Office

Home

On the Couch

At the Office

In the Library

Mailbox

Neighborhood

Pitfalls of the Working Game Designer: Not Defining Design

It may seem like a no-brainer that the role of the designer on a team needs to be defined. However, as fundamental as this is, there is no standard definition you can rely on. Every studio has a different sense, a different history, a different structure of working with design. Even within a studio, the role of design may vary by team based simply on the personnel involved. A producer with strong design skills may want a different working relationship with a designer than a producer who doesn’t want to be involved with the design. An engineer or an artist may drive elements of the design simply because they have the skills and experience it takes to come up with good designs.

This confusion is compounded by the fact that designers wear many hats as part of the team, sometimes switching roles several times in one meeting. At different times, the designer is expected to be a storyteller, a play-tester, an efficiency expert, a cheerleader, a marketer, a mediator, a sounding board, a visionary, a leader, a level builder, a scripter, a historian, a sociologist, and a psychic. Design is not a simple task. You can never have too many skill sets as a designer, and you need to constantly work to improve the ones you do have.

In this environment, it is easy to lose track of what exactly design is supposed to do, how the design group relates to the rest of the team, and where their deliverables fit into the rest of the schedule. Simply defining the design deliverables can be a slippery task. The worst solution, however, is to “play it by ear” or take an ad hoc approach. This can produce not only confusion but conflicts within the team, as everyone brings their particular expectations or needs to the table.

The first issue that has to be tackled is the relationship of design within the team. The industry is rife with the buzz words “consensus” and “team buy-in”, but without a solid structure in place, these are simply ideals and not a working process. The decision-making process for design must be clear and explicit. Consensus is a valuable goal, but there will be situations where different members of the team simply cannot agree, and in those cases, there needs to be a final authority. That authority can be the lead designer, the team leads, the producer, management, the publisher; in the final analysis, it doesn’t matter who plays that role so long as everyone knows who it is and how to get a final decision.

Similarly, where, when, and how team input into the design happens must be nailed down. The team needs to know that their input has been received, that it has been considered, what has happened as a result, and why. The only thing worse than not having any input is to have the appearance of input with no actual contribution happening. Without solid processes in place, team input may get neglected simply due to time and resource limits. The less information the team has about the design process, the more mystifying it will seem to them, putting the goals of consensus and buy-in completely out of reach.

The second issue is to define tasks and deadlines. The most conscientious designer will work inefficiently without specific goals. Ideally, the designer is out in front of the team on most issues, but they can’t stay out there without knowing what the team needs and when they need it by. It’s altogether too easy to get caught up in one issue or element of the design and spend days working out the fine tuning; in the long run, all of that work may be worth it, but if the team (or management) needs something else in the short term, you’ll lose in team productivity what you gained from the finality of the design. The concept of “just in time” delivery or milestones for design may or may not work depending on your specific team structure, but regardless of the approach you take, the deliverables of design need to be defined and scheduled regularly, just like any other element of the project.

Ultimately, there is no “one size fits all” solution. Every project will have different requirements, priorities, and schedules. In the same way that an idea has no real value until it is translated into a design that takes the constraints of the project into account, a process cannot work independently of the situation it takes place in. Design is a project-specific task, not an abstract process. As such, you need to have a practical plan in place for who is going to do it, what it consists of, when it will get done, and how it will be finalized. Leaving any of these issues up in the air is a gamble you will lose much, much more often than you will win.

Next: Too Many Cooks
Back to Top
Previous: An Introduction

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood