Friday, December 5, 2008

Post-it note design docs


I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I'm always looking for better game development techniques that work well for this particular team mix.

Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.

  1. Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.
  2. Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn't very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.
  3. Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn't make sense.
  4. Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.
  5. Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
  6. Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.
  7. Rate: At the end, the gameplay experiment is rated according the scale below.
  8. Save: The code is saved off, a few choice notes are recorded in a doc containing our 'list of experiments' and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.
Rating system
The rating system is delightfully crude. The goal is to triage experiments quickly.
  1. "A": These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask "Was this fun? How so?"
  2. "B": These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.
  3. "C": There wasn't any fun. The experiment fails.
A portfolio of fun
One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don't fit into the game or get abandoned for other reasons, that's alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.

Contrast this with a prescriptive 'design doc' approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your 'educated' selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, "We spent 3 months of dev time on this lump of an idea and it isn't fun?"

It doesn't take very many expensive failures for the project's perceived 'design risk' to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.

Some basic observations
Here's a quick list of things I've observed when prototyping.
  • Failed experiments happen a lot. Don't be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.
  • Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can't, you likely are not suited to be performing the designer role.
  • Listening matters. The designer doesn't need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
  • You need programmers: If there aren't programmers dedicated to prototyping, the prototyping isn't going to happen. You can drop down to paper prototyping, but it usually doesn't prove out many types of mechanics (especially ones involving timing and interfaces.)
Advanced observations
These are some notes that are a bit geekier, but can save you large amounts of pain.
  • Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.
  • Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear 'level-story-level' pattern used by most FPS is one example. The 'hub with many sub levels" used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don't have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you've already discovered.
  • Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.
Benefits
There are some interesting benefits to the Post-it note design method:
  • Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.
  • Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn't work.
  • Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won't work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.
  • Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.
  • An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.
The value of dime-a-dozen designs (A brief aside)
One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.

There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.

The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the 'programming waste' is better classified as low cost learning.

Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized.


Conclusion
The "Post-it note design process" has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.

If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to 'find the fun'. Both can produce great games. Pick the one that works best for your current team composition.

This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to 'save your programmers' so they can be off running really fast in the wrong direction.

In the end it really isn't about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note.

take care
Danc,
Post-it note fanboy

