I come from a long lineage of builders and architects.
My father started his own construction company, working on buildings across all of Seattle. My grandfather helped build my hometown, planning and creating many of the buildings that still stand there today. My family's last name is literally written in the book about where I grew up.
Tables at home for my entire childhood were filled with scattered blueprints, rulers, and construction notes. Weekends would be spent looking at houses or visiting construction sites. I was embroiled in the scene—even though I knew very little about it.
One day, I was sitting down with my dad at home. He pointed at the blueprints haphazardly strewn across the countertop. They were curling at the edges, with the side view of a two-story house poking out from the center.
He nodded toward them. "What do you see?" he asked.
"Blueprints?" I replied.
"I see the foundation the rest of someone's life will be built upon." He paused. "Someone is going to live here. They will fill this house with their things. And while I don't choose the things, it's up to me to make sure they are happy putting all their things there. That's why we have to build it right."
I'll never forget that.
Now, 20 years later, it turns out I'm an architect too. I am part of a team that is creating foundations for everything else.
I'm just doing it a little differently than with houses; I'm doing it with Magic sets!
Welcome to Product Architecture.
You might not have heard of the Product Architecture team (also sometimes called the Product Design team) before. And that's because it is relatively new part of R&D. It's really only grown to be its own team within the past year, though the core of Product Architecture has been done by its individual members for a while now.
We're a tight-knit, strategic team inside of Magic R&D. And today I want to pull back the curtain and tell you more about what it is that we do
So . . . What does an architect work on? Do we look at Amonkhet and think, "Hmm, the Hekma could really use some more high-rise buildings?"
Well, that sounds awesome—but no.
Product Architecture is about focusing on the vision of a set or product, looking at things a couple levels up from what you may normally hear about here on DailyMTG.
Most people in Magic card design are focused on creating individual cards. Product architects do some of that too, but it's not the core of what Product Architecture is about.
Some people in Magic R&D get to lead specific teams, calling the individual card design shots and focusing on crafting the set's overall gameplay. We do some of that too, and that's getting closer to what we do, but we're still not quite there.
The Product Architecture team focuses about one level of vision higher up from that.
While the set lead is focused on figuring out the mechanics and cards of a set, Product Architecture helps keep the vision on track, providing help where we can and identifying potential holes to work on.
If a set lead comes to me on a set I'm architecting and says, "I have a problem," it's up to me to help them figure out how to fix the problem. Similarly, if I see a problem with how the set is reflecting the overall vision I have of the set, it's up to me to relay that to the lead designer so they can start working on it.
These kinds of problems could be anything from "This set is missing something splashy" to "I heard this set about Dinosaurs and Pirates is going to have a Goblin on the front of it. What's up with that? Why not Pirates and Dinosaurs?"
A lot of it is proactive as well. For example, if we know a set like Ixalan is going to be tribal, it's up to us talk to other teams and relay that so they know. That way, marketing is designing elements around it that are about tribal rather than it being just about Pirates.
We do this for all products, not just sets.
Planeswalker Decks? That's us!
Commander Anthology? Yep.
The San Diego Comic-Con exclusive? Absolutely!
In short: We touch all aspects of the set or product, working with the designer, Brand, Packaging Design, and practically every other team inside Wizards to make sure every release is as fantastic as possible from every angle.
Five of the many things I might do in an average day include:
- Play games of upcoming Magic sets;
- Look through a set file to see what's working well and what's missing;
- Read through player feedback to see if we should create something new to address a potential hole—or remove a product that hasn't been doing the right thing;
- Figure out what exact components should go into upcoming products; and
- Relay R&D's needs and desires to other groups inside the building to make sure we're all on the same page.
Here's something fellow product architect Mark Globus said once that I think captures our job pretty well:
"A product architect's job is to turn something nonexistent into something good, something good into something great, and something great into something amazing."
That sounds like a huge task. So, how big is the team? Like most areas of Magic, it's probably gigantic, right?
Well, this is a rare exception! Our entire team is three people. (Though we are hiring a fourth right now!)
Let me introduce the rest of the team.
Mark Globus heads up Product Architecture. He pioneered the space inside of Wizards, realizing the need for it and creating the team himself. (Which is probably what makes him such a good product architect!)
If you think you've seen Mark talked about on this website before, it's because . . . you probably have! He not only is an alumnus of the Great Designer Search, but has worked on many, many design teams—including leading Magic 2012, Magic 2014, and the first Commander decks with Commander (2011 Edition).
Mark has worked on five different Commander teams as a designer, and if there's one thing I've learned from playing Commander with Mark Globus, it's this: never attack him unless you're prepared to get attacked by him every turn from the rest of the game.
Seriously. If you ever find yourself in a Commander game with him, you have been warned.
Mark Heggen is relatively new to Wizards, joining us nearly a year ago. Coming from a highly creative background, he took right to the position, and he's already been busy doing architecture work on many cool things to come.
The first of his handiwork? The HASCON promos! If you were excited to try to get your hands on those sweet promos, Mark Heggen is partially to thank. (And we'll be talking about those a bit more in a moment.)
Additionally, Mark Heggen adds yet another Mark to our tremendous count of people named "Mark" at Wizards. As you're reading this, do your best to keep track of which Mark I'm talking about. (It's hard even for me sometimes!)
I know, I know—you were expecting another Mark. So much for that pattern!
Something I've loved about my job at Wizards is that I get to do a lot of different things, and nothing exemplifies that more than Product Architecture. I'm on the Product Architecture team, and in addition I still do a lot of card design work as well. (So if you loved Commander (2017 Edition), fear not. There are plenty more sets I've worked on coming your way!)
And . . . that's it! That's the whole crew of this well-built ship.
Now you may be wondering, what are some examples of what we do?
Well, let me tell you three stories that tie right back into our mission statement from Mark earlier.
Turning Something Nonexistent into Something Good
Let's take a look at those sweet, sweet HASCON promos again.
This is a perfect example of something that didn't exist, and then was born out of nowhere.
How did this come about?
New products basically come into existence in one of two ways: Product Architecture goes to Brand and says, "Hey, we would like to do something new," or Magic Brand comes to Product Architecture and says the same thing to us.
In this case, it was the latter.
Magic Brand decided that since we would have a presence at HASCON, it made sense we would have an exclusive item there. So, they came to Product Architecture with a request for a HASCON exclusive. That's all we knew they needed—something for HASCON.
But it could theoretically be anything: a Play-Doh container that looks like the Planeswalker symbol; a game of Mouse Trap where you trap Planeswalkers on Ixalan; or maybe, yes, even Magic cards. What it was going to be was entirely up to the Product Architects. (And in this case, Mark Heggen.)
Product Architecture didn't have to design the cards—we had to design the entire product.
After a brainstorming session and asking around to people in Magic R&D, Brand, and other departments, we landed on the card approach you have all now seen. We set the team in motion, and an R&D designer worked to create the actual cards.
But that's far from where the story ends.
While the designer is working, we're the two-way river that all information flows through.
How many cards should there be?
Should the packaging be incredibly stylized and good for displaying or more like a booster that you open up?
Are Hasbro's teams okay with the characters of theirs we've picked?
These are all things we had to look into and communicate with everybody else about. When the design team for these cards says they've chosen Grimlock as a card in the set, that means it's time to reach out to all the other teams that it could possibly affect—Brand, Packaging Design, and more—to let them know and make sure there aren't any problems with using Grimlock here.
And if Grimlock changes to some other Transformer at some point, it's important to run right back up the chain so everybody knows. It's a product architect's job to make sure all the teams working on a product know and understand what R&D is doing with it.
Turning Something Good into Something Great
We came out with our first Commander decks in 2011, and they were a smash hit. We pretty much immediately decided to start doing them on an annual basis, firing it back as soon as possible in 2013, and every year after that.
The first ones were based around color. So, we made the next ones about color. And the next ones. And the next ones. And the next ones . . .
The Commander decks were totally good. Everything showed that they were a success, players liked them, and they helped bring tons of people into Commander.
They were good . . . but Product Architecture thought they could be even better!
After five iterations on these, Product Architecture had come into swing. And taking a step back, there was a lot to look at.
A lot of our playtesting told us that four-player games with these decks were generally preferable to five-player games, and easier for new Commander players to process. However, by selling five decks, we were passively indicating that we recommend people play in groups of five, when really we thought four would be better. And while we had done the previous decks by colors, which lends itself well to fives, that had pretty much run its course.
Additionally, if you look at Magic history, we are a game that has had a ton of success with themes. Our worlds, for example, are all built around themes.
Why weren't Commander decks built around themes too?
Taking all of this into account, a new idea was hatched: let's change to four decks, each with a theme of some kind. And to make it even better, the themes could be tied to the set around them, helping make sure that even new players who join up can go get some cool new cards for their deck. We could even do tribal, which paired perfectly with Ixalan being right around the corner!
This was delivered to me as the lead of Commander 2017. I could do whatever I wanted in the sandbox of four tribal decks, but we were doing four tribal decks. The cards and factions? Those were up to me. But the themes and number of decks were determined by Product Architecture.
The result? A runaway hit.
Commander 2017 is our most popular Commander release ever. And while I am very proud of the design as the lead designer, it wouldn't have ever gotten here without the initial direction of four tribal decks. I would have never deviated from five color-focused decks if I hadn't been asked to.
A product architect always listens and re-evaluates. The team listened to feedback they had been hearing, and instead of just doing something the same way because that's how it had been done before, they came up with something new—which made the set even better.
So, why is Commander 2017 in the "Good to Great" category rather than the "Great to Amazing" category if it did so well? While it turned out great overall, it was also our first time trying the direction of themes. And as our first attempt out of the gate, there was a lot we learned, both as product architects and designers, about what that means. You all, the players, have given us your feedback on what worked and what didn't, too.
Now that we've learned more on both axes, both internally and externally, we can put that information toward making future versions of a Commander-focused product ascend from great to truly amazing!
Turning Something Great into Something Amazing
So far, you've seen two different major aspects of Product Architecture. The first example was about coming up with the idea and helping support it once it's underway. In the second, we re-evaluated what already existed on a product level to make it as strong as possible.
This example shows yet another different but crucial side. This is where we really interact with the core design of the set more.
During Ixalan design, the set was coming together nicely. The tribes were being chosen, and the Dinosaurs and Pirates were big and splashy elements. We hadn't done a tribal-focused set in a while, which we knew would make for a fun return for players.
But the set was still missing something.
There were two problems identified by the architects.
First, the world that had been built around the tribal themes was an awesome adventure world. There were mysterious jungles, hidden treasures, and uncharted waters! However, "tribal" doesn't really have anything to do with adventure. How could we get some of that exploration and adventure into the set?
Second, the set had a lot going on for people who liked tribal—but what about people who weren't drawn in by the tribal themes? What was the big splashy mechanic for people who weren't smitten with the idea of running Dinosaurs into Pirates?
We had identified a hole, and we needed something to fill it. So, Mark Globus brought it up to the design team and asked for them to make something in this space.
Now, it's important to understand that Globus communicated the need to design, and gave them parameters and even an example of what he meant—but it was up to the design team to come up with that to do.
After some work, the Ixalan design team came back with something that fixed both sides of the issue.
And I really do mean both sides:
The idea of double-faced cards was perfect; it both was a splashy, exciting return and communicated the exploration nature of the set very well. You had things that helped you search for these lost lands, rituals, and relics actually turning into them.
From there, Globus took the idea and had several discussions with different groups. For example, philosophically, was it right to do double-faced cards again so quickly after Shadows over Innistrad block? What was the right amount of these in the set? Should they all turn into lands? He handed a lot of this research back to the design team and let them run with it.
A product architect is always thinking about what a set might be missing, if the cards are reflecting all the themes, and how to make sure the set has pieces that are exciting for everybody.
And that's the story of how Ixalan got its double-faced cards, taking it from a great set all the way to one of the best we've ever made. Awesome, indeed!
Blueprint for Success
When you're building a house, you want to build it right. There's a lot to look at: the structure of the building, the way the rooms are divided up, where the outlets should go, and so on. And if you don't do any of those as best you can, the house will be worse. People will be less happy putting things in there.
Any given Magic product is similar.
Like a building architect, a Magic product architect always has something to work on, some tweak, small or minor, to make Magic better. Whether it's reading through pages of player feedback to create a new product, looking through sets being designed to see what elements they are missing, or running around the building and talking to people to make sure everybody is on the same page, it's always there.
And that's just the tip of the iceberg.
Ever since I started architecting, I've had some of the most active, involved, and creative days in my six years working in Magic R&D. There's nothing else I've done quite like it!
Does this sound like something you'd be interested in doing? We'd love to have you on board! If you're at all interested, I encourage you to apply for the position I mentioned earlier and work alongside us to make Magic awesome!
I'd also love to hear what you thought about this! Do you have any questions? Did you find this insight interesting and would like to know more? Is there a product hole that you think we have which should be filled? Please let me know! You can send me a tweet or ask me a question on my Tumblr.
And who knows—if enough of you find Product Architecture interesting, perhaps we can make articles about Product Architecture a more regular thing.
Hopefully you enjoyed this look at Product Architecture. Now it's time for me to put the writing pen down and pick the architect pen up. There's architecting to do.