Sunday, February 8, 2015

2/6/15 Episode 199: Feedback

All podcast content by Mark Rosewater


I’m pulling out of the parking space! We all know what that means! It’s time for another Drive to Work.

I had to take my son to the orthodontist and then to school today, so I’m starting from our school. But as long-time listeners know, our school is right by my house. So you should get a full podcast today.

So I have a fun topic today. I’m going to talk about a very important tool that needs to get used. Feedback. So Malcolm Gladwell wrote a book called Outliers where he talked about, how do you get good at something? You have to do it for 10,000 hours. But most people miss of that thing is, it’s 10,000 hours with constant feedback.

Feedback is very important to the process. So I talk all the time about how what we do is iterative. And what that means is, you do something, you get feedback, often from playtesting and stuff, learn, make changes, and then playtest again.

And that part of the process, part of an iterative process is using feedback as a means to improve what you’re doing. And that feedback doesn’t always have to be playtesting. As we will see today, there are multiple ways to get feedback.

Okay. So what I’ve done today is I’ve broken the feedback into four sections. There’s four kinds of feedback I’m going to talk about. First is self-feedback. How you are giving yourself your feedback. Next is team feedback. How the design team is giving you feedback. Then it is department feedback. How other people in R&D are giving feedback. And finally the audience. How the audience gives feedback. So I’m going to talk a little bit about how feedback can best be used, and how it affects Magic.

Okay. Number one. Self-feedback. So I don’t think a lot of people necessarily realize that you are giving yourself feedback. And that one of the most important things is understanding what the feedback you have from yourself. What do you think about something?

So when you playtest your game, what I recommend is there’s three questions you ask yourself. Question number one. Is it fun? The thing I keep coming back to, I’ve had a whole on this is, at the end, the point of a game, it’s a form of entertainment. If the person playing the game is not enjoying themselves, you are fundamentally failing. It’s not working as a game.

Now, I’m not saying there can’t be lots of other things going on. There can be mental stimulation, there can be all sorts of other things. But it is important that it is fun. And so when you are playtesting, one of the things you have to ask yourself as you’re playing is, is there fun here?

Now note, early on in the playtest process, you are searching for the fun. It’s not that the whole experience might be fun, but you’re trying to find moments of fun. And then as you progress, you’re trying to make sure that you take those moments of fun, and you stretch them out and build your design around the fun parts.

Okay. Number two, is it accomplishing my goal or goals? What I mean by that is, one of the major roles of a lead designer for a game is to make sure that they set the vision for what the game is trying to be. In my case, an expansion, or whatever. I’m trying to set the vision. What are we trying to do? What is the goal of what we’re trying to do?

And one of the things when you playtest is, you have to ask yourself, “Okay, I have a vision, I have a goal, is what I’m delivering meeting that goal? Is my game doing the thing that I say I want to be doing?” Now, note, if the answer is no, there’s two answers. Answer number one is, “Okay, how can I change my game to get the goal I want?” And number two might be, “Oh, is my goal wrong? Do I have the wrong goal?”

And the reason you might come to that one is you might have a blast. The game is hilariously fun, you’re enjoying it, you’re like, “Oh, it’s not doing what I said I wanted it to do, but oh, maybe that what it’s doing is okay, maybe my goal is wrong." That’s something obviously that can happen.

Okay, the third question you have to ask yourself is, “Can I remove anything?” So I talk about this a lot too. A lot of making any creative process is figuring out what is necessary from what is not. I often talked about how when you write, you’re always asking yourself, “Do I need this line? Do I need this scene? Do I need this subplot?”

Game design is similar is, do I need this rule? Do I need this element of the game? And that if you can chop something out and the game works well, chop it out. That nothing should be there that doesn’t serve a purpose. Okay. So one more time, when you’re checking with yourself, ask yourself, “Is it fun?” Ask if it’s accomplishing your goals. Ask if you can remove anything. Those are the three main things you want to do when you are self-evaluating to figure out what is going on from playtesting and looking at your game.

Okay. Now we go a ring out to your team. So in Magic we have design teams. So these are the people working with you directly on making your game. Okay. For each one of these I have three questions. A little structure for you. Okay. So the first question I have is, “What is your team member seeing that you aren’t seeing?” And I mean this in two different ways. One is, there’s a lot going on in a game. Especially like in a Magic expansion. There’s a lot going on.

