Hey, game devs! How do these phrases strike you?

"I just couldn't grok that part.""The playtest is next Wednesday.""The rigging on that part's really messed up.""The FTUE is really coming along nicely.""That level is totally unbalanced right now."

How about these?

"We need to set up a way to measure the proximal outcomes.""I’m really concerned about what kind of far transfer this experience will have.""We’re wondering about the overall journey map of this experience."

Chances are, if you’re involved in game development, there was at least one phrase in the first set you were familiar with. That second set? Maybe not so much, depending on your field. These are actual quotes from actual teammates whose field of expertise is something other than making games. Those examples alone are taken from the past three months of collaboration on a health app with experts in Smoking Cessation and Weight Management. If you felt lost and confused, join the club: we were all speaking English, but none of us spoke the same language!

Not all games are made by a traditional game design team. A lot of games need experts outside of our wheelhouse: scientists, UX designers, parents, children, educators, researchers, professors…depending on your experience, it could be anything. If you’re not careful, all of those experts, including you, can get into a room, think they have a productive conversation… and then leave with totally different ideas of what is about to get made.

Enter codesign. Codesign is a field meant to help cross-discipline teams collaborate effectively and quickly. Codesign is a concept taken from UX research and design, and also the more-generalized field of “Design Thinking.” One major tenant of codesign is that meetings are artifact-based: together, always be making something concrete. For an overview of the idea of Design Thinking, I recommend Stanford’s D.School website!

I’ve run codesign sessions before, but running three to five sessions a week for three months in a game-specific context was all new to me. Over the course of the past three months, I learned a lot about what to do and not to do. I want to share some of those takeaways.

WHAT I LEARNED TO DO:

1. Keep a standard lesson plan format so that you don’t go crazy every time you need to plan one.

When you’re running regular meetings in which you have to prep supplies, materials, and activities, you run into a common problem for beginner K12 teachers. Picture this: you’ve planned five separate lessons for the day (reading, math, social studies, science, and an essay project). You show up and realize that you’ve forgotten at least four supplies across the five subjects and the lesson plan for the fifth. That’s a recipe for a ruined day. How are you supposed to run the lessons as well as account for the supplies and gauge how everyone is doing?

Having to prepare so many fully-facilitated experiences and then showing up prepared can be a tremendous cognitive load. Especially since you’ll need the extra brain space to get creative during both planning and also during the facilitation. Try to keep a standard format for writing up what you’re doing and what you need and use it to track prep as well as look back on later for time estimates and activity ideas. Otherwise, it will feel like you’re reinventing the wheel every time.

2. Look to Design Thinking and codesign methods for activity-based, generative-focused meetings. Luma Institute’s guide for action-based activities is a good introduction.

Often, you’ll have a goal in a meeting–”we need to prioritize these features,” “we need to see what everyone has in their heads about what this idea could look like,” “we need to generate as many ideas as possible,” “we need to narrow down to one idea,” “we need to understand what our goal is here”–but you won’t know how to get there. Starting to develop a sense of what activities exist out there for what goals was something I was grateful for doing, because they served as recipes that I could adjust as necessary rather than having to invent activities all the time.

3. Use the Transformational Framework topics. Write down your answers, then have your experts edit them.

I found that writing down my assumptions and then having the subject matter experts correct me where I was wrong with the workbook pages in front of them was a fast way to get something down early. For example, I discovered my assumption of the audience as 20-to-30 something gamers was completely incorrect. I also discovered that the way I was prioritizing our goals was totally wrong. But if I hadn’t tried to write them down, I wouldn’t have known.

4. Try to take risks by getting things in writing or concrete artifacts as much as possible, even if you think your take is wrong.

Most people can’t articulate on a blank page, but can totally tell you where you messed up. A blank whiteboard can feel intimidating to non-designers. It can feel scary for your ego, but take one for the team. Type up the doc. Write an example of what you want to walk out of the meeting or the week with–if it’s a 6-page design doc, write a dummy doc with lorem ipsum in some places and show it to the team at the start of the week. Draw a picture of what you think the flow of the app will be and have others correct it. Bring materials for people to change it. Call out that it’s a draft, make it look sketchy and piecemeal so that people don’t feel bad marking it up or correcting it.

5. Use research papers in your transformation subject area to start developing a shared language between disciplines.

You’ll want to be able to have some shared vocabulary when making things together. A team I worked with published a paper about how to do this last year. The paper is about how to get a team of experts in different fields “speaking the same language” through a mix of reading the same papers, making things together using writing and simple paper supplies, and talking about what’s working using those prototypes.

