Season 1 Highlights
Relive the best moments of season 1Join us for a look back at the highlights and key themes of the first season of Getting2Alpha – the podcast about how creative people bring their idea to life.
[Amy Jo Kim] Welcome! I’m glad you’re here. Today we’re taking a look back, and sharing highlights from our interviews with the amazing and brilliant designers who joined us for Season 1 of the Getting2Alpha podcast.
Today, I’m here with Kenneth Lim – web designer extraordinaire, and my partner in producing these episodes. Welcome Kenneth! Tell us a little bit about yourself.
[Kenneth Lim] Hello Amy Jo and thank you for having me on the show today. And hello to the millions listening around the world. It’s been a pleasure helping out in publishing the podcast and a nice change of pace from what I do most of the time, which is marketing-oriented design work; mainly web design, identity design, publication and presentation design. I’m from Amsterdam, The Netherlands, where I still live today.
As we looked back on these episodes, we noticed that certain key insights about early product design kept appearing across many of the the interviews. So today we’re going to highlight six key themes that emerged from Season 1. Theme #1 is the importance of defining and understanding your early customer.
Looking back, the season opened perfectly with Erin Hoffman, who said that “without the player, there is no game.” I think that the many ways in which it’s important to understand the customer became very evident throughout the season.
Yeah, that really popped out as a common lesson that experienced designers have learned. Here’s Blair Enthington of Crowdstar explaining how she thinks about understanding customer psychology.
When you now start a new project, how do you approach testing an iteration? How do you decide which ideas to pursue, and which ones to filter out?
I think the first step is always really understanding the consumer or the user. You need to understand who are they, what do they want, why do they care, you have to be empathetic with the user. Then, from there, figure out what are the goals that I’m trying to achieve and how do they align with the user goals as well, and always being really grounded in that, and as the features develop, always revisiting what are the goals, what are we trying to achieve and how does that align with the user. As you test and iterate, making sure that your tests are setup so that you can actually learn about your success within hitting those goals.
You’ve had so much experience on different kinds of projects, what are some of the best practices that you’ve learned about how to not dig yourself into a hole, and really make something that your players are going to love?
I think one key thing is not narrowing down your definition of your customer base to one type of customer and being aware that there are lots of different types of customers out there. That can be customers that you have, have different segments and motivations, then there’s other customers that you don’t have yet. Needing to find a way of how do you talk to all those different types of customers and get the feedback of whether your next future product is going to satisfy their needs and help you meet your goals with them. More segmentation of your customers and an awareness that you also need to figure out how to talk to people who aren’t your customers yet, because if you want to grow, you have to appeal to a larger audience.
Closely related idea is Theme #2 – getting early feedback from the right customers. This is a cornerstone concept of our Getting2Alpha system, our programs where we work with clients through the process of collecting and leveraging feedback from exactly the right customers.
It’s a common mistake to think that if YOU and YOUR TEAM really like something, it’ll be appealing to your target customer. Occasionally that works – but in many situations, this becomes a deadly trap that can derail your project and waste months of time.
Here’s Jon Radoff of Disruptor Beam talking about the pitfalls of building games for yourself – as opposed to building games for your customers.
I think it’s really important to expose game development teams to the market as much as you can because the development team themself, while they love it, and certainly you want to hire teams that love the idea, love the kind of game that you’re creating and have sort of a personal affinity for it, it’s rare for them to actually be entirely representative of a mass-market product that needs to be appealing to millions if not tens of millions of people. Making sure that they get exposed to them in some form, whether it’s talking to customers, listening to them, seeing how people actually play the game early, I think, is just important. Super fans can also give you a lot of false positives, too. Super fans can be totally enthusiastic about a feature that may only appeal to 1,000 people in the world. It’s important that you’re getting a lot of points of feedback, not just sort of different pockets of feedback.
Jon brought up a great point about the extent to which the people you gather feedback from are representative of the mass-market customer. He mentioned the development team, “super fans” and end customers, but what about expert opinions? Amy Jo, you get a lot of people asking for your input about their product. What role does that play in the process of gathering customer feedback?
That’s such a great question. As I’ve become more and more experienced as a designer, I have a very different point-of-view about my own input. What I always tell my clients – and I help them actually execute – is to pay more attention to what the right target customers think of your idea than what I think. Yes, I have a lot of experience. Yes, I definitely help my clients shape their design, but even the most brilliant creative game designer needs to gather customer feedback for success. There’s a story Jesse Schell told and that just beautifully illustrates this point.
I remember when we created Pixie Hollow, which was a massively multi-player game for girls based on Tinkerbell, we had a whole design worked out that we felt pretty good about and we said, “Yeah before we get into any production, we should, let’s spend some time talking to girls and see how they feel about it.” We didn’t start by just saying, “Here’s what we’re thinking.” We started out by just asking them really simple questions, questions like, “Do you think you would like to be a fairy?” And we got an enthusiastic, “Yes!” Okay, that’s what you like to hear. “If you were a fairy, what would you do?” We thought we knew what the answers were going to be and we were wrong. The answer was, “Fly.”
We hadn’t been thinking about that because we’d been really focused on the Tinkerbell movie where Tinkerbell does a lot of things. She does some flying, but flying isn’t prominently featured, so we hadn’t been thinking about flying. Flying was really central with the girls we talked to. We started talking to more and more girls and like, “Yeah, wow. They really expect that.” That wasn’t in our plan at all. We immediately changed our plan. We made it so that you’re flying every second of the game. Early conversations can be really important and those can go a long way.
I love hearing that again and that leads us into Theme #3: the importance of early play-testing. It took me a long time to learn this and – now that I know it – I see it everywhere. It’s really emotionally challenging to show your customers your beloved idea in rough form, it’s really hard. Usually you don’t get the feedback you had hoped for, but what you get is accelerated learning. And if you’re testing with the right early customers, this feedback helps you avoid costly mistakes and unproductive cul-de-sacs. It just saves so much time and money. That’s why I – and so many of the people we talked to – have become so passionate about it. Here’s Katherine Isbister – game design professor from NYU and UC Santa Cruz – on the importance of building and testing your idea, not just dreaming and talking about it.
If you look at how often people iterate a system it’s not nearly frequently enough. It’s not nearly along the lines of what typically happens in game development. That’s quite frankly necessary in order to achieve an actually engaging highly interactive experience. That’s one of the big mistakes I see beginners make.
What did they do instead?
They talk about their idea a lot, they spend a lot of time in this verbal idea phase. Then they may linger too long in trying to craft a prototype that gets to where they would like it to be without sharing it with people and getting feedback.
With game design students, sometimes that can mean they really don’t actually have the technical or artistic rather chops they need to get a prototype together that represents their idea. Part of what they need to be doing is finding the right teammates to do that or modulating their ideas so that they can actually craft something.
A lot of beginning designers don’t realize that the idea is worth nothing if you can’t actually build it and test it and take it to the next step. Even if you love some idea it may just be completely out of scale as what you can actually execute on it. It’s not really worth pursuing for too long. It’s not worth wasting the time on.
What’s funny is that you briefly mentioned Eric Zimmerman from NYU in your interview with Katherine and, when Eric was a guest on the podcast, he had some even more pointed remarks about this topic, didn’t he?
Yes, that’s true. Eric has been beating the play-testing drum very loudly for years, and I’ve personally learned a lot from his approach to early, iterative play-testing. I have made those mistakes and learned from them. Let’s take a listen to what Eric has to say.
I have been called a play-testing fundamentalist because I really believe that play-testing as early as you can is the key to game design. We do have some caveats and maybe we can talk about that, but in general, I think the biggest mistake that people don’t do is they don’t rely on an iterative process where they do rapid prototyping and they base their design decisions on their experience of the prototype. There’s often an idea when people are entering into an industry for the first time, whether it’s they want to make fill-ins or write a book or make a video game, that somehow the idea of the game, the concept behind the game is the main thing. Once you have that concept, well then, you know, just executing the game is the matter of crossing your T’s and dotting your I’s, but really, it couldn’t be further from the truth.
I really think that any idea is a valid starting point. The actual design happens once you start building the game and play-testing it, seeing what the prototype is trying to tell you about what’s working and what’s not working in the game. The only time when an idea in and of itself might be sufficient is if you’re doing a complete copy of an existing game, because then you don’t have any uncertainty about the way things are going to play out, but the more innovative, the more you want to mix and match genres, the more you want to try out new ways of telling stories or new forms of player interaction or new kinds of social relationships among new players or communities that you want to form, the more you want to innovate, the more essential it is to play-test and prototype, because you just don’t know in advance what’s going to work and what’s not going to work.
In fact, one of the pleasures of play-testing is seeing all of your brilliant ideas shattered on the rocks of reality, but if you can learn to enjoy that painful process of coming to the truth about your design, through play-testing, then you also can take advantage of it and learn to benefit, for example, from happy accidents that can occur during play-testing or collaborate with your players as they play-test your games and gain from their insight and wisdom into your own design process. I can’t emphasize it enough, but I think one of the big problems with the start is that people overemphasize the idea. Then they just want to iterate on what’s the best idea. Let’s argue in the abstract about whose idea is working. If I have a group of students and they’re arguing about whose idea is better, I say, “Okay, you know what? Everyone go make a prototype. Come back here in 15 minutes and we’ll try them out.”
I actually teach game design off the computer so that everything is a tabletop game or a physical game or a social game so that people can quickly prototype and iterate ideas. I understand it’s harder to do that once you move to a digital medium, and of course we have plenty of video game making classes at NYU as well, but the fundamentals courses are all off the computer, but I would say that, to me, that idea that you just want to play-test early and often is very essential to my approach.
Eric and Katherine are both professors of Game Design – and it’s great that we have people like them, as well as people like Tracy Fullerton and Jesse Schell, to help familiarize young game designers with practices, like early play-testing, because it’s really something that continues to be important throughout a game design career, isn’t it?
A good example of that is Erin Hoffman. She was our very first interview in the series. She’s a working designer. She’s now at GlassLabs, but she’s been at Zynga, she runs her own company, she’s a very experienced game designer. And she expands on these ideas beautifully and articulates both the challenges and the power of this approach.
What I often see, especially from younger designers, basically as a young designer, if you’re creating the game design document that is longer than five pages you’re probably already on the wrong track. That’s what I would say to people who are just starting out, is don’t do too much forward thinking or forward development, even if you’re working in software, to get too attached to the assets that you’re putting in the game before you’re seeing the basic interactions of how players are relating to your game. You have to get it in front of players as soon as you absolutely can. You have to know that it’s going to be terrifying and horrible, and then you have to know how to look at their interactions with this very nascent piece of software and understand where the promising interactions are and what needs to be changed about it.
And then there’s Jesse Schell, who is both an educator and a professional game designer. Here, Jesse shares his experiences with getting feedback on rough prototypes – and his words echo and reinforce what we’ve been hearing from all these other great designers about the power of early, rough prototypes.
One of the rules that we know is if my game’s really ugly and it’s still fun, I’m in really good shape. It’s okay to test things that don’t look very good but have the right play mechanics. One of the advantages, you actually have a lot of benefits when you work with kids because kids have a good imagination and adults have a bad one. You can ask kids to imagine that things were different than they are. Adults have a harder time doing that.
The other good things is if you bring people really rough prototypes that are unfinished, they’re more likely to give you honest feedback. If you give somebody something really polished, they’re less likely to tell you the truth about how they feel about it because they feel like it’s already done and so that their feedback’s not going to matter. If you bring a thing that’s all kind of “janky” and broken and a lot of rough edges, they’ll tell you the truth about what they like and don’t like about it.
Now let’s turn our attention to Theme #4: the power of story and narrative.
This was brought up multiple times as an organizing principle of game design.
That’s right – and to sum that up, I really like this section of our interview with Jon Radoff where he describes the importance of narrative for making the experience both accessible and relatable.
I’d say that almost any game has some kind of narrative to it. Now, narrative doesn’t necessarily mean that you’re telling a story with dialogue and a plot. Like, you can still have a fiction around a game so that it’s accessible to the player and they understand what’s going on. Otherwise, games become nothing more than sort of mathematical abstractions. It’s important to be able to structure a game in a way that people can comprehend. Chess is a good example. Chess, there’s a way we could play chess in which the figures don’t really mean anything other than a particular set of rules about how they move around the board. We could call it pieces A, B, C, D, E, but that doesn’t make it as easy to understand, and it’s not as easy to approach if we do that.
Yeah, I want to be careful when I talk about narrative. Narrative doesn’t just mean coming up with a plot. I don’t know what the plot of Candy Crush is, for example. I think there might be a plot, but there’s still a narrative, and there’s still characters, and they’re sort of ways to take the match 3 concept and wrap it within familiar objects that make it accessible to me.
That’s fascinating. Let’s drill down on that. Talk to us more about the narrative in chess because I think what you’re talking about are things like character and setting that can almost create the foundation for a narrative without creating narrative. Talk to us about what your thoughts are about that, how you think about narrative that’s not obvious, and what are the elements that can set up like minimum viable narrative?
Well, I guess I think back to how I approached chess when I was a child learning about chess for the first time. If chess had just been a bunch of rules on a checkerboard about how certain pieces moved around, it probably wouldn’t have been as interesting to me, but the fact that it was sort of wrapped within this fiction of a royal court and there was a conflict going on, actually brought the game to life in a way that wouldn’t have happened without that. That said, there’s games like Go that are essentially that abstract, and there’s a huge number of people who love a game like that, but I didn’t pick up Go. Whatever it was about Go didn’t work on me when I was a kid, whereas chess did. I think the story aspect of it, even though it’s the most tenuous of stories, is part of what made it appealing to me and I think makes it appealing to a lot of other people.
You don’t need character and plot and setting and themes and all these things that people talk about in fiction writing. You can have aspects of it. Sometimes it’s world-building. Sometimes it’s just a matter of humanizing aspects of the interface or the objects that you interact with, but it’s about making it more familiar.
This line of thinking leads naturally to our next theme – Theme #5, the importance of taking a player-centric view of your game or product as you’re designing the experience.
Absolutely, and Chelsea Howe from Electronic Arts shared more details on that and had a really interesting and surprising point-of-view about how to please players by actually withholding pleasure.
I’m working on kind of a critique of free-to-play under the guise of kind of aggressive versus submissive tendencies and how free-to-play really puts us in this place of… I guess traditional free-to-play where you have energy mechanics. Essentially, it makes the game in a position to withhold pleasure from you unless you comply to the game’s desired behavioral patterns. It’ll say, “Okay, you’re done, no more pleasure for you. Come back in two hours.”
It’s about pleasure withholding and it’s about behavioral compliance and it’s about obedience. Fundamentally, a lot of designers approach free-to-play by figuring out how to get players to be obedient to their… What they perceive is an optimal behavior pattern, which is super interesting.
A lot of people approach game design in the free-to-play space with the product in business’ best interest in mind, above the player’s best interests. I think it’s that… That fundamentally, whether you prioritize your business above the player or the player above your business, is what really makes the difference.
I think most people who are actually making games that do have positive impact, see that prioritizing the player fundamentally will lead to successful business. That just affects all of these little, tiny choices that add up to make the difference between the game that feels great and a game that feels manipulative.
I love that and it applies even more so to learning games, where the objective is to teach the players something new, and keep them engaged. Product designers and educators a lot to learn from game design in this area – and Erin Hoffman is at the forefront of the movement to make learning more fun, engaging and player-centric.
What I want is for game designers and people who have a game design inclination to start thinking about how the systems that they make in software are responding to the humanity of the player that they encounter. I think that they inevitably do, it’s just that we don’t really become metacognitive about this and think about what it means, but in learning it means that a game can stay one step ahead of a player and pull something out that’s responding to feedback that they’ve put into the system and say, “Hey, you’ve been doing this series of actions. What about this action that might be just outside of your comfort zone, but might lead you to make a leap forward.” I think that game designers have a tremendous amount of potential that is untapped to really change learning.
That was wonderful and another thing I enjoyed when listening to the episodes was how deeply passionate the guests were about their work. It has to be a big challenge for game designers to keep that passion alive – while also ruthlessly testing and iterating their ideas with early customers.
Absolutely, that’s one of the toughest – and also most important – parts of the job if you want to be successful. This leads us to Theme #6: being emotionally dispassionate as a creator, and resisting the urge to fall in love with your own designs. How do successful designers walk that line? Here’s Eric Zimmerman’s take.
I think that there’s kind of specific tips and tricks, but I think that the most important thing to get play-testing right is an attitude. It’s an attitude towards the idea of play-testing. What I mean is that I feel that design makes us better people because, for example, to design something you have to put yourself in the shoes, in the place of another person and think about how is someone who’s never seen this game before going to learn how to use the controls and interface. How are they going to adjust to the difficulty curb that I’m designing, et cetera.
Design is an intrinsically humanizing discipline on many levels, and I think in play-testing as well. I feel that when you play-test what you’re doing is giving yourself an opportunity to expand your ego and your sense of self beyond just yourself, that you can expand your sense of authorship to include your play-testers, and that, for example, this whole idea of valuing the brilliant genius idea over everything, I think it’s more important to value the process at which you’re making something. There’s a lot of ego in this idea of I have a brilliant idea and there’s a creative director on a team and the team is just there to implement the genius visionary’s idea, and I think that’s the opposite way that’s worked for me in the past of how games are developed, that games are a team effort, that anybody can contribute ideas, but even more significantly, that a game is about a collaboration between you and your audience that you find and use as you begin play-testing your game and moving forward.
Tracy Fullerton – who runs the world-renowned game design program at the USC Film School – has some great things to say about this and she has lots of experience with this struggle. I think her advice is GOLDEN for all aspiring entrepreneurs.
Once *you* love something, that is not the time to stop listening to the users, the players, the testers. Unfortunately, a lot of times, we fall in love with our own designs. We might not fall in love with the first one, but maybe by the fifth or the sixth, we’re starting to fall in love with it. Then we stop seeing the body language, the facial expressions when people are testing. We explain those away. The most successful designers that I’ve seen are the ones that continue to … It’s not that they’re not in love with their … because they really love what they’re doing … but they continue to be open to the problems and keep hacking away at those problems and keep perfecting, keep making their solutions more elegant.
There’s an advertisement for this new movie, Whiplash. They’re playing the drums. It’s about, I don’t exactly know, but it’s definitely about creative drive. At the end, somebody says the enemy of greatness is … The two words that are the enemy of greatness, it’s “good job.” That just really hit me because I say that all the time, just by the way. I say that to my students all the time, but maybe I’ll stop because the designers that I see that really have done great things are the ones that never tell themselves they’ve done a good job. They ask themselves, “Okay, that’s good. That’s good. What’s next?”
That entire point about “What’s next?” really reminds me of something Dan Cook mentioned as well in his interview, which was the Stage Gate model. He uses that to weed out the bad ideas from the good ones. I hadn’t heard of the Stage Gate model, so that was really enlightening.
Me too – I first learned about Stage Gate model from Dan, and I really love his approach to “killing your babies” and the importance of having more than one idea in development.
Can you kill things early? I talked about momentum on a project earlier, and one of the things that happens is you get emotionally invested in a project and it’s the only project you have, and you can’t imagine your life without it. So even when all these negative signs are building up, you really don’t have anything else to compare it to and you don’t want to get rid of it. You’ll find tons of excuses to not kill the project. So some of the things that have helped me deal with that is having more rigorous understanding of what a good project is and a bad project is. Then the other piece is leaning towards killing things earlier rather than not. Then the last bit would be having alternatives. Always having two or three alternatives in my head at once so that even if I kill something, I know that I can jump onto another experiment which is also promising. That’s helped me deal with the very expensive mistake in developing a bad experiment for too long.