12 comments:

  1. Hey Danc,
    It seems like you're discovering or re-discovering "Game Design Mechanics." I want to thank you for providing the blueprints for this Swiss Army knife of Game Making. This collection of useful tools that require little overhead but when used in combination allow for MacGyver type results. The constraint of keeping information on a post-it seems to enable a jam-session environment. I can even see this working on "solo" projects where the designer/artist/programmer has to switch hats. I'm sure I'm not going to be able to sleep since much tonight, thinking of how one might tie these sessions in to their skill atom representations and then the end result of the game. Oooh... I guess coasters/bar napkins/karaoke slips work just as well as post-its.

    Given that the post-it jam allows for the designers, artists and programmers to have the chance to ask questions and come to "get" the prototype, is there a plan for when step 4 doesn't result in something recognizable by mere humans? Does the session get an "incomplete" grade? Can there be a failure with appeal? The B-grade seems to cover this case a bit. I guess I'm just wondering if there's anything more to that timer period between "...I get called over and we play test it the experiment together." and "If the results are comprehensible by mere humans...".

    Vincent

    ReplyDelete
  2. What a wonderful article, Daniel. I've been reading your posts for a couple of years now and I find your blog a constant inspiration and also a practical manual for game design. I teach visual arts to kids at a nearby arts center, and I'm about to teach a "Introduction to Game Design" class in which I plan to incorporate a lot of your teachings. I'm so thankful there are people like you out there doing what you do! Keep it up!

    ReplyDelete
  3. Play testing
    You can skip right to 'review' if the design is unplayable after the first play. Playtest really has two sections.

    - White box: The first is 'white box' testing where the designer and programmer play it together. They know how it is supposed to work and offer expert thoughts on it. It's pretty common for the experiment to not quite be at the level where players could understand what is happening.

    - Black box: If you do get all the pieces in place where you think it would be comprehensible to people other than the creators, you can move onto more black box usability testing with other folks from around the office who haven't seen this experiment.

    Mind you this is all very informal and happens organically. You go with the flow and use your best judgement. Even though I'm calling these playtests, they are nothing as complex as a User Research session with one way mirrors and video recording. Instead, you grab someone who happens to be nearby.

    Incomplete
    There is no such thing as an 'incomplete'. It's a bit like an expedition into the jungle to find buried treasure. Each expedition lasts only a day before you need to return. You either find treasure (fun!), find a clue about the location of the treasure (but no actual fun) or don't find anything at all. It isn't like a feature that is 'done', 'incomplete' or 'not started' The exploration is about creating a measurable change in the player, not about putting checkmarks on features. This is an important distinction. One highly effective game mechanics (bejeweled) is worth more a dozen polished C or B-ranked features.

    When to dig deeper
    You have to use judgement about whether you want to keep exploring in the same direction or start off in a new direction. Some experiments will be Cs. Yet you'll have faith that there is fun there and come back with a different take on the original experiment that ends up being an A. Some experiements will be B+s, but they aren't worth pursuing.

    In general, it is often better to go broad rather than deep at first. That way you aren't committed to a design too strongly and are more open to opportunities when a crazy idea that you just had last night ends up being immensely more fun than the things you've been banging away on for the past week.

    You can use your portfolio as a guide for when you narrow down. When you've found enough A's then it probably time to start digging deeper into the treasure on hand.

    take care
    Danc.

    ReplyDelete
  4. A version of this was published in 1994 under "prototyping for tiny fingers" http://portal.acm.org/citation.cfm?id=175288

    Works like a champ for UI/UX design. I imagine it's just as good for gaming.

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete
  6. In general I´m with it, but two points. One, what is the essential gain, in your opinion, from having more than two people involved? My earlier experience was working as a designer with a programmer, this approach would have certainly cut down on the social friction between iterations. Lately, I´ve learned enough GML to do interesting stuff on my own, and found a new plane of both freedom and insight into design (I think many programmer-designers are constrained by their more narrow educations, not their skills, though naturally one follows the other).

    My other point is that your kill-process is focused on a flow-oriented model of game design, which I´ve found is only half the story. The really interesting aspects of gameplay are the capacities for our agency to be warped so that the game changes our minds, rather than our minds just changing the game. There´s an added dimension of discernment in knowing which un-fun prototypes to throw out, if they´re shallow and worthless or if they´re something altogether more interesting, a route to a new kind of gameplay.

    ReplyDelete
  7. I'd love to see some examples of the post-its designs and screenshots of the experiments that resulted from them (successful or failures).

    I've been working on an "onion" design process. My game designs tend to be overly complicated, and so I try to peel away layers until I get at the "core" of the game and then prototype that. Sometimes there's nothing there, but if there is a core, and if it's fun, I will add back a layer, and so on.

    ReplyDelete
  8. Dan:

    I love this kind of stripped down prototyping. But I worry about your controls here - by testing what programmers and designers find fun, aren't you designing games for 10% of people and not 100%? How does the wider audience get a say in developing new kinds of fun by your method?

    Cheers!

    ReplyDelete
  9. @Chris: This is absolutely a problem. First, we are testing with users who aren't programmers or designers by pulling in people from nearby. However, they still come from the game developer culture and are suspect and have biases (like a love of competitive play)

    This works okay for early prototyping (though fresher users are quite useful here as well) but not so well for balancing and finding the right 'mix' of fun elements for a particular audience. At this point, you bring in outside people from your target audience and do some more formal gameplay testing.

    It is a tricky thing to balance since you want the ability to get feedback every couple of hours. Usually, you can't get kleenex testers in your exact audience with that rapidity.

    Another source of feedback is an online beta group. This can be good as well if you can push them a build quickly (Flash games do this a lot), but you lose those all important face-to-face emotional signals. When someone grins for a half second when they knock into someone, that insight can spawn a whole new game play direction. Yet it would never show up on most remote testing techniques.

    So all the techniques are imperfect. Use all that you can, when you can, when appropriate. :-)

    take care
    Danc.

    ReplyDelete
  10. Thanks for the more detailed account! I know what you mean about remote beta testing - and this also has a player bias, of course.

    You work for a mega-corporation: can't they fund you to do an experimental play roadshow to try out some of your ideas on the "person in the street"? :)

    Best wishes!

    ReplyDelete
  11. Danc,

    I run customright.com which has iPhone Post-it for iphone app paper design & prototyping. See it in action in the video.

    I am also running a post-it note design contest. I hope you can participate!

    Kai
    paper prototyping fan boy

    ReplyDelete
  12. Still reading....

    One flaw: going from post-it to 2-day work stint is a bad idea. A post-it note can justify a few hours of work max, not a day, and definitely not several.

    If you want that much work you should go into: post-it, fuller outline (probably by the guy tasked with making it), sign-off (by you), then work.

    Plans should always grow in proportion to implementation. I realize this post is 3 years old.

    ReplyDelete