The reason you have a whole team playtesting is, there’s just more people experiencing things. And A. they’re experiencing things just because they’re… like, you might play blue/red and someone else plays white/black. Well, they’ve seen the white/black cards and you haven’t because you played blue/red.

Also, each person has a different vantage point that they’re coming from. So on our design team, we have a developer. Right? The developer’s looking at, “Is it balanced? Is this stuff that we can later develop?” The creative person’s looking at, “Well does it match our story? Are we conveying the essence of the world?”

A lot of the core designers that are on a design team are sort of like, “Is the design shining? Does it do what it needs to?” That different people are looking at your design in different ways, partly because they have different roles, partly because they’re different people. Different players might enjoy different things.

One of the things you want to make sure when you have a mix for your design team, that the different people have different desires. Partly it’s the role they play, partly it’s just, “Are they different kinds of players?” There’s different things they enjoy about the game. I talk all the time about how Magic on some levels is many games wrapped in one. You have different people that represent the different kinds of players.

So the first question you’re asking basically is, you can’t see everything. Partly because of vantage point, partly because of time, partly because of resources. And that your team is filing out and being an extra set of eyes to see things. So first thing you want to say is, “What are they seeing?” There’s things you’re not seeing that they are seeing. What are they seeing? And one of the roles of having a whole design team is that you are allowed to get a lot of perspectives and just have more people looking at it.

So number two. What is the group consensus? So another issue of having a team is to find out what does the team agree on? Where are people… now, that doesn’t mean, by the way, having the group agree on something, if it disagrees with you, the leader, doesn’t necessarily mean that you need to change things. But it is important. And generally what I find is, any one person can believe whatever they want. But when a group starts believing something, you have to sort of get to the root of what they’re seeing.

Now, once again, that doesn’t always mean that why they’re seeing it or what’s going on is correct at the time. It is okay to go, “Oh, my team sees something, I don’t think that’s the right thing.” But you have to respect, when your team all sees it, it means something. If nothing else, it means maybe the thing you’re trying to do is not where the game is at because people are seeing it differently.

Okay. The third question is, where do they disagree with you? One of the big challenging things about being the lead of a design is it is your job in the end to fundamentally make the decisions. So let me explain this real quickly. I do not believe a good design is a democracy. The role of having a team is not so all of you together can make every decision… I mean, early on, when I used to do Magic design, I used to do more of that. Like, we would want to add cards, and I’d say, “Okay, let’s vote on the cards.” And I would try to get everybody involved so that all the decisions were reached by the group.

And what I found was, A., the group does not have as clear… like, you want the person who has the vision making the final call. That is you, the person leading the team. That doesn’t mean you don’t want input. That doesn’t mean your team’s input isn’t valuable. That doesn’t mean that sometimes your team [isn’t] right and you are wrong. But it does mean that you need to be the one to make sure that everything is lining up with the vision you want.

And so a design team is not a democracy. I believe. I believe that a design team is… they are a team made to help you, the lead designer, capture your vision. And part of your role as being the lead is making sure the vision is clear to all of them so they can help you with it.

But you will have… one of the things as the person leading the set is, since you are the keeper of the vision, you will have a vantage point that is slightly different than the rest of your team. And obviously, if you’re doing a good job as a team member, you’re trying to get your team to see what your vision is. So that you get to a similar vantage point.

But, it is not about everybody sort of coming to a group consensus. You want to know, if there is a consensus, what it is. But that doesn’t mean that the way you need to do the design is to get everybody to agree with you.

Okay. The reason the disagreement’s interesting is, you want to understand where the conflicts within your team lie. Meaning if you’re doing something, and fellow team members think it’s wrong, you want to understand it. So once again, one of the themes of today about feedback is, one of the things that’s most important about feedback is understanding the reasoning and rationale for why the person giving the feedback is feeling that way.

One of the ongoing themes for today will be that people are better at understanding problems than they are at solving problems. And what I mean by that is, when something is wrong, most people can tell you something is wrong. Now, not a lot of people necessarily can fix it, or the solutions they give might not be the ideal solutions. But they are good at recognizing problems. So when someone disagrees with you, understand why they disagree with you.

