The Joel Test is a great 12 question litmus test for programming team efficacy. I’ve devised a similar test for design teams. Design teams can really make or break a company, seeing as to how design is effectively steering a boat. You could have a great design with an allegedly impenetrable hull, but if you have nitwits at the helm, congratulations you have the Titanic.
Got a sinking feeling?
There are a few measures that aren’t 100% foolproof seeing as to how nature is capable of rapidly iterating its way to a “superior” idiot, if you can say “yes” to all of these at your company, that’s a good thing.
- Does Design use source control?
- Is there a centralized wiki/internal website/physical bulletin board where you can easily view schedules & tasks?
- Is the process of determining if a task is done clear and understood by all?
- Is there proper risk assessment and analysis conducted for all design decisions?
- Is the spec kept up to date?
- Do you use the best tools possible?
- Do you have a good relationship with QA?
- Do you do hallway usability testing?
- Do designers shut up during hallway usability tests?
- Are the results of hallway usability tests turned into plans of action?
- Is there a place designers can easily meet with other team members to discuss matters without distracting other team members?
- Do the designers play the whole game regularly?
1. I’ve seen source control used for code but not other types of assets. This is absurd. There are times you absolutely have to look at previous versions of spec and potentially roll back designs as programmers occasionally have to roll back code. It sucks, but it’s important to back stuff up.
2. Know what you need to be doing? And what you have left to do? Makes it easier to manage your time when you know what you need to do and by when.
3. So, who says whether something is done? How are these criteria determined? A lack of clear goals will kill focus, leaving people to thrash like fish out of water never sure if they can move on or not. A lack of clear goals and how to achieve them creates massive anxiety.
4. Implementing anything is a risk. Meaning it will eat money and time(salaries, electric bills, another word for more money) to do. Some features run the risk of not working as planned. Or just not being feasible altogether. Risk management is another word for looking over things and seeing “this is important, this is not” and “this is worth spending the money to make, this would be nice if we had the extra cash.” If anyone says “we’re doing EVERYTHING!” run away. Run far far away.
5. Due to the iterative nature of finding the fun, it’s always worth asking if design documentation is up to date. The testers will want to know how things are supposed to behave so they can easily differentiate bug behavior from expected behavior. You’ll waste a lot of QA time explaining spec in bug reports vs just handing them an up to date spec.
6. Making ANY department waste time working around cheap tools is false economy.
7. Intelligent capable testers are worth their weight in gold, platinum and ink jet printer ink. In addition to bugs, the capable ones will no doubt find odd patterns, difficulty spikes and other issues.
8. Your friends in QA will no doubt get used to your game, bugs and all. Hallway tests are for getting usability bugs that only a fresh perspective can really give.
9. For these usability tests to really be valid, no hints! Sit down and shaddap. If your interface isn’t well designed enough for a new user to understand what to do, it’s not well designed. Fix it.
10. If your hallway tester finds something un-fun, wait until the marketplace gets a hold of it! They’ll love it! More like they’ll love writing smarmy reviews about what big idiots the design team is and how they can do better. Even the biggest Luddite they know could do better.
11. Not breaking others’ concentration is important, but being able to talk about issues freely is vitally important. Communication is everything in this study by Paul Tozour.
12. Do the designers play the game and the WHOLE game, not just the portion they’re assigned to cover? Maintaining continuity is difficult. Shigeru Miyamoto’s method of creating the first level last is a smart method of making sure players are equipped to handle challenges as they come(heck, I’d say design a level backward and create the boss first.)