6. Love & trust your teammates to be experts

Across disciplines, there can be a lot of mistrust that comes from not understanding their work. Here is an excellent GDC talk that includes our CPO Chuck Hoover that discusses tips for how to do this effectively. See: Production is Working at the Heart of the Team

7. Teach them about game techniques using a “video lit review”

If you’ve played a lot of games, it’s easier to “picture” an idea and how it will work in its final form. Something that you imagine with glitter, sparkles, pizzaz, and a universe of context might come across as flat or insane to an expert colleague who has never played Mario Kart. When you’re talking about game design terms, it can help to do a 3 minute video of examples of that mechanic in practice in other places–that way, your team has seen examples before and can now talk about them, too. Encourage your other experts to do the same with their field. Maybe they have a talk or PowerPoint they always share, or a paper they wrote that sums up their expertise or what they want for the game.

8. When you’re behind, be brutally honest but don’t place blame.

Teams learning to design together move slowly at the start. It can be tempting to lay blame on people arriving late to meetings or those who don’t seem as checked in, or whatever seems to be happening from your frame of reference. Instead, I took a step back and just conveyed the facts: I had everyone collaboratively estimate how many hours of work remained and cross-reference it with the number of hours we had left together. Then, I asked: what can we do about the discrepancy? And we brainstormed ideas to try. I learned two things. One, there was a ton happening that had nothing to do with my frame of reference of the problem. Two, we picked three solutions to try as a team, and people were far more committed to trying them because nobody felt blamed. We made up the difference and hit the original deadline.

WHAT I LEARNED TO DON’T DO

1. Don’t put off making a visual roadmap of where you’re going and WHY you’re doing these sessions–people don’t read the written outline as “big picture.”

I’ve used everything from a post-it wall to sketches to Photoshop to google slides to make this. The format or structure matters less than the fact that it exists and that people understand it. Here are some examples, but generally all you need are dates, what you’re making on that date, and what you’re trying to accomplish/have at the end. I have a hunch that making it in front of everyone and then updating it/moving the “you are here” marker every meeting in a visible place is probably a good idea.

Courtesy of majorindependence.com

Courtesy of template.net

This was a major mistake I made: I got so deep into planning and prepping that I really never shared the big, long-term “why’s” with my clients, and they didn’t have a sense of progress as a result. I thought sharing a dummy outline of what we’d have at the end would be enough, and it just wasn’t. Every meeting, take two minutes to describe where you’ve been, what you’re doing that day, and how it fits into the larger plan.

2. Don’t forget to schedule/budget time for open-ended question/discussion breaks at the end of meetings.

Or people will leave confused and feeling like they don’t have enough wiggle room to discuss what matters to them. This process is unfamiliar and often people need to feel heard at the start and end of meetings in order to feel comfortable trying something new.

3. Don’t forget to frame design as messy, generative, uncertain, full of bad ideas, and not about sitting on it until you get the “right” answer (Stanford’s Design resources do a good job of this).

Again, so many disciplines are not steeped in the exact kind of uncertainty that design is, and many clients come from a work culture where you sit on an idea until it feels polished. This is very bad for the creative process because you don’t fully explore the possibilities! But on the other hand, people naturally have a fear of appearing stupid in meetings if they feel like they’re not coming up with “good” ideas or thinking on their feet well. Frame design as messy and be open about your own less-than-polished ideas. I totally forgot to frame the process as rough and changeable, and I had a lot of stressed-out clients for the first two meetings as I continuously pushed them to produce outside of their comfort zone. All I needed was to message that I, too, get heartbroken when we throw away stuff after pre-production, and so does everyone else! But it’s a necessary mess. Lean into it.

4. Don’t forget to “test” meeting activities with your internal team when you haven’t run something similar before.

We playtest games for all of the reasons it’s a good idea to playtest making activities.

5. Don’t forget to give people choices about how to contribute –and if they have a suggestion for changing an activity, try to roll with it, at least sometimes.

I was good about this at the beginning, but when we got new teammates it was easy to forget to check in with them and allow them choice. People will be more creative if they feel like you aren’t steamrolling them with a plan.

6. Don’t participate in all of the generative activities unless the content touches on your expertise.

One, because the cognitive load of facilitating means you probably won’t be very creative. Two, you may not have the know-how to generate good concepts until you learn more about the subject matter. Consider coming prepared with a couple examples at the beginning of each activity, or participating for the first minute or two, to level-set what the concepts or artifacts should look like.

Happy codesigning!

Elaine