Now maybe, when you dig down deep, they’ll say, “Oh. Well, I believe Thing X.” And you go, “I, the lead, believe it’s not Thing X. I believe Thing Y. I understand you believe Thing X, but I believe Thing Y.” It’s okay. Like, once you dig deep and understand their reasons, you might, you’ll get to the core of what they believe. And maybe there’s a fundamental disagreement.

But a lot of times, what I’ve found disagreements is, they have an issue with something. And if I dig deep and understand what their issue is, a lot of time, their issue and my issue don’t have to contradict. The reason we might disagree is, I or they might want something, and the solution at hand is not addressing both our issues. But it could.

A lot of times what I find is, you get feedback from your team, they have a problem, and you’re like, “Oh, the thing they care about, I haven’t been thinking about. The thing I care about, I need to address, oh, but there’s a way to address the issue I care about and address their issue.” And a lot of what I find the feedback from teammates are, is trying to get a sense of when something is slightly askew. And once again, this comes from the fact that they have different vantage points. And that is very valuable.

Okay. Let’s get to the next one. The department. Okay. So department, what  I mean is, you’re working in a team that’s actively working on the project. But a department are people that are with you, but are not actively working on it. So R&D in this case.

So one of the things when we do a set, there’s a lot of people that poke in and take a peek. The development team obviously has to take a peek to make sure that things are developable. The creative team needs to take a peek to make sure that we are matching their world and vision. The organized play has to peek in to see if we’re doing anything that’s going to impact how organized play works. Digital might take a peek in. To see if we’re doing anything that’s going to be problematic for them to program. There’s just lots and lots of… sometimes graphic arts will peek in to see if we’re trying to make new frames. And there’s all these different people that are poking in to get a sense of what is going on. And they are going to give you feedback.

Okay. So, first question is, what is their first impression? One of the things that’s very valuable is, you are constantly evolving your game. And one of the things that you lose is, you don’t have the ability after very early on to have any sense of the first impression of your game.

And that’s really important. You want to make sure that when people play, that it creates a positive first impression. Well, how do you monitor that when you’re so ingrained in what you’re doing that you don’t have a fresh set of eyes?

So one of the great things about outside people is, every person who looks at your set for the first time gets to have an opinion, a first impression that you can talk to them about and understand. In fact, one of the things I always do is when new people come to R&D, the first week, they have to get up to speed. Because they’re behind by a couple years since we work ahead.

And the question I always ask a new employee is, “I want your first impressions. What do you think?” Before I ask anything else. Before I taint them with any other question. Because any other question I ask them will kind of taint the purity of their first response. And the first thing I want to know is, “What is your first impression?”

Now note, it’s not important that everything has the most positive first impression. We do make mechanics that at first blush might not seem that good but when you play them are. But overall you want your sets to have good first impressions. A lot of being successful is making people excited about your product. And that while I want the set to play well, I also want the set to have a good first impression.

And what that means is, you have to balance the number of mechanics. That like, you can have some things that don’t look good at first but turn out to be good, but you can’t have a set full of those. If everything in your set doesn’t look good, your audience goes, “Ehh, I don’t want to… ehh, I don't know.” They’re not inclined to want to come play it. And that what you want to do is make sure the set has some exciting things in it.

Okay. The next question is, what are they saying as an expert? So when people are poking their head in from outside, they represent something. They are developer. They are a creative person. They are organized play. Digital. CAPS. Whatever they are, they are looking from the outside, and they are… the one thing that’s very interesting when you get outside is, the person who’s coming from the outside has one distinctive vantage point. And that you as the designer are looking at a lot of different things. And it’s very refreshing to get somebody from outside going, “I just care about this one thing. Or these few things. And I’m going to give you comments on those things. Because that is what I’m focused on.”

And my parallel here is, back in the day I used to direct plays. And one of the things I learned by directing plays is that my actors have  a vantage point on the character that I do not. And the reason is, as the director, I have to care about all the characters. I have to care about the motivation of everybody. But my actor, who has a part, they don’t care about anybody but themselves. Because they’re focused on understanding their character.

