As I’ve mentioned before, one of the core assumptions we have at Filament is that when a Client hires us to make a positive impact game, it’s because they can’t do it themselves. It’s not always true, as some clients may just need more development firepower than what they have on hand, but by and large most clients are hoping that they can work with us to add design and development expertise that they lack in-house. And that’s great!
But that means that we have a challenge at Filament- it’s one thing to make learning games, which is a weird and challenging enterprise, but it’s another thing to explain the decisions you’re making ABOUT making learning games, while you’re making them. Add in the fact that your collaborator is probably not a game developer or game designer, and now you’re looking at having to strategically develop ways to talk about how you’re making a thing that lets them provide THEIR expertise.
I’ve noticed an interesting phenomenon while working with clients who’ve had wildly varying levels of experience in design and development, which I humbly submit as an idea tentatively titled “The Fidelity Rainbow.”
The Fidelity Rainbow represents the level of “realness” that you need to show a client in order to engage them in problem-solving an idea.
On one side of the rainbow, we have the lowest point of fidelity. These are napkin sketches, stick figure drawing, Lorem Ipsum text, black and white storyboard, etc. These documents are stripped down to be absolutely and obviously NOT the final product in any way. The information present is intended to provoke ideas, and clients are expected to think about things like progression, mechanics, and other essential design-level ideas, and not fixate on things like UI, art, animation, etc.
Example: at one point I had developed a set of example wireframes for a game where the player had to choose one of three topics to explore. They were shown as points 1, 2 and 3. Then, as a joke that *I* thought was funny, I wrote placeholder text all about the number three (“The history of the number three” “Famous people and their usage of the number three” etc.) However, when I reviewed this with the client, I didn’t get the wholesome chuckles that I had desired, I instead found out that they were worried that their project had turned into a game about the number three. Quick tip: placeholder or joke content is used at your own peril!
On the other side of the rainbow, we have the highest point of fidelity- the thing itself. This is either literally reviewing the game as a finished product, mockups, prototypes, animatics… basically materials to review where the reviewer can assume EVERY decision presented is up for evaluation. Move slowly up the fidelity chain, and clients can become confused about what aspects are intended to be real and what aren’t.
Example: At one point I took a finished game that we had developed, and showed it to a third party. They politely watched as I walked through how the game worked, and when I had completed it, their first question was: Was this actually a game, that I was controlling, or were we watching a show? Even the smallest step from literally handing the controller over to someone can raise doubts for someone about how they’re supposed to evaluate something!
Clients who have a lower level of experience prefer to hug the edges of the rainbow. For the lowest fidelity materials, it’s easier to navigate the smaller set of decisions presented. For the highest fidelity materials, they don’t have to worry about which things are up for evaluation and which aren’t.
Where everyone can get in trouble is in the center. What if the interface is final art but the text is a rough draft? Or the backgrounds are done but the main character isn’t animated? The client has to have a pretty multi-dimensional view of game development to make safe assumptions about what aspects of the project they should be evaluating at what step.
The more experienced someone is as a designer or developer, the more familiar they are with how someone gets from one side of the rainbow to another. They have an expectation of when different elements would be introduced (e.g. “I assume this animation is placeholder, right?”) and are more flexible with understanding how different aspects of a game are completed in different ways (e.g. the tutorial MECHANICS might be completed well before the tutorial CONTENT is drafted, in order to make the tutorial as representative of the final interfaces as possible).
But that kind of experience takes time. The real burden here is on Filament. How can we present documents that target the specific TYPE of decision we want to have made? How do we make sure everyone is focused on the right scale of feedback, and how do we make sure we minimize distractions in our design materials so everyone can work together to solve the problems we have at that time, and not the problems of the future (or past!).
Brandon Korth wrote a lovely article about wireframes that helps express our in-process philosophy, but in my mind the best practice is for the designers to see themselves as having two communication obligations- one is to present materials to a client to allow them to express their expertise, and the other is to teach the client more about game design and development in order to empower them to make even more powerful decisions in the future. It’s just another way in which communication and creative collaboration are the most vital parts of what it takes to make something playful and impactful!