“How do you two work together?”

This is a question that Carla and I get asked all of the time, and it’s a tough one for us to answer. Our instinct is to say, “We just do!” But we realize that’s not a very helpful response. The problem with quantifying our process is that, in many ways, it has become second nature to us over the last couple of years, so we don’t tend to take time out while we’re developing an idea to stop and think about how we’re going about things.

Then an opportunity to do just that came up, courtesy of none other than iKids at Kidscreen Summit. We were invited by the always nimble-minded David Kleeman to be part of the “App Challenge” panel. We were one of four developers asked to spend a short amount of time brainstorming an app idea based on the idea of parents and children passing a device back and forth. (This is a modification of the pass-back effect, where a parent just hands off a device to the child.) We then presented our ideas and had a little discussion about the concepts.

It was inspiring to see the great ideas from Jason at zincRoe, Andy at Launchpad Toys and Juliet at Plug-in Media. As part of our presentation, I explained the thought process that had led to our final fleshed-out concept. So, thanks to David and iKids, here’s the secret of how Carla and I develop:

1. We talk about the age group.

The challenge was to create a game for 5 to 8 year olds, so we talked about what kids are like at this age: what they understand, what they like to do, and what pertinent developmental milestones we should keep in mind as we developed the idea. This is pretty much the first thing we discuss regardless of what project we’re working on – including if we get to pick the age group – because if we’re not making something the target audience can play and understand, we’re not doing our job. (Carla’s got a lot of expertise in child development, so I basically listen and ask questions for this part of the conversation.)

2. We talk about the feature or design requirements.

In this case, we were supposed to make a pass back and forth game, so we thought about what constitutes a good pass back and forth game – a game where one player’s move depends on the move of the last player. We discussed some analog (as opposed to digital) pass back and forth games, from Scrabble to Exquisite Corpse to the old basketball court standby H.O.R.S.E. We went into the details of how those games are played and what the players’ goals are, how turn taking works, and so on, to make sure whatever idea we came up with would really address the challenge.

This part of the discussion was about the core goal that had been set for us by David, but this is a part of development that can be very different depending on the project. We could just as easily been talking about curriculum that needed to be communicated, or how to incorporate existing characters or other branded IP. Essentially, if the first question is “Who is this for?”, this second piece is “What are we trying to do?”

3. We talk about the device features and affordances.

We had decided in this case to develop for iPhone, so we talked about the various input options available on an iPhone – microphone, gyroscope, touch screen, GPS, etc. – just to make sure we were keeping all of them in mind as we developed game ideas.

4. We hash it out.

So this part is in many ways the hardest to define and we always go back and forth on whether story and character or game mechanic should lead. (I tend to want to know the story first — “Why are we doing this?!” — and Carla tends to want wants to know what the game mechanic’s going to be — “What are we doing!?!” I bet watching us fight about this is amusing.)

Essentially, what we do is a brainstorming process anyone else working in a creative field would recognize. We come up with ideas, sketch them out if necessary, write out the steps involved, even hold up our phones like goofballs and pretend we’re playing the game to see if it seems fun. We ask each other questions about possible pitfalls or holes in the ideas, think about a few different approaches, and settle on what we think is the best one.

In this case, by the end of about an hour long meeting we had a strong sense of where we were headed, and after a few more passes we had our basic idea fleshed out enough to mock up the concept, a sort of digital “I Spy,” (I jokingly called it “I Spy with my Little i(Phone)”). One player picks an object and enters a series of clues into their phone for the other player use to figure out what the object is.

So that, in a nutshell, is how Carla and I come up with a game idea. It doesn’t always happen in exactly this way, or exactly this order, and it’s a process that always involves one of us (or probably both) saying, “Just bear with me while I’ll explain this…” about ten or twelve times as we try incoherently to communicate an idea that’s stuck somewhere in the depths of our brain. But it’s a way of doing things where we truly collaborate and vet our ideas in a way that I can’t imagine doing without a design partner. Or frankly, without Carla. Because the last important point about how we work together is that, although we have different backgrounds and perspectives, we’re basically on the same page about what constitutes good game design for kids. Without having that in common, all of the process in the world wouldn’t get us to a cohesive, compelling design.

Give us a yell anytime at kidsGotGame@noCrusts.com . And if you’re on the road, we’ll be at Game Developers Conference in San Francisco and SxSW in Austin very soon.