This is the second in a series of six blog posts where different disciplines share what they wish others would know and understand.
The stories we live over the course of our careers shape the way we see each other and affect our work together. ‘10 things you should know about ...’ is a series prepared with game developers to share what we feel and hide from each other as we collaborate on a game. Agree, disagree, share and add your own to complete the picture.
1- I am as confident in this design as you are that your new feature is bug-free, that your development plan is accurate or that your palette choices are flawless.
2- What makes a good design great is not creativity, ingenuity or cleverness. It's time.
3- Designs are there as much for me as there are for you. When you ask a question and I reply with "Did you read the documentation?" I promise I am not withholding - I just need to check it for the answer too.
4- What's best for business is not always what is best for the game. Sometimes I need to be reminded of, and accept, that.
5- If I am reluctant to "Try this one first ..." I am not being stubborn out of spite. More likely it's because in past the "... and if it doesn't work ..." part happened but the "... we'll try it your way" didn't.
6- We do not analyze metrics and user feedback to undermine the producer’s expertise, rather to help listen to our players.
7- If I seem annoyed when you ask me to explain design decisions it's because I feel you're asking me to justify decisions I have just spent hours (or days) refining and I feel you are questioning my credibility as an expert.
8- Developer tools need to be designer-friendly just as designs need to be developer-friendly. We can make each other’s goals our own.
9- Design is everywhere, but great design is invisible. The thing I'm asking you to schedule in, or mock-up, or code may seem too insignificant to spend time on, but it's the invisible things that make experiences magical.
10- Expecting me to get the design right first time is as unlikely as expecting a programmer to deliver bug-free code. It’s complex to arrange because design comes first, but I need to be given a little room to try and fail just like everyone else.
Written with the contribution of Tim Aidley, Jordan Ault, Dave Hollingbery, Mark Lintott, Kim Russell, Rik Skews, Chris Solarski, Will Sykes, Sean Turner and others who wish to remain anonymous.