3/13/15 Episode 209: Iteration

All podcast content by Mark Rosewater

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

Okay. So today, I’m going to talk about an important concept of design. Iteration. So creative, creative things are what they call an iterative process. So I’m going to talk today about what exactly that means, and then how to make your design better through using iteration properly.

Okay. So what iteration is, is the idea that every act of creation is lots of small acts of creation that you go through a process of improving things. So here’s how iteration works, and this is true of almost any creative endeavor, is you start and you do something, and then you sort of learn from that, and then you do a little more. And that you keep sort of advancing the thing you’re doing, improving it along the way.

That it’s not like, you sit down to write a book, and the first draft is the book. No, you write a draft. And then you go through and you rewrite the draft. And you rewrite. And you rewrite. Or if you’re an artist, you don’t start just by painting the painting, you first figure it out and you sketch it, and you spend time and energy slowly figuring out. And with each iteration you get better.

Now, it depends on the medium how much iteration there is. In game design, especially in Magic design, there’s a lot of iteration. So what that means is, and I’ve talked about this before on my podcast, but today I’ll go a little more in depth.

So essentially the way it works is, in design you come up with cards. I mean, you come up with ideas. You then have to come up with cards to represent the ideas. Meaning that one of the things—people often ask about the difference between exploratory design and design.

In exploratory design, our job is to figure out sort of the questions at hand. What is the design team going to have to solve? What are the questions to solve? And so the only reason that we make cards in exploratory design is to test out theories of what we’re doing. To see if new mechanics show any promise.

In design, you have to build a file. That the act of design is built around creating file. Now understand that the file of cards you make is not really what you’re making. What you’re making is a strong concept and environment that you are passing along to development to understand what you’re doing.

Now, you’re trying to make as many cards as possible to execute on that, and a lot of what you’re trying to do through design is create a card set that embodies the things that you want. But more important necessarily than every correct choice is getting the essence of what you’re trying to do.

But anyway, you are trying—the way design works is, design is broken into three parts. We call it the vision phase, the integration phase, and the refinement phase. And each section does different things. And when you iterate, you are doing different things during the course of each of those three sections. So I’m going to walk you through the iteration process as it applies to each of the three phases of Magic design.

Okay. So the vision phase. The vision phase is you trying to figure out what your set’s about. What is going on, what do we care about? And it’s during the first phase that you have to figure out—you tend to figure out your mechanics, you figure out the major themes.

Now, exploratory design walking into this did a lot to sort of—usually when we start design nowadays, because of exploratory design, we have a leg up on exactly what our theme is, and we have a good sense of mechanics maybe we might be interested in. Because what exploratory design does is makes a smattering of different mechanics for design to consider.

We changed a little bit of how exploratory design works. What we do now is, we go shallow on a lot of things rather than going very deep on a few things. Because the idea is, let’s create a palette of paints for design to paint with, and let them figure out what one’s the most useful, rather than going, “I think you’re using red. Here. We’ve mapped out red for you.”

So what happens when you start design is, you have a lot of the exploratory design team, of which I’m always part of, has done a lot of work mapping out kind of the essence of what you’re trying to do. So for example, when we started Khans of Tarkir, the block that’s currently out.

When we started Khans of Tarkir, we knew that we were telling a time travel story. We had started with the idea of a block structure that we wanted to have you—large/small/large, and drafting the middle set with both sets. And from that, we had come up with the idea of a time travel story. That that was the model that matched what we need to do to have the cards function correctly in a way that made sense.

And then, once we knew we were doing a time travel story, we went to the creative team, and they helped shape what the world was going to be. And that helped illuminate us on the story. And from there, we understood—so let me walk you through, I’m jumping ahead here.

So early on in design, we knew “time travel story,” and we knew—we had gone to the creative team and they gave us warlord world which transforms into another world, and if you know the name of the third set you can probably figure it out.

So we were going from warlords to dragons. I guess I’m not giving anything away because it is called Dragons of Tarkir. And so the idea is that we wanted to transition. And so what that meant was, design early on had to figure out how to communicate a lack of dragons in a way that made dragons have a presence without dragons being there. That led us down the path to the clans, obviously.

