Guidelines for Creating Good Design Materials
by Mike Ellis (Design Director)
During the course of production many docs, specs, outlines, briefs and proposals are written with the intent of communicating various parts of the design. These may be anything from broadly pitching the key concepts for a new, yet to be started game to detailing out exactly how an enemy, weapon or mechanic works in isolation and as part of the greater whole.
Some of these materials inspire, inform and provide direction. While others never realize their intent, ignored and destined to clutter desks and websites until the next spring clean. What’s the difference between successful design materials and those that become tombs for ideas? Often it’s not the quality of the content, but how it is presented and delivered.
Below are some guidelines that we’re adopting here at Insomniac to ensure that we communicate effectively and achieve our goals.
The days of enormous design bibles are gone and for good reason – nobody ever read them! They were stuffed full of rhetoric and out of date before you could hit ‘print’. Aim to explain the design clearly in the shortest possible fashion. Start with proposals that are 1-2 pages long and then develop those that are approved or gain traction with the team.
State your goal.
Before you explain your design, state what it is that your aiming to achieve. Whether it be a design problem you’re aiming to solve or a new twitch mechanic you have an idea for, tell the audience what is at the heart of the matter. Then they can think on the subject in the same way that you are and have a grounding point for their ideas and feedback. This is a core part of our ‘state the problem, not just the solution’ philosophy.
Consider the audience.
The type of information and how its presented should be determined by who the materials are intended for. As we all know, artists are more visually oriented while programmers prefer knowing how things are supposed to work, parameters/constraints and data. Audio guys like to hear reference and publishers require more seductive language. They want to know why it’s going to be cool and accessible.
Be visually oriented.
Remember the adage “A picture is worth a thousand words”. Designs are often very complex things to explain and visual aids, maps, diagrams, cartoons, charts, storyboards, etc. encapsulate information and quickly render it understandable. The goal isn’t to create something beautiful or a piece of art, it’s to effectively communicate the design.
Thanks to our friend the internet we now have the world at our fingertips and effective methods for zeroing in on exactly what we’re trying to convey. We’re no longer subject to making ourselves look like crazy people as we run around the room flapping our arms and making strange noises in an attempt to mime a specific visual or replicate a sound. Movies, photos, maps, architectural plans, sound effects, music and video of other games are there for us to grab and use to strengthen our case.
Submitting a design or a proposal isn’t ‘job done’. It’s just the beginning. After the materials have been distributed and an appropriate amount of time for digestion has passed it’s time for us to leave our desks and begin discussion. By discussing with the individual stakeholders and the group as a whole we have an opportunity to explain any details that we may have overlooked or missed, garner feedback on our designs and create a stage for the other members of the team to share with us their ideas. Finding the ideas that enhance our designs or supersede them is key for making our games creative and fun.
Use and maintain the wiki.
Once we have buy-in and direction is set let’s get our designs up on the wiki where the team (and the rest of the company) can see them. Be sure to send out an email (with links) that notify people that there’s something new that might be of interest to them. We should be visiting the project wiki sites once a month and removing outdated or incorrect information in case it misleads people.