So they spend a lot more time than I do focused on that one thing. And so a lot of times, if I want to understand the character, I’ll sit down and talk with my actor to see what vantage point do they have. They might notice things that I would have never noticed because they’re trying to understand the character. And they’re looking at every line in the play as how it affects them. How their character interacts with everybody else. And so they have a unique vantage point.

The same thing is going on here, where Erik Lauer, who’s the head developer, he’s looking at how to develop the set. He’s looking at what he needs to do to be able to make a balanced Limited environment and a balanced Standard environment. He’s looking at what he needs to do to make it a well-developed set.

And so the feedback he’s giving me is not about the design, it’s about the development. Same with the creative team. If the creative team’s talking to me, they’re focused on the story. They want the story to shine. And that they’re looking at it to go, “Is this making the story shine? Does it make sense? Are there things that are incongruous with how the story’s working?”

And so having outside people is very valuable because the insight they are giving you is a very clean and clear insight that is different than insight you are going to have. And once again, you will notice that one of the ongoing themes today is, one of the reasons feedback is so important is, people will give you feedback about things that you do not see or not expert in or not focusing on. And that one of the things that’s really interesting about other people is, they will focus on other things, and they will give you feedback that is a very different style of feedback.

Now, when  you’re talking departmentally, remember, they are the experts. Trust the experts. One of the things… R&D is very talented, we have top-notch people working. So when I am dealing with somebody, what I want to say is, “Okay, you’re the expert. In the area, you’re the expert.”

So for example, one of the things we do in design early on now, and we didn’t always do this, is we go to the rules manager and to the templating team when we have mechanics that we think we want to do. We spend the first early time in design figuring out what we want to do, but at some point we’re like, “Okay, yeah yeah. We’re going to do this mechanic.”

Once we know that, we then have to go to templating and the rules to say, “Okay. How does this work? How is it worded?” We want to get a sense of what this actually looks like on a Magic card. And the thing that’s  important is, I’m not good at templating, I’m not good at rules. I mean, I have a general sense of it. But when I go to them, they’re going to say, “Oh, well if you do this, blah. If you do that…” And they’re going to really spell out things that I might never have thought about.

And that is why feedback is so important is, as the person leading the set, I do need to understand those things. They have a huge impact on what I’m doing. If I want people to enjoy my mechanic, I have to care about how it works in the rules. Is it intuitive? How’s it worded? Do people understand it when they read it? All that stuff’s very important.

Okay. The last question for the department is, what do they see that you don’t? It’s a similar question to what I ask for the team, which is, one of the things that’s very interesting is, when you are working on a project and you’re so close, I talk about “can’t see the forest for the trees.” Sometimes what happens is, when you have people that are less close to it, they can see things that are obvious but you’re blind to.

One of the things that’s very hard is that each person is blind to their own faults to a certain extent. That you can look at other people and you can easily see things they are doing wrong. But when you look at yourself, it’s harder. That you have a vantage point that just makes… when you’re so close to something, sometimes it’s hard to see things. And it takes somebody stepping back and going, “Hey, this is happening.”

And in life that’s a good sense of feedback, by the way, about yourself, which is people will see you and be able to tell things about you that you do not see or understand. And people want to say, “But hey! Who knows me better than me?” And the answer is, there’s many things about yourself that you know, but there’s certain things that because of your closeness to yourself, because of your vantage point, you can’t see. And there’s value in having others to help you see those things. That is very much the same in game design. When you’re so close to your game design it’s easy to not be able to see things.

Okay. The final feedback. The audience. So you make your game. It goes out. And your audience has some feedback. So one of the things that has been my role is… and this is very conscious on my part. One of the reasons I think I am a very good designer is, I have made it my mission to create a conduit where I have an open communication between me and my audience.

For example, I have a blog where I answer questions every day. In the last four years I think I’ve answered 45,000 questions. I have a Twitter where I post to every day and I answer questions on my Twitter. I do Google+. I do Instagram. I mean, I try to be wherever I can be where an audience can have feedback and talk to me. And that feedback is very important.  

