|The Tenth Annual Game Design Think Tank
Project Horseshoe 2015
|Group Report: Best Practices for Design to Communicate with Other Disciplines|
|Participants: A.K.A. "Team Dynamics Duo"|
|Link Hughes, ArenaNet||Nick Laing, Turn10|
|download the PDF|
Brief statement of the problem(s) on which the group worked:
What are the best practices for design to communicate with other disciplines?
A brief statement of the group’s solutions to those problems:
We discussed various aspects of discipline responsibilities, communication techniques, and other related topics. Ultimately, our best takeaway is that standardized documentation templates are very useful for design to think through all of the answers to questions they are likely to receive from other disciplines. In recent years, there has been a general move away from such standardized design templates toward alternate paradigms such as a focus on diagramming as the sole design documentation solution or a sole focus on prototyping and iteration in order to use the game as the only living document of the design. While these solutions may be tenable for very small teams and projects of very small scope, at any appreciable size, standardized documentation will help predict answers to questions from collaborators and reduce found work. Even for very small teams, completing a standardized design template should still help achieve these aims.
That said, there is a reason that design, industry-wide, has drifted away from design bibles. The fallacy of the designer writing a master document, handing it off, and then relaxing on vacation while the team implements this grand vision obviously never worked and we’re not implying that it can. These standardized design templates must be customized to the needs of a given studio and/or type of project, and must be living documents, with sections added or removed as work is discovered or found to no longer be useful. The purpose of “standardizing” them is to make sure that the needs of all other collaborators are considered, not that design is shoehorned into some one-size-fits-all solution.
We also discussed the challenges that different definitions of the same disciplines across the industry create. Because of the rate of turnover and the resultant professional cross-pollination, there is a baseline amount of static in the communication channels between disciplines. Understanding the motivations of the functions that various roles serve at different companies can help overcome this effect.Finally, we discussed whether it would help things for design to teach basic design principles to their collaborators or if design should seek to speak the language of the other domains they work with. Our discussions on this point were inconclusive and bear further exploration. That said, we did discover that metaphors can help bridge the gap between domain languages. As an example, programmers and designers can shortcut confusion over how solid a given design is—and thus how robust the implementation for that feature needs to be—by referring to the code needed for a design with a high chance of changing as a “red brick,” while referring to the bulletproof code needed for something that is much more certain as a “blue brick.” When asking a programmer to build on a red brick implementation, there is an understanding that time will be required to upgrade that implementation to a blue brick. The problem with these metaphors is that only a person who speaks both of the domain languages that a metaphor is intended to bridge is likely to be able to establish a useful metaphor.
select a section:
Copyright 2000-2015, Fat Labs, Inc., ALL RIGHTS RESERVED