If a car comes off the assembly line with only three wheels it’s obvious to everyone that someone screwed up. I wish that were true in the software industry. Maybe the Product Manager knows when a new email product is missing a “wheel” but does the rest of the build team? Maybe if they read the specs, but how often is that done? When was the last time the artist read the spec? I find the problem only gets worse when building social games, but we’ve stumbled upon a tool to make it a little more obvious a social game is missing a “wheel” – storyboards? Using storyboards we’ve found that we can lessen the confusion about what you’re building and even enlist the entire team in contributing to the design.
Storyboards
Of any product I’ve ever built, social games have to be the most open-ended. Everyone has a different vision in their head. Even when writing a screenplay I have a structure to cling to. Games are a different beast all together. To help get everyone on the same page we started using storyboards on my last project. Most games start with either a concept doc or if you’re lucky a full Game Design Document (GDD). As the Product Lead I would take that and write out use cases. However instead of handing those over to Engineering to start building we turned many of them into storyboards. Capturing a typical play session in storyboards we not only found it helpful in communicating the design but in advancing the design.
Allowed us to engage the entire team in design
I like to engage my entire team in building the game. Many of us are in this industry because we like games so why not collect everyone’s input. However it’s a bit cumbersome to get everyone from the Game Designer to Engineering, and Customer Service in one room let alone on the same page. Having not been privy to earlier design discussions most input isn’t all that helpful but using the storyboards we found we were engaging everyone in a more productive way.
We weren’t a room full of people with our own ideas or vision in our heads. In a typical meeting we might draw a diagram or two on one of the white board to clarify something. With up to a 100 slides in the storyboard it was equal to a 100 diagrams spread about the room. Everyone in the meeting understood the user experience with the current design, so our time was spent arguing how best to improve that design.
Highlighted issues we couldn’t see in use cases
Use cases are always helpful to highlight something you or the Game Designer might have missed. Seeing some of those use cases in storyboard form brought even more issues to light. Ultimately anything that isn’t caught in preproduction will cause trouble down the line. If it’s something major it might call for a major course correction – which no one enjoys. As they say, a picture is worth a thousand words and that certainly goes storyboards too. Never hurts to see a little emotion too, which is nearly impossible to communicate through a use case.
Improved communication
Having storyboards I think if I would use them even if I went back to typical web development. It isn’t that far from using flows to diagram a product but I feel like it goes even further – to capture more the experience you’re trying to build.
I use to say, “you never really know a product until you’ve done a few use cases, or a few hundred”. Now I might add, “and have done a few storyboards”. One of the biggest problems of relying on use cases was that few ever read them, but having a visual and one charged with emotion goes a long way in the communication department.