Okay. So what do I care for the audience? What are the questions for the audience? Number one. What problems do they see? So… and this is another vantage point, but one of the things is, and I said this before, I will stress it again. People are good at recognizing there’s a problem. They aren’t always as good at solving the problem. Usually what happens is, people can tell something’s wrong. They’ll make a suggestion on how to fix it. Most of the time their suggestion is not the best suggestion how to fix it. Only because if they’re talking about your thing, you have more insight for how it works.

Like one of the things that’s very interesting is, there are a lot of moving pieces in making a design work. The audience doesn’t care about all those moving pieces. All they care about is the end result. Which is fine, that’s what they’re supposed to do. The audience is like, “Am I enjoying this? Is this fun?” They don’t care about a lot of the things that you care about. Not that you shouldn’t care about them, but it’s not their issue. And that what they’re trying to do is they’ll explain why they have a problem.

Now, their solution often won’t work because they don’t know all the issues you have to deal with. So they’ll solve their problem and not realize that it’s causing a different problem. But recognizing what the problem is is important.

Now, one of the things that’s tricky is, Magic is a game that keeps breaking its own rules. Every time you break a rule, you will get people who are uncomfortable. Because people crave structure and rules. I talk about this a lot just how humans behave, human brain, I talk a lot about aesthetics and sort of, the human brain loves structure. It very much wants to understand things and group things, and it wants things to have a pattern to it. Humans also crave comfort, so they want to understand things. When you change things or make them uncomfortable, the first reaction usually is, “What?” They get uncomfortable.

Now, the fun of a game is, it’s in the safe setting where people can accept change. And obviously Magic is a game about change. But note that one of the things you will get,  and every time I do something where I know I’m breaking from something we’ve done before, like one of the things I do in my articles is I lay out the rules. I’ll say, “Here’s our rules.” And then when I break one of the rules, people write to me, like “What are you doing? You broke your rule.”

And I’m like, “Well… we are a game that breaks its own rules. The question is, how and why do we break the rule?” And that one of my themes is, we don’t break rules just to break the rules, we break the rule for a purpose. And that we make sure that the rule-breaking is done in a way that is safe and not hurting the integrity of the game.

But anyway, your audience is very, very good at voicing… I mean, they’re your audience, right? They tell you what they like and don’t like. And once again, this is… Magic is many games to many people. Just because… one of the common feedback I give back for the feedback is, sometimes people have a problem because the thing they’re upset for wasn’t meant for them. And they’re like, “I don’t like this card.”

And you have to understand whether it was meant for them or not. If it was meant for them and they don’t like it, that’s a huge deal. If it was not meant for them and they don’t like it, well, you have to take that with a grain of salt. If you’re trying to make a really fun Timmy card and Spike’s like, “I don’t like it, that’s horrible, I would never play that in at tournament,” you’re like, “Well, that wasn’t for you.”  Some of my answers when I talk with players is understanding when something was for you, and when it’s not for you.

But, and this is important, no matter how… sometimes people give feedback very negatively. Sometimes they can be a bit cruel at times. They can be a bit harsh. Every bit of feedback, if you dig deep, there’s a grain of truth in it. Something about it speaks some truth.

Now, that doesn’t necessarily mean each time that what they’re saying, you necessarily need to change. It doesn’t mean that you’ve made a mistake necessarily. But it does mean you’re doing something that’s causing discomfort. And you want to understand what that is. Why is the audience unhappy?

Now, the audience will ask for things that they don’t get. The audience might want things that okay, it’s great that they want it, either you secretly know that they wouldn’t really like it if they got it, or that it causes problems if you give it to them. Or maybe you’re planning to give it to them but in two years and not now. There’s lots of different reasons why they’re not getting something. And there’s reasons why you’re not giving it to them on purpose. But sometimes it’s just like, “Oh, I didn’t know you wanted that.” Okay, we’ll get to that one in a second.

Okay, number two. What is making them happy? It is just as important to understand what is working as well as what is not working. The audience tends to want to give feedback on what is not working much more than they want to give feedback on what is working.

That said, the audience does give a lot of feedback on what is working. You need to listen carefully. When people have problems, they are very precise in what the problem is. They give you a lot of very specified detail. When people are happy, they tend to give broader feedback. And one of the things that’s important when you have two-way addressability, when you’re communicating with somebody, when they say, “Oh, it’s awesome,” you want to say, “Why? What did you like about it?”

