First off I want to apologies if I do not post anything over the next week. Things have come up that will no doubt keep me busy for the time being. With that in mind I want to talk about something that popped into my head. I remember the times in college when I had to create design documents that would be the be all, end all documentation for a given project. From a design and production standpoint it was a necessity and an asset. Then I remember telling my programmers and artists to read it…..
Yeah right, I was better off trying to pick a fight with a pigeon outside the office than getting them to read that 50+ page documentation. A saving grace of online technology, aka the use of wiki’s for documenting, has alleviated this process for said team members. Yet this bring with it similar problems in a different form; 1) they don’t want to read it from beginning to end, and 2) they might miss over aspects of the documentation that might appear to be given for a designer.
I remember my artist coming up to our designers and saying “wait, when did we had this feature” with a response of “since the beginning….didn’t you read the documentation.” Their response, “oh course I didn’t, I have art to create.” As much as I would like (well, more like need) everyone on the team to be on the same page I also know that some members have a ‘get to work’ mentality that pushes them to be productive and active.
With that said I will break down the FINAL DOC (adhoc name, call it whatever you want). Here’s the documentation format in a nutshell:
– Each section of the documentation starts with a bulleted, brief summary (no need to going into detail). This allows team members to grace over the bullets to see if what they are looking for is in this section.
– Following the summary section comes the designer’s section. This is the content heavy section that probably scares of the majority of the team (the “I don’t want to read this” section). This section is geared towards the designers, level designers, producers/project managers, QA (more or less depending on team makeup).
– Following the design sections are the specialized sections. Ultimately there should be one section for each “sphere” of the team. By spheres I mean the broad categories of the team. This includes, but is not limited to, Artist section, Programmer section, Music section, Marketing section. The team could also throw in a Production section if they wanted, but the producers probably have their own documentation that would cover this section.
Why these additional sections? I’m a scenarios man, I’ll look at a given situation and say “alright what’s the best thing that could happen, what’s the worst, and what are possibilities that happen in the middle.” Best case scenario is everyone reads the entire document, is happy, and receives free beer and chocolate as a reward; probably not gonna happen. Worst case scenario is a given person asks “what do I have to do for this given aspect/feature.” So what do you do, you tell them.
– I would probably also add a link in the summary section a link to each section so that a team member is one click away from getting to the nitty gritty of what they need to do. We could say that Life Made Easier is one of the mantra’s associated with this documentation style.
On a final note I just want to add a little insight that I’ve noticed of the years of review and writing different documents. One could say that having more detail is better than not having enough detail (think about camping, you’re better off having and not needing then needing and not having). However, if sufficient detail is enough to get a point across then sufficient detail is all that is needed. Bizarrely enough I’ve seen team members get thrown off rail when they come across more information than they expected (almost counter thinking, but it’s happen to me). That’s all.
So that’s my long winded thoughts on design documents. Thank you for reading.