|
In discussions with friends who work on collaborative projects in and outside of games, one question came to mind:
Can a QUALITY product be completed WITHOUT a designer?
The conclusion we came to was a conditional "yes", but only if either of these two things were true:
- Each member of the team was fully capable of cohesively visualizing the ramifications of their component before actually implementing it
- There was infinite time to iterate on the implementation of bad ideas until they become good ideas
Time is rarely infinite and trusting everyone on the team to maintain a cohesive vision of the product can be a gamble. For that reason, most projects will involve people whose role it is to supplement the team's ability to visualize the details before time and resources are spent on the implementation of those details.
Depending on the industry, the people that perform these functions hold titles such as Producers, Directors, Project Managers, Product Owners, Designers, or Planners. The idea behind these roles is two-fold:
- Thinking about ramifications warrants a fulltime job
- The cost of thinking is cheaper than the cost of doing implementation work that will be discarded
So... what are the metrics of a "product owner"?
I believe that every industry can distill the evaluation of this pivotal role into three distinct categories:
1. Pre-Visualization
How good is the designer at running simulations in the brain before committing resources to the design? Nobody will be perfect at this... iterations will be a fact of life in any industry involving collaborative creation of product.
There are two ways to derive a solution to a problem:
- One way is to throw random darts at the problem until a solution hits... and hopefully they will recognize the solution when they see it
- The other way is to incorporate the problem into a mental model with an effort to define success and failure conditions so that experiments might be methodically mapped within this mental framework
The "methodical" designer will cost production less money than the "random darts" designer.
Sample Pre-Visualization Screening Questions:
- Design a product about X with constraints Y
- What would happen if you do X?
- Solve this open-ended problem
2. Converting Thoughts to/from Language
Pre-Visualizion takes place inside the designer's head, but that work needs a reliable channel in order be converted into meaningful tasks outside the head.
Team members (including the designer) may not have all of the information needed to perform their function. The translation of ideas into sequential words within a sentence can certainly have more influence on the product than the translation of sentences into code.
The best designers I know have a way of communicating not just their ideas, but also the philosophy behind their ideas to the team. These designers serve as a creative mentor infecting the rest of the team with a galvanizing aesthetic compass. This transferrence of philosophy in addition to details gives implementors an opportunity to incorporate the core values of the design into their own decision-making process.
Sample Communication Screening Questions:
- Describe a product you like/hate and explain why it is good/bad
- Teach us how to do something complex that you are an expert at
- Solve this open-ended problem... ask questions as needed
3. Managing Relationships
Even though communication may be clear, debates may still occur. People will not neccesarily follow blindly. Unless the designer is going to work alone, this person will need to deal with people factors.
I have seen many highly skilled designers felled by a fatal flaw in this particular category. The pattern was often the same:
- Person is highly skilled and competent (or just overly confident)...
- Person expects everybody to be like them (i.e. agrees)...
- Person antagonizes people who are not like them (i.e. disagrees)...
- An authority figure (or figures) realizes that the cost outweighs the benefit
... or in the other direction, people quit the team or become dysfunctional because of this breakdown in relationships.
Like othello, the science of relationships is said to take a minute to learn and a lifetime to master.
Conclusion
Few developers ever say that they are a bad designer. Most people on a development team firmly believe that they are good designers; I suspect that this may be the same proportion of people who believe that they are good at cooking food because they are consumers of food.
Whether in or outside of games, the design discipline is responsible for managing the target aesthetics of the final product. Design, Planning, and/or Product Owning is a skill-based discipline with three categories of metrics that serve as qualifiers of competency within that discipline.
If you find yourself in a position to develop an interview process for a design position, then feel free to incorporate three RPG stat trees into your interview process if you haven't already:
- Pre-Visualization
- Communication
- Diplomacy
... and if you are in a position to interview for the position of "designer", then it wouldn't hurt to consider where you might fall within each of these three stats.
|
I ask this because, while I fully agree on clarity of information and concise, structured specs, I met developers who did tended to simply ask for too many details. I want to know where do you draw the line, because presenting a vision, a philosophy, a concept is no easy task to do (and therein lies the value of any creative person, in my opinion). Beauty is in the eye of the beholder, in the end, even if it seems like everything is clear.
As for metrics, it would be really cool to conceptualize something to use in this regard, but impossible to standardize them. They can at best be designed per project and per team in strict correlation, so I didn't find your title misleading.
I agree with Laura that the designer evaluation exists per project and per team. A test for a street fighter designer is probably not appropriate for an MMO designer.
@Laura: Thank you for the kind words.
I have seen the detail problem as well. In the other direction, I have witnessed the 300+ page design doc that nobody reads. On this, I believe that the relationship between designer and implementer is a two-way collaboration that works best when channels of feedback and response are maximized. Different people have different communication styles and needs for information. Some programmers tend to ask for too many details because they may feel disempowered to "design" (would rather somebody else be wrong on design than them). I may be biased, but I like the idea of gameplay programmers (such as myself) who are empowered to fill in the blanks left by design while engaging in constant feedback (and iteration) loops with a designer from conception all the way to post-execution. The feedback loop not only reinforces the quality of the design and its implementation, but it also gives both sides repeated practice in working together within this context.
About where to draw the line... I like the idea of the designer taking ownership of the WHAT (big picture) and WHY, which gives the programmer/artist/level builder the direction needed to own and become an expert at the WHAT (minute details) and HOW.
To answer your question ("do you consider yourself able to be the designer you describe or not?"), I developed these values after being mentored by some very good designers, and I have found that striving to maintain these values makes it very easy to work with designers... So I would like to believe that I might do well on an evaluation if the project and team were like mine (emergent sims), but I will probably do very badly if I were being evaluated for a design position on business application software :)
Systems/technical designers.
Senior level people. Responsible for implementing systems (like inventory, save/load game, mission objectives etc) on a "design side". Create mission "templates" and other re-usable parts. Main point of contact for engineers. For them, good knowledge of whatever scripting language is used in a game (lua, unreal, C#, Python) is a must. "Systems", logical thinking and ability to take ownership of several systems is required. Basic knowledge of C++ and game debugging is a good plus. Knowledge of visual scripting systems, how systems are done in popular games is greate too. I think people who started in engineering "long ago" but wanted to work more on a game/design side are the best for such role. My favorite type of designers ;)
Mission designers.
Well - they make missions. Place mission objects, hook triggers, assign enemy AI types, create combat encounters and tweak them till they are fun. Ideally - they would know how to use a set ot "tools" that systems designers/engineers prepared for them best. Some mid/basic-level scripting knowledge IMHO is very valuable (on some games - required). Knowing a lot of games, what made particular levels, particular encounters in them "fun" is a must. They usually need to be very good players too.
World builders.
Not all games have them - but for games with "big worlds" they are good to have. They populate the world - create terrain, foliage, rivers, bushes etc. Position main cities and structures. Basically - build the foundation - and mission designers add mission specific objects/scripts on top of those. I saw them also actually making some objects - bushes, trees, environmental peices, terrain textures. They are half artists - half designers. Usually - do not need technical knowledge.
Writers.
Create dialogs, overall story, setting. Might not be technical, but need to know how to use (typically limited) game/engine means to express character moods, personalities, fill in "ambients" etc. Have to be able to come up with a few (the more the better) good jokes.
Design leads.
The guy who thinks he know what this game is about :) and trying to make people around him to implement this vision, and people above him to pay for that :) Well, together with director/producer. Can come from anywhere, but I think typically ex mission designer with good logical/organizational skills or systems designer with a good eye for fun gameplay. There might be examples of writers or world builders becoming good design leads - but I think not in my experience.
Well, and sometimes there are specific designer(s) for "social aspects" of the game, for game balancing, for cutscenes, for "multiplayer" etc.
This article originally started out as a conversation between myself and some accomplished tech-professionals outside the games industry. We were feeling out the commonalities of our fields as a means of breaking down some common patterns that arise from industries where thoughts get turned into 1's and 0's through a collaborative process.
Whether you are designing gameplay, level geometry, narrative, production schedules, or code architecture, I believe that these three axes are an effective galvanizing compass towards the development of your screening process.
:)
As a student studying at Masters level, I've had a lot of practical experience in both design and production in a safe, protected environment, and its been very insightful.
I've seen pretty much everything you've said here - I began assuming that design meant producing heaps of documentation that nobody would ever end up reading, and I've seen the chaos that erupts from a project in which nobody holds the vision of the final product.
I think the last point simply can't be overstated enough - a designer needs to be able to work closely with everyone on the team, and needs to be approachable at all times. I can't imagine doing my job in my current position (as a designer on a game) if I couldn't happily interrupt someone else to talk about a feature or vice versa.
No comment except that this is a very smart article.