That positive feedback you have to draw out detail a little more. Negative feedback (???) them to give you details, positive feedback often doesn’t. And so one of the things you have to do with positive feedback is spend the time to get the information you need. “Oh, I loved it.” Why did you love it? What about it? What about this is different from other things? What did we do here… So this goes into my third question, which is, “What is missing that you could grant later?” Or the better question actually is, “How could you use the information now to improve what you do later?”

So there’s two parts of it. One is, if something’s missing that you can learn… like, a lot of times you’ll do something. Players want something, you didn’t deliver it, but you’re like, oh, okay. I’m learning something. Why do they want this thing that we didn’t deliver? And is it something we can deliver later? Is it something that will teach us about things in general they want?

When something is missing, one of the things that I always look at feedback is, the point of feedback is the iterative process that I began with. That I want to do something, get feedback, learn from the feedback, ,make changes based  on the feedback, and improve to continue the iterative process. And I think of Magic design as an ongoing iterative process. I put a set out, that’s kind of like the equivalent of having a playtest. I’m doing something, people give me feedback, I iterate on it, I put another thing out. So putting sets out is a lot like having playtests. Just on a broader scale.

And one of the things, for example, I’ve been at this for nineteen years now, one of the reasons I think that I’ve gotten pretty good is that I take that feedback. I listen to the audience, I talk with them, I hear what they have to say, and I make changes.

Now, once again, one of the important things about feedback is figuring out where you think it’s valuable feedback, and where it is not. Not every feedback you address. Sometimes people are asking for things that you think… people will ask for things that in the end, it’s not good to give them. But you want to understand why.

And usually, when I get feedback, like my takeaway from any feedback, whether it’s on any of these levels, myself, my team, my department, my audience, is there’s something they want to tell me? I have to understand what that is. And if at first blush I don’t get it, if someone gives me feedback and I don’t get it, I want to spend more time to understand it.

Like I said. It’s not important that you agree with every piece of feedback, but it’s important that you understand every piece of feedback. Why is the person saying the thing they’re saying? What is the essence of their feedback? And the reason that is so crucial is, the way you get better, the way your game improves, the way you improve as a game designer, is that you take that feedback and you learn from it. You want to get your 10,000 hours in with constant feedback.

Okay. So the other thing that you can learn, not only is what’s missing, but also what was working. Like, one of the big ways that you change things through feedback is you try things. And what you want to figure out is, what are your successes, and what are your failures? It is very easy to focus on your failures and go, “Oh…”

When you make a mistake, it gnaws on you. I talked about this in one of my articles about how mistakes are great teachers. Mistakes are awesome teachers. Success is not as much a teacher. The problem with successes is, successes teach you to replicate what you’ve done. Where mistakes force you to reexamine what you’ve done and try to find differences.

So one of the things I always stress to people is, no matter what the feedback is. Positive or negative. You want to walk away with, “What can I do in the future that will address the feedback I’ve gotten?” And the reason I stress that it’s really important to understand what people are saying when they give you feedback is, you want to be able to turn that into actionable design.

You want to say, okay, I’ve done something, I’ve listened to the audience, I got the feedback from the audience, this is what they’re saying. Okay. Next time I do a design, I’m now going to design differently than I did before, because I have new data to work with.

And I think if I look at, like for example, I’ve been doing design for nineteen years. That I look back at a lot of old sets and I made a lot of mistakes, but in a sense, like, I often think like… Tempest was my very first design. And in some ways, I look at Tempest as kind of being the Model T. It’s this early car that was like, in its day was really impressive. It was this amazing thing. But you look back on the history of time, and like okay, we’ve come a lot farther. There’s a lot of things I did in Tempest, I’m like, “Wow, if I had that to do again, I would do it differently.”

And it’s not that it was wrong. Like, that’s where we were at the time we made it. And Tempest was very advanced for its day. It did a lot of things for the first time that had never been done before. That it was a stepping stone in us getting to where we are now, just as where we are now is a stepping stone to where we’re going to be in the future.

And that that, to me… the value of feedback is understanding that it is a tool in the arsenal of a designer. The arsenal of any creative person, really, but I’m talking game design. That you as a game designer, feedback allows you to help change the design as you’re making it. And helps you change the design for the next time you do it.

Now, I happen to be in a product where we keep putting out things, and so Magic has to constantly sort of innovate what it’s doing. That we get to change and we get to learn and we get to iterate as we go along. And one of the reasons, by the way, I think a lot of people talk about how Magic has really hit its stride. And one of the reasons for that is, we’ve had a lot of time to try things and figure out what works. And we have a very talented group of individuals, and we have a lot of data. We have done a lot of sets and learned a lot from them.

And we keep learning. Like, that’s one of the things that to me is very interesting and why feedback is so important is, there’s no point at which feedback is not valuable, because there’s no point at which you can’t improve the product. I honestly believe that all that happens is, as we learn how to do something better in the game, that we just find other areas that we can improve upon. Magic is a very, very complex game. Not just from the game-playing standpoint, but from the game-building standpoint. From the game-designing standpoint. That there is a lot of pieces moving.

And that one of the things… it’s kind of funny, when I talk about the different stages of design, I feel like one of the things we’ve done over time is we’ve pulled back a lot. That early design was about thinking about how the cards worked. And then we talked about how the cards worked together. Then how mechanics worked. Then how the sets worked. Then how the blocks worked. Then how Standard worked. And larger… you know, that we kept sort of pulling back and figuring out how to do larger and larger things.

And one of the things, as someone who can look in the future is, we are getting more and more ingrained in how we do things. That there are questions I’m asking now as I do design that I never would have asked ten years ago. Fifteen years ago. That I wouldn’t have even had the mind thought to think of… that there are advances to be made, as we improve things we get to move our attention elsewhere, and we get to think in some bigger picture ways, and more inter-set, inter-block. We get to think long-term. And that to me is really cool.

So anyway, I am almost to work. So let me recap my lessons today of feedback. So. Number one, every piece of feedback is valuable, there’s something in it. Make sure you dig deep and understand what that piece of information is from. What they’re saying. What is the core they’re saying.

Number two is, you don’t need… feedback does not… you do not have to act on every piece of feedback. Not every piece of feedback is necessarily actionable. But you want to understand each piece of feedback. And then, once you have gotten feedback, you always need to ask yourself, “How could I use this feedback to improve the quality of what I am doing?”

So hopefully, as we walk away today, you realize that there is little more valuable to a creative person, a game designer than feedback. And that notice that today, I talked about feedback from yourself, feedback from your team, feedback from your department, feedback from your audience. All of that matters. There’s lots of people from lots of vantage points.

And that remember, the reason feedback is so important is, everybody else has a different vantage point of view. They are seeing things that you are not seeing. And that part of being a leader is setting the vision so everybody else understands what you’re seeing, and listen to everybody else, so you understand what they are seeing.

And the goal is to try to see what you are seeing and what they are seeing, and line them up so that you are addressing them correctly. And I think if you do that, I think if you use the feedback as a productive tool to improve what you’re doing, that there is no tool probably more powerful than feedback. And my goal of today is to sort of explain to you how to use it. And how to listen to it.

And, the final point I’ll make today is, the reason I talk about not just the audience but your department and your team and yourself is that the feedback comes at many different layers, and that you need to be conscious of all of it. Especially, by the way, from yourself. I think sometimes it’s very easy to see feedback from external sources. And sometimes easy to dismiss the internal feedback.

And what I’ve found is, in some ways the most important feedback is the feedback you get from yourself. Is understanding when you’re happy and when you’re not happy, and listening internally to your own sort of intuitive sense of whether something is working or not. Because if everybody’s happy but you, that also… something is still wrong. That you want to make sure that everybody is happy, you being part of everybody.

Okay. That was quite a… we had some rain today so you get a little extra time. Hopefully you guys enjoyed this today. I think this is a very important topic and something that really is applicable probably to more than just game design, although I’m talking about game design.


But I have now parked in my parking space, so we all know what that means. It means it’s the end of my Drive to Work. So it’s time for me to stop talking Magic and start making Magic. So I’ll talk to you guys soon.

No comments:

Post a Comment