So what happens early on in design is, we say, okay. We have this idea, and so we start designing to it. So pretty early on we had the idea of clans. For those that don’t know the history of the set, we started with four and it quickly got to five.

But the idea was, okay. Once we understood some sort of structure, we then had to make design to fit that. So for example, whenever you do a faction design, what that means is, you want to have equal—whatever number of factions you have, you want an equal number of cards roughly in each faction.

So you want to sort of get a feeling of—because part of factions is having choices, and feeling like there’s an equal representation of each of the factions. Imagine if we had done Ravnica, but Dimir had twice as many cards as everybody else. That would feel off.

So in the vision phase, you’re trying to get a sense of what you’re trying to do. So during our vision phase of Khans of Tarkir, we said, okay, I got it. We’re doing a clan set. Originally we didn’t even know wedge yet, because when we started there was four. We would get there eventually. But early on I’m like, “Okay, we’re doing the clans, that’s a faction thing. What does that mean?”

Well, a faction means there’s equal numbers. Originally we were doing four. So when we started design there were four factions, so, okay. That means we’re going to divvy up the set so there’s four equal factions. And what we learned, and Ravnica really hammered this home, although we’ve learned this in other places as well, is if you’re about faction play, you really need to give one mechanic to each faction if you want to communicate what that is. That if you’re trying to use your mechanics to really hammer home factions, one of your important natures of it is to make sure that you divvy up your mechanics between the factions.

Now remember, we also had done some work with exploratory design team with the idea of, we were doing a time travel set, so we needed to have something demonstrate the present, the past, and the alternate present. And so we wanted to have a mechanic capable of doing that. And so morph was the mechanic we wanted to do that with. Obviously you guys haven’t seen Dragons of Tarkir yet, but morph was going to show up, then manifest was going to show up, and then something else.

And so we had a mechanic to sort of mirror what was going on with the time travel. So we had a morph component, we had factions, we wanted to make sure each faction—so the trick was, we wanted to make sure each faction both—because this was a three—at the time, before we got to the wedge part, it was some were two color and some were three color. And eventually, pretty soon, still during the vision phase, we got to five. Let me just jump there because it makes it a little easier to explain this.

So when we had five factions and we had a wedge, what that said to us was, “Okay. Each of the factions has three colors.” So what that means is, there’s a lot of overlap. When you are playing with a single faction, you will have access to all five mechanics. Because every mechanic’s in three colors, and any one faction plays three colors, that means you have the potential in any faction to have all the mechanics. So that meant not only did we have to have five mechanics that represented each of the clans, but the mechanics had to have synergy with one another because you were going to play them together.

Okay. So during the vision phase, it’s like, “Okay. We are trying to understand the different qualities of what’s going on.” Now, usually in vision, one of the things about the iterative process is you start small and you build your way up. So the first playtest you have, which is usually an all-common playtest, what you are looking for is not big picture things, but actually individual card things. What you’re looking for when you first start playing in an iterative process is the small things.

So very first playtest, all commons. It’s not (???) do the commons all play together well yet. You’re not even to that point yet. What you’re trying to do originally is to say, okay. We want to test the grounds.  We want to figure out, are there individual fun things? Are there fun cards? Are there things that you play and go, “Ooh, this is fun, I enjoy this?”

And the answer is, if you can find a few fun cards, you can turn a few fun cards into a lot of fun cards. Really what you’re doing is you’re sampling your themes in early playtest. And you’re trying to figure out what you have that works.

Now, early on, in Khans for example, we did know we were doing some sort of faction play. So early on we were trying to figure out how to make the clans feel different. And we had attributes. When we first figured out the clans, we figured out really quickly that in order to feel as if they were part of the dragon world, that the clans would each admire the dragons and have some attribute of the dragons they would care about.

And so early on we were looking for mechanics, and we knew the essence of—so remember, early on, the attributes we did, we modeled after… D&D has attributes, for those that know, so D&D has six attributes. Let’s see if I remember this correctly. It’s strength, dexterity, intelligence, wisdom, charisma, and constitution.

And so originally when we had four, we had chosen strength, dexterity—I thnk we called it speed at the time, dexterity’s speed. We had constitution, and we had intelligence. So the idea was, there was a smart clan there was a fast clan, there was a strong clan, and there was a tough clan. And then when the fifth one got added in, we called it charisma. The fifth clan was the clan that wanted to win without actually having to fight. And so whatever they needed to do to win that didn’t require them actually having to fight. And that ended up becoming Sultai, obviously. And we changed words later on to sort of match the dragons a little more, we got to “ruthless” and “savage” and stuff like that.

But anyway, early on we’re of, okay. This clan wins through being the biggest, the strongest. This clan wins through being the fastest. And so we had attributes that we’re trying to mirror, we’re trying to get mechanics. But early on in playtesting, you are at the card level. You are just looking at the cards. And what happens is, when you play in your earliest playtest, you’re saying, “Is this card good, is this card bad?”

And what you intend to do in the iterative process is cards fall into a couple categories. Category number one, which is, “This is awesome, make more cards like this.” And that is an important one. You want—having a lot of those means you have a great playtest.

Number two is—I’m not putting these in sequential order, I’m putting them in the order to talk about them. Number two is, “This is bad, get rid of it.” Those are also important in a playtest. The first two are very illuminating. “Yes, this is awesome, use this, make more of this,” “No, this is horrible, get rid of it.” And usually “this is horrible, get rid of it,” is like, not only is this card bad, but often it’s representative of a larger theme that’s bad. Sometimes it’s just the card, just this card isn’t fun.

But the first category is to look at, I open up my avenues where to look, second one explains to me what isn’t working so I know what to get rid of. And by the way. You want to have cards that aren’t working. That’s actually a valuable lesson, that one of the things about the set is, you go very wide when you first start iterating. That when you first start making cards, you don’t narrow in yet. Just you try a lot of things.

And so, one of the things I say if you’re a beginner is that usually in an iterative process, you want to introduce a few things at once, so you can sort of figure out what’s going on. Very, very, very early in the iterative process it’s okay to have a bunch of different things just to sample and see what you like. But pretty quickly, you’ve got to figure out what you like and what you don’t like.

Okay. So category one is, you like it, make more of it. Category two is, you hate it, get rid of it. Category three is, it shows potential, but it’s not there yet. What that means is, well, this wasn’t really fun, but I think there’s something there. I think with tweaking maybe this could be fun.

This category is tough. Because when something isn’t working, your first go is, “Ahh, this isn’t working.” You have to recognize what isn’t working and won’t work from what isn’t working but might work. And I think this category is where experience comes into play. It is very easy to go, “This is working, I should make more of it,” “This is not working, I should make less of it.” Those are relatively easy. I mean, it’s all hard in the big picture. But comparatively they’re much easier. Knowing that something isn’t working but could work requires a deft touch.

The other thing, the final one, which is tricky, is it is working, but something about it isn’t right. And that’s the hardest one because when it is working, you’re like, “Oh, this is working.” And to know that something is working but something about it, even though it is working, is problematic, is the toughest of all to recognize. I mean, it’s very, very tricky to recognize.

So what happens is, you playtest, you figure out what is working and what’s not working. Then you take things that—let’s go through each of the categories. Number one. Things that are successful. Make more cards like it. Figure out why. Talk in your group. Talk in your design team, why does this work? Why is this kicking ass? Why is this card good? And figure out, can I extrapolate from that? Is there other cards that we can do that will help do that?

Okay. Next, this card is bad. Get rid of them. And like I said, if something really isn’t working, and we’ll get to those (???) categories, if it really isn’t working, it is not doing any service to keep it around. Part of the iterative process is to find things that are working and make more of it, find things that aren’t working and make less of it.

And the iterative process is a cutthroat one. You have to really be as critical as you can. And remember that every idea has to serve the greater good. That no idea in a vacuum, you can’t judge ideas in a vacuum. Well, I’m getting ahead of myself. When you’re doing early iteration, just is it working, is it not working? Get rid of stuff that isn’t working.

If it’s not working but you think there’s potential, change it. What about this card do you think could work? It’s not working now, how could I change it? If it is working, but there’s something about it, likewise, you have to figure out what is there. And remove something. Normally if something is working and something’s not, take something away and leave—like, let’s say the card has a couple components to it. Well, take one component away.

That’s a good trick to learning whether that’s the component that’s causing problems. Right? Is that—let’s say a card has three components to it. And something’s working, something’s not working. Well, take a component away. If it doesn’t work as well, that was one of the ones that’s helping. If it still works just as fine, maybe that’s one of the ones that’s problematic. A lot of early iteration is trial and error. Is trying and getting a sense of things. Because like I said. The first few playtests is just about getting the general sense of what cards are working.

Okay. Then, the next part, and this still happens during vision, is as you start to find things that are working, you then start looking for two-card interactions. Do I have moments in where, wow. This card and this card are doing neat things. That’s where you’re starting to look for synergy.

Okay. Now, this is all still during vision. You’re trying to find your initial synergies. And the way you do that is, just looking for interesting two-card interactions. And then saying to yourself, “Wow, why do these two cards interact well?” And looking at themes. Because sometimes the theme is going, oh… these cards are working well, (???) individual cards and go, “Oh, no no no, they’re playing into a theme, this does Thing A and this does Thing B, ooh, there’s a synergy between Theme A and Theme B.”

And one of the things you are looking for in your early design is to start finding basic synergies. Because you want to make sure as you’re picking your mechanics that you’re making them work together. So for example, a good example of that is in Khans, we wanted to make sure that the mechanics we picked had synergy with what was around it.

Now, we knew we were doing morph, the new mechanic had to play nicely with morph. Now, morph is pretty easy. Most mechanics, surprise, I have this creature, it has a mechanic. You can combine morph with mechanics pretty easily. Easier than most mechanics to combine with.

But anyway, we were trying to get the general sense of figuring what we wanted. We knew we were doing warlord world, so that also pushed me toward making a little more combat-centric design. That I knew—part of setting your vision is also figuring out what is the overall flavor you’re trying to get, and as you start piecing things together, you want to start making the mosaic that’s going to build up what your set is.

Okay. Now by the end of vision, the plan you want is you want to have—you want your commons and your uncommons, maybe your rares if you have them, but you don’t need a complete set of rares. But you want a general sense of what you’re doing. You want a good pass on your mechanics. Not that you won’t change the mechanics but a good first pass will (???) what the mechanics are, and a good general sense of your theme so that you can play it and go, “I got it, I got what the set’s going to do.”

So in some ways this is a sampler. This is where you want to make sure—because at the end of the vision point, you are going to make sure that other people in the department have a little peek into what is going on. And make sure they are happy.

Our peek is sometimes at the end of vision, sometimes at the middle of integration. It depends. But the key of Magic design is, it’s a group effort. And you want to make sure when you’re working on a group effort that you create the tools necessary to allow other around you to share their expertise.

And what I mean by that is, for example, development has to come in and you have to give enough of a sense of what the set is doing that development understands your goals and can look at your tool and judge your tools accordingly.

And say, oh, okay, I think I get what you’re doing, I like what you’re doing or I don’t like what you’re doing, I think your tools are a little inadequate. Maybe you want to change this tool this way. Or this tool we’re not going to be able to develop. So you might want to change that now, because we’re going to eventually have to change it and we’d rather you change it while you can, you the design team find a replacement, rather than development have to find it later. Because design’s going to make it more integrated. That’s the nature of how design works.

So vision ends, and you’ve presented a picture of what you’re trying to do. It’s commons, uncommons, maybe some rares. But you want to have a picture of what’s going to happen. And the iterative process, during the vision phase, is all about slowly adding to the picture. Of figuring out—of trying to get a sense of what you want to do. Of getting strong individual cards that play up your themes, of getting mechanics, of getting synergies.

It’s about doing the building work. To use the metaphor of building a house, vision phase has a lot to do with the architecture. About making sure that all the foundations are correct. You know what your bearing walls are. That you built the house in a way that it is going to be solid, and you can then build on what you’ve done.

Okay. Next is integration. So integration is the phase where you are trying to take the ideas you have and solidify them and just make a solid set. This is where you bring in outside assistance to get people from other sections to sort of tell us if there’s issues. You go to the development team, you go to the creative team, at this point sometimes you might even go to production.

So like in Innistrad, at this point, during the integration phase I’m like, “Okay, I think we want double-faced cards.” And that was a pretty big deal. That wasn’t just, “I want to do it.” That required a lot of buy-in from a lot of other people. That I had to go to production and say, “Can we do double-faced cards? Can we do what I need to do?” We had to go to Organized Play, okay, we’re introducing something new to the system. What kind of stress is that going to do? We had to go to development, and like what are we doing? Are we doing something that’s developable?

So there was a lot of different things that happened. Integration is where you step outside. Vision you’re kind of within your own thing, you’re just trying to come up with what you’re doing. You’re not worried about other people seeing it at that point. Because you’re just trying to get a sense of what you want to do.

Integration, it’s called integration, and the reason is, you’re starting to integrate not just your components, but outside components as well. And a big thing to remember in the creative process is, if you’re making a process in which there are others involved in the creative process, it’s a team thing, that it does no good to keep your team in the dark.

The goal—one of the things we try to do, and over time we’ve done more and more is, design is not meant to be a black box. It’s not like, “We’ll do our work and when we’re done, we’ll hand you something.” That we want to use the expertise of the people around us and work with the people around us to create something that reinforces what we are doing. Now, design has the role of setting vision, but it is important that we are working with everybody around us to make sure that we create a vision that can be achieved.

So the iterative process during the integration process is about sort of taking feedback externally, and like vision is about sort of internal feedback. And it’s not that internal feedback doesn’t continue during integration. But integration, you’re starting to take outside feedback. That might be just having other people playtest, it might be getting notes from other departments or sections of R&D.

But it’s about getting more critical analysis of—like, the vision phase, you come up with an idea, and you sort of said, okay. Here’s what we’re going to do. We’re going to do this thing. We are doing a horror world. We’re doing a Greek mythology world. We’re revisiting a world, be it Ravnica or Mirrodin or whatever.

And so, the idea is that integration is, it’s the same iterative process, but you are now taking outside feedback in addition to your own internal feedback. And that is very important, because there’s a lot of things that might—like when you’re in your little bubble, that might seem good, that when you bring outside forces that are like…

Because one of the neat things is, when somebody looks at your set, they are going to look to the set in their vantage point. Now your job as the lead designer is you’re inside and looking all around. But it’s very important you get other vantage points, because they’re just going to see something that you don’t see.

So I used this analogy before, about how when you’re a director—I wrote and directed plays in college. That it was a very, very important tool that my actors, my actors—I had to think about all the characters and how they all interacted. But my characters had to think about one character. So they spent a lot of time and energy trying to understand that character. And they would ask questions that I had not thought of because they were digging down deep. All they were focusing on is that one character.

And that’s very true of when you get outside—development’s going to come and they’re going to give you development concerns. They don’t have design concerns. They don’t have creative concerns. They’re going to have development concerns.

Likewise, creative, they’re not going to have development concerns, they’re going to have creative concerns. And that each one that comes to your thing is going to give something that has to do with their vantage point. Which is very important. Because what you’re trying to do is make sure that the finished product meets everybody’s needs. And so during integration, the iterative process during that is taking in the outside feedback and adapting to it.

So one of the things, by the way, I didn’t explain this before, iterative process tends to speed up over time. So the iterative process during the first—vision, note it’s about a year long, and so divided into three. So it’s about three months and change. I’m sorry, four months. Four months for each of these phases.

So the first one, you do a playtest during the vision phase every three to four weeks. Maybe two weeks near the end if you’re really starting to pick up some steam. During the second phase, you are doing a playtest about every two weeks. It’s like, you’re getting feedback, fixing things, and then every other week you’re fixing things, every other week you’re playing.

Early on, during the vision phase—during integration, you are much farther along. During the vision phase, you spend a lot more time talking and building and crafting because you’re making more of the bulk of the cards. You’re talking more to the themes.

So you get to the middle phase, what you want to do is have a lot of feedback, make changes, and then go back to the people that you got the feedback from. If development is saying, “We have an issue with this,” make changes based on the feedback. And then, return to them to make sure that they understand. Okay. Which brings us to the third phase.

So once—the first two phases, like you’re in your bubble, you’re looking external, we get to the last phase. The refinement phase. So at the end of design, on a large set, for example, the last two months, what we call “devign.” Which is where development is giving really—I mean, you have them look and give notes earlier, but this is, like, the team is started up. When devign begins, the development team begins. And they’re looking at your set very critically, and playing it, and giving very more intensive notes.

So the refinement phase is—so by the time you walk into the refinement phase, you want to have all the cards—there’s something in every single slot. Every single slot has something in it. And refinement is about, “Do you have the right things in every slot?”

And refinement is about trying to get the final sort of like—so if we’re using our house analogy, phase one is the architecture. You’re making sure it’s got a good foundation. Phase two is you are doing the plumbing and doing the electrical, and you’re doing all the stuff that’s going to make everything come together. And you’re putting up the walls, you’re doing all the actual structural getting the house built and making sure that it’s functioning well. The third phase is kind of the decorative phase. Where you’re coming in, you’re maybe adding some decorative elements, you’re painting. You’re putting down carpet.

You’re really turning it from—like, I don’t know if anyone’s ever built a house, but there are different phases in the house. And the first phase is kind of like, you’re looking at plans, and then they’re mapping it out and they’re digging a hole, and then you come in one day and your house is made out of wood beams. And then they start putting things inside the beams. And then they make walls. And then they start adding the windows.

And at some point they come in and they start painting, and they add in the cabinetry and the carpeting. Like, the refinement phase is that last thing, where they’re putting things in and it’s starting to look like a house. You can see what is coming from it. And that’s the refinement phase. The refinement phase is the finishing touches.

Now, in the first phase, in vision, like I said, you have a playtest about every third week. And in integration, you have a [playtest] about every second week. And refinement, you have a playtest about every week. Usually what I like to do during the refinement phase is, we meet twice a week, we meet once a week and take notes on our previous playtests and make some changes, and then we playtest on the second day.

Now, one of the reasons why as you move along during the iterative process, that it gets shorter, is you are making smaller and smaller changes. Part of what happens is, early on in the iterative process, you’re making huge sweeping changes.

Like in vision, you might be swapping out mechanics. Like, “Let’s try this mechanic!” “No, let’s try this mechanic.” “No, how about this mechanic?” “Ehh, maybe.” “Well, let’s keep this mechanic and change this other thing.” Or, “Let’s radically change how we do this mechanic.” “This mechanic is open-ended, but maybe we want a little less open-ended.” Or “Maybe the mechanic needs to take place at a certain time,” or maybe we’re… the point is, early on, when you’re doing the iterative process, you’re making huge sweeping changes.

It is quite possible, by the way, between Playtest A and Playtest B in the vision phase, a third of the file could change. A lot of the file could change. And then as you move along in integration, there’s still the possibility for bigger changes. But in general, the changes you’re making tend to be a little bit smaller than they were during vision. And then refinement, oh, refinement. You’re making very—you know, much more careful, small changes.

Now, be aware. That doesn’t mean during the course of the process, things can’t happen. It’s not like vision, I make the big choices and we’re done. Maybe during integration, development’s like, “We can’t make that mechanic work.” Like, okay, I have definitely swapped things out during both integration and during refinement.

Sometimes during devign we put the pedal to the metal and test something out, really stress test it, development’s like, “Aah, it’s just not working.” And then I’ve had to change things in devign. I mean, things get changed in development sometimes. And that’s not ideal. Hopefully you get the mechanic you want before you get to development. But the idea in general for the iterative process is that you want to be making smaller and smaller changes. That the iterative process gets quicker, but the changes are smaller. And that’s why it can be quicker, because you have smaller changes.

Okay. Let me talk about a couple strategies about how to use the iterative process. Number one, which is—and this is sort of using science to your help. One of the things about understanding change is, you need to make sure that you have some constants and some variables. What I mean by that is, you can’t change everything. If you change everything, it is too disorienting and it’s hard to learn. It is hard to understand the differences.

So what you want to do is every time you are doing iterative change, make sure that you keep something the same. In fact, you want to keep most of it the same. That you don’t want to change things too much. What I say is, for beginners that aren’t used to this process, you might want to only change one thing. That you want to make sure you understand, you have a grounding in what you’re doing so that you understand what the changes are.

Now, I’ve been doing this a long time. Like I said, it’s my twentieth year. I tend to go much faster through it. I’m more willing to throw more different things in at once. But that just has to do with the fact that I have a lot more experience doing it. And I think that when I have a newer designer, what I say is, “Make sure you understand what the changes are when you make the changes.” If you iterate too much too quickly, sometimes, you can lose special things that you have.

Another important lesson of iteration is—and the reason why iteration is so important is, there is this desire to what we call “theorycraft,” which is to understand things by talking them through and comparing them to other things in Magic. If you are doing your job—I talked about this in both of my playtesting podcasts [NLH—I don’t remember a second.]—if you’re doing your job, you need to be actually playing with the cards. It’s how they’re going to be perceived by the public. You need to understand, and you need to put them through their paces in the way they’re going to be used. Which is through play.

And just like I talked about with the actor, that it’s one thing to think about a card and another to use a card. And when you use a card, you actually get the issues that come up. “Oh, I hadn’t thought about that issue, but now that I’m playing with it, oh, that is something important we have to think about.”

And so the reason for all the iterations in general is that if you want to appreciate what you’re doing, you need to walk through and experience it. That when you’re writing a book, there comes a point at which you have to read it with a critical eye as a book. You have to read it. Stop thinking about it as a structure and just read it and go, “Is this an enjoyable book?” And then test things as you go through. And playtesting’s the same way. You want to play with your things and get a sense of it.

And one of the neat things about iteration is that if you do enough iteration, you can see things as they improve. Which from a morale standpoint is important. That if you have a horrible playtest, it’s a little discouraging. But if you walk away from it understanding why the playtest was bad—and one of the things I say is, a horrible playtest is a very valuable tool.

The most frustrating to me actually is a very mediocre playtest. Nothing was great but nothing was horrible—those are the hardest. A playtest in which it was horrible, things stunk, you will learn from that and you will make changes and you will make it better.

But like I said, the reason the iteration is important is, you want to build on something, figure out what you’re doing correct, maintain that, and then adjust things while you’re—part of iteration essentially is, it’s a building process. What you really are doing is you’re building your set, and each time, you sort of evaluate your latest changes and say, “Am I going in the right direction? Is this build what I need?”

And then, what happens is, you take the thing that are working and you keep them, you take the things that aren’t working, and some of those might be older things, because as you change things, things that once worked might not work. And then you remove them.

So in some ways, I like to think metaphorically that you are chiseling a statue. And that each time, as you find new things that you’re sure on, you get to keep those things, and then you get to whittle around at the things that aren’t right.

And there is—one of the things that also, I try to think, people always talk about how much fun it is, because I get to play at my job all the time! And it is fun. But one of the things that I always like to say is, we play a lot of bad Magic so that you don’t have to. That we try a lot of things and we go, “Ugh, that was horrible! We would never want to inflict that on the players.”

Now, you guys have the luxury, and it’s awesome, and you should, of getting to play what we intend. Of being the best of the best. That this is what we want you to see. And that when we’re playtesting, we do a lot of things that do not work. That are disasters. We’ll playtest with cards, we’re like, “Oh, that’s crazy broken!” Or “This isn’t fun!” Or there’s all sorts of reasons why just you can have a playtest and go, “Ohh, I hated that.”

And like I said, the key to iteration is that you are building over time. And that when you’re writing a book, it’s like, not every sentence of every book gets written right off the bat. And that’s the same with card design which is, if you went through the set and picked out the gems, what are the standouts? Sometimes some of those cards came early in the process. Sometimes they came late. Sometimes they came in the middle. That your moments of awesomeness happen along the way because you create so many opportunities for that. And that the iterative process allows you a lot of attempts.

I talked about this before, which is, we make a lot of cards that never see the light of day. For every card that you actually see, somewhere between fifty and a hundred. R&D always argues about what’s the ratio of cards made vs. cards printed. And it’s a whopping ratio. Even if it’s fifty. I think it’s closer to a hundred. But even fifty to one. There’s a lot of cards that get made that never get seen. And the reason is because you try things and you always want to figure out the best way to do them.

And what I see in new designers, and the reason I really stress iteration, I think it’s important is, there is this myth about creation that like one day you don’t have it, and then thunder strikes your brain, and poof! And now you have it. And it is complete. And you now have a wonderful thing.

And there’s this idea that the generation that creativity is this like thunderbolt from the sky moment, where like it’s just this magical moment. And the reality is, no, it’s a lot of work. Maybe the initial idea, and even then. It’s not like your idea comes at once. You work and work and work and work at it, and finally craft what the right thing is. That very little design—not that I don’t have moments where—I mean I literally had a moment where I woke up in my sleep and had an idea. But that’s few and far between.

Usually what happens is, now take Khans of Tarkir for example. We started with the idea of a time travel—we started with the idea of a weird drafting block. And then we came up with the idea of a time travel thing. And from that we got warlord world and dragon world. And then from that we got the idea of doing the clans, and from the clans we got the idea of aspects of the dragon.

And each thing came along the way. It wasn’t like we just sat down one day and go, “I got it! Dragon clan!” Like, that was not where the process came from. It was a small, iterative thing where we kept making small changes. And that that is what the creative process is. It is a lot of work. It is not moments of thunderbolts in the brain, surrounded by twiddling your thumbs. No, it’s a lot of hard work. The reason that a Magic set is as good as it is is because a lot of people put a lot of energy and a lot of time through a lot of iteration to make it good.

And that part of today is, you’ve got to put in the time. You are not going to get something brilliant just by sort of sitting around and talking about it. You’ve got to do it, you’ve got try it, you’ve got to experiment it, you’ve got to take feedback, you’ve got to adapt to feedback. And that the way you make something truly awesome is putting in the time to try every version that isn’t awesome.

In fact, that’s one of the ways I like to joke about “How do we make a good Magic set?” “By making all the bad Magic sets and then getting rid of them.” The iterative process is like, “This is a bad Magic set, let’s try again.” “This is a bad Magic set, let’s try again.” “This is a bad Magic set, let’s try again.” “Ooh, this one’s pretty good. Maybe we should keep this one.”

That in some ways, what we do and what the creative process is, is slowly working. Just like the act of physically building something. Building something creatively takes time and energy and care. And that the reason I talk about iterative process today is, that’s just one of the tools to be able to build something creative.

And understand the expectation that it’s going to happen slowly over time, not all at once. And that you will have individual moments of cool things where you come up with something, but really, the true genius of a creative work comes from the fact that lots and lots of tiny, tiny awesome ideas. Not one big awesome idea, but lots of tiny awesome ideas.

And that when you are putting it together, you need to create the moments of possibility to discover the small things, and to enjoy the small things. That every small victory needs to have its moment in the sun, because the small victories lead to other victories. And that is how you make something truly awesome.

So anyway, I am in my parking space. And so we all know what that means, that means this is the end of my drive to work. So instead of talking Magic, it’s time for me to be making Magic. I’ll talk to you guys next time. (???)