A presentation at Beyond Tellerrand in November 2017 in Berlin, Germany by Dave Rupert
Hello, everybody. I’m Dave Rupert. I’m from Austin, Texas. I’m really happy to be here in Berlin. When Marc invited me, I instantly said yes because Marc is Germany’s sweetheart. This talk is vague but exciting, and I promise you it will be vague, but exciting. As I’ve gotten to know the local culture here, I decided I need to rename my talk. This talk is all about prototypes, so I’m going to rename the talk here just for Berlin, and it is “Prototypen: Arm Aber Sexy.”
I was watching Star Wars with my nephew, and the movie finished. The credits come rolling, and there were names and names and names and names and names. I’m thinking to myself, “How the fuck did they make this?” because every time I’ve made a website with more than five people, everything goes to shit. Things catch on fire.. it’s terrible.
This launched me on a one- or two-year quest to sort of answer a question.
That question is, how do large, creative projects succeed? I specifically mean digital products that go into a digital medium.
Then the, I guess, inverse of that question is, why do large, creative projects fail?
I’ve been doing some research. I’ve been scouring the Internet making connections, and I’ve been doing a lot of research in finding examples that confirm my bias. I’ve been looking around and really trying to figure out how these large, popular, creative projects succeed. I think I’ve come up with some answers. The answer is prototypes, so let’s begin or continue our journey.
The first stop on our journey is Pixar. I think we all know Pixar. They’re a beautiful animation studio, and specifically Pixar because they have created dozens of hits over and over and over and over. They make good movies. There’s maybe like two, Cars 2, and The Good Dinosaur, that are not so good. But, they keep making good, good, good products.
I was very thrilled to find this book by Ed Catmull called Creativity, Inc., and it’s a look inside to how Pixar works. Who is Ed Catmull? Good question. He is this guy. He’s the guy you don’t know. In the middle is Steve Jobs, a computer guy, I guess.
Dave: John Lasseter, a very talented animator, and then Ed Catmull is a computer scientist, but he specialized in computer animation. In fact, his life goal was to make an animated film. He was the first person to articulate, animate an articulated hand going like this, and that’s amazing amounts of computer science.
His life goal was to make an animated film, which he did with Toy Story and won Oscars. Then he did it again with Toy Story 2. He found himself kind of, “Okay, I’m done. I did my life goal. I’m done. Thank you. Bye.”
But, he switched his focus in how Pixar runs in working on how Pixar makes movies hits after hits after hits. There’s a lot of good advice in this book if you can find this book and read it. I don’t know if it’s in German, but I would hope so.
There’s a lot of good advice, but one thing I want to kind of draw attention to is the way he describes making a movie versus making an animated film. When you make a movie, the first step is to have some directors, some writers start to piece together a storyboard, a plan. They kind of put this all together. Then you capture the film.
You have maybe 100 people. You have the actors, Tom Cruise on set, and then you have the caterers, and then the people who operate the cameras. You have all these people on set for a very short amount of time. You try to minimize that amount of time because it’s very expensive to have Tom Cruise on set.
You want to make that very short. Then you go into an editing phase. Maybe you do reshoots and fix things up, but it’s mostly like six people or so kind of finishing out the movie, depending. It can flux, but when you make an animated film, though, it’s a lot different. You don’t have an editing phase.
When you make an animated film, the animation process with all the people is very expensive. It’s not 100 people. It’s somewhere between 4 and 700 people, highly skilled computer animators that you’re bringing in for a short amount of time as possible, like one to two years, you want to bring them in.
As a result, you have to do a lot of planning. There’s kind of a saying. There’s no editing in animation because it’s so expensive to edit, reshoot, redo, redo, redo, and redo. You have to kind of have a plan and make up a plan, a really good plan.
A lot of animation ends up looking like this. This is kind of how you plan out in animation. You do a storyboard. These are all hand drawn images pinned up on a wall. Then you kind of walk through, moment by moment, keyframe by keyframe, tell a story, and get people excited. This is kind of the prototype of the movie. As you can imagine, this is a very hard task, drawing every frame of a movie and putting it on a wall.
What I found was interesting is Pixar made some software. This is a piece of software they call Pitch Deck. No. Oh, what is it? I have it here. Pitch Doctor. Yeah, Pitch Doctor. This is the only picture I could find on the Internet of it. It’s very secretive, I think.
It’s basically a PowerPoint that you sketch in. You can add auto tracks and basically time out a movie and build a whole movie in sketches right in a PowerPoint-like interface. You can add notes, sketch, and kind of fix things up as you go. This allows them to prototype more and prototype faster before they get to that expensive part of building a movie, an animated film.
Uh-oh. There’s a head with some gears on the wall. What does this mean?
This is where I want to take a moment to kind of apply this to the work we do. We make digital products like websites, apps. I actually don’t know what you do. I would love to hear it. But, let’s look at how this affects our work.
The first thing I’d like to do — I’m launching a new product today. I’d like to introduce you to a revolutionary new design thinking thought technology. Are you ready?
You see, you sketch on paper and it works really well. What I love about sketching is anyone can sketch. You can sketch. He can sketch. She can sketch. Your boss can even sketch an idea out, and you can start communicating.
I would actually argue; if you can’t sketch it, don’t do it. If you can’t get this idea in a really rough form, don’t even try it. This is how we do a lot of our work is we just do a sketch. There’s a thing that’s a carousel, and I don’t know. Everything needs a carousel.
We like to sketch out ideas and communicate with that because it is free. It is so cheap to do this over and over and over. You can do thousands of these, and they go in the garbage or recycling. Yes, they go in the recycling.
You can be so much farther along in your thinking before you even start opening PhotoShop or code. That’s kind of the, “Okay, let’s sum it up.” Think through problems before getting to the expensive part. That’s the thing I learned from Pixar.
Then come to find or make technology that allows you to prototype quickly. Just like Pitch Doctor, maybe there’s something you can find that helps you prototype more quickly.
Overwatch is a game made by Blizzard Entertainment from World of Warcraft, all of that. Thirty million people play this game. That’s the size of Germany or Canada. A lot of people play this game. It’s very popular.
I thought it’d be interesting to see how they kind of piece together their new ideas, and I was thankful. The story sort of starts with this character. This is an African Minotaur built by a 13-year-old girl named Orisa. She has a cannon. Then she throws down a drum with some energy shooting out of it. Obviously, yeah, it makes sense.
What’s even more interesting is how they came up with this character. I was pleased to find these developer updates that sort of explain how they come to these ideas. I’m going to play a little clip. There’s some audio here, so hopefully, you don’t get blasted, but here we go.
Male 1: A lot of the characters of Overwatch come from many different places.
Sometimes it’s from design. Sometimes they’re from stories. Sometimes
it starts with the art. We talked a lot about introducing another, what
we like to call, anchor tank. Reinhardt is one of the only characters
that can really sort of stand his ground and mark his spot and move with
his team real slow, so we thought there was a great opportunity there
for another option. Orisa was amazing almost from the earliest prototypes.
While I was testing and iterating all these ideas, I was actually using
one of Zarya’s alternate skins internally to make it so it wasn’t too
confusing as Zarya was in the game just so we could test it.
Male 2: We see a gothic Zarya, add to it Bastion’s cannon, that was just a
combination of cobbled together parts, but it was instantly fun, and that’s
how we knew we were onto a good hero.
A combination of cobbled together parts. But it was instantly fun. And that’s how we knew… ’ – Jeff Kaplan, Game Director of Overwatch
They took the model of one character, and then took a gun from another character, then they took a shield thing from another character, and they just smashed it together and were like, “Is this fun?” The answer was yes, and then they built it. They kind of continued on the art and everything.
I find this really inspiring. I like to think of all of my productions as cobbled together parts.
I think the most obvious thing is, do you have a system of parts, a pattern library? Pattern Libraries have been very popular in the Front-end Web industry lately, but pattern libraries are amazing.
You figure out all the problems, then you just have parts that you can cobble together into new things, and you don’t have to make those decisions over and over and over.
I think Mina Markham’s story about the Hillary campaign is amazing. She made Pantsuit, and that allows, allowed her, allowed the Hillary team, to make dozens of products in an 18-month lifespan. If you’re talking about how we can quickly develop, I think the answer is in establishing a style guide. You can quickly create minimum viable products.
I actually hate this term “minimum viable products.” I don’t think anyone uses it correctly. I don’t think anyone actually does it well. Usually, it’s minimum viable products means maximum amount of shit I can put into a two-week sprint.
I like to say, find out if it’s a dumb idea as quickly as possible because, if you find out it’s dumb — everyone has ideas. Your boss has a lot of ideas. It’s best to find out that it’s dumb real quick than to spend 8, 10, 12 months on a bad idea. Right? The quicker you can get into prototyping with your cobbled together parts and then you can show your boss.
I think you’re going to solve a lot of problems before they turn into a lot of heartache.
I am a Nintendo fanboy. I love it very much. I think there’s a lot we can learn from their creative process.
I was pleased to find this story about the launch of Super Mario 64.
Super Mario 64, this was an amazing game. This game basically pioneered video games, 3D platform video games, the video games that exist today. Overwatch, in some way, owes its credit to the work that was done here.
What’s amazing about Super Mario 64 is, they were building it for hardware that didn’t exist yet. The Nintendo 64 didn’t exist when they were developing Mario 64. They were building on $10,000 computers, and it was going to ship to $200 hardware.
Let me repeat that. They were building on $10,000 machines that were shipping to $200 hardware. Does that sound familiar? That sounds a lot like my job.
Miyamoto: There was a room made of simple Lego-like blocks, and Mario and Luigi could run around in there, climb slopes, jump around, etc.
He said the way Mario 64 happened is there was a room made of simple, Lego-like blocks. Uh-oh. Legos, that’s a style guide trigger. Mario and Luigi could run around, climb slopes, jump around, et cetera. We were trying to get the controls right.
Miyamoto: We were trying to get the controls right with an analogue 3D stick, and once that felt smooth, we knew we were halfway there.
Then, this is the most amazing quote.
Miyamoto: As for the courses and enemies, those actually came at the very end. They were done in a single burst of energy, just thrown together, almost.
Wow! The game that defines 3D video games was almost thrown together.
I find this amazing. When you get into the philosophy of Shigeru Miyamoto, the creator of Mario, the creator of Zelda, the creator of Donkey Kong, you start to understand this. I feel like this is his ethos.
We get the fundamentals solid first, then do as much with that core concept as our time and ambition will allow. – Shigeru Miyamoto
They figure out the function, and then they work on it; they iterate it as far as they can go. I think that’s interesting for us because I don’t feel like I’m ever sensitive to, like, let me get the core and then we’ll just work and see how long we can go until launch time. I never think like that. It’s always a rush to launch time, and I’m sweating and crying.
Miyamoto says this phrase a lot. This is the Japanese word “tegotae,” which means hand response. There’s also a thing like when you bite into something. That’s “hagotae,” the feeling when you bite into something. Tegotae is the feeling when you use something with your hands. In English, we say “game feel,” and I’m sure there’s some 20-character German word for it.
Haptic
Haptic. Yeah, there you go. We learned something. Da-da-da. The more you know. They focus on this haptic, this game feel, the feeling of the game.
I was pleased to find another example from another Nintendo game called Splatoon. It’s a little niche, but the game is basically a game where you run around and you try to paint a level. It’s kind of like a shooter, like team shooter, but you try to paint a level.
It looks a little bit like this. You’re kids running around with guns, and then you’re squids also, too.
Would you like to see how this game started? It’s very interesting. It started like this…
They called it “tofu”.
Just little blocks of tofu that would disappear, come up, and shoot. I don’t know if that’s a gun, a nose, or what that other dot is, but they would run around, shoot, and just see if it’s fun. They’d just establish that core function, and then they kind of iterated on it. That’s where they added, I guess, squids because of ink and then squid kids because — squid kids
This is from Satoru Iwata. He is the late—just recently passed away—president of Nintendo.
The way that Miyamoto-san [makes] games, the idea comes not from the design, but from the function. The design comes after. – Satoru Iwata
I know every designer in the room just said, “Nope!”
But I think, when they talked about design, they just mean the visual, the visual look and feel. I think, as designers, you should be involved in the function. Function is not just code. Function is feeling, like, is this going right; is this fast; is this good for the user? How does this have to feel? You can decide that before you get into the visual aspects of design.
Let’s get our brain going. Okay? Let’s get the gears going. Here we go.
I think it’s important to prove ideas before committing to them. You know? If they walked in and they said, “We’re making squid kids. Let’s go,” no one would know. But instead, they started with this idea, “Let’s try to make blocks move around, shoot, and paint and see what happens.” I think that’s a really good way to kind of do that and to build digital products.
The way we do that at my work is we do it on CodePen. We do a lot of CodePen. I have 700 CodePens in my account. You can maybe see half of them because they’re all private. There are, like, four big clients that we work with.
I do the dumbest things, and I do very useful things, but most don’t even look through my CodePens because it’s mostly just Bill Murray photos, and it makes no sense. But, it makes sense to me because I’m working on that gray, that tofu. I’m at the tofu stage of experimenting with things.
I even prototyped out a game. I had this dumb idea. It was Sunday night, and I had a conference on Friday. I was like, “I’m going to make a game for the conference that 600 people can play.”
Oops. I had never made a game before. I didn’t really even know Canvas, so I just said, “I’m going to do it,” so I cracked open CodePen. I wanted to make, like, an asteroid shooter game. You know, defend the city. I was like, “Okay, I know how to do this.”
An asteroid, that’s like a circle shape, so if I make a circle fall down. I made a circle fall down. Easy! Got it done in four hours.
Now it’s Tuesday. [Laughter] Then I was like, “Okay, now I need to shoot the asteroids,” and so I made a button. I was like, “Okay, let’s just shoot.” Again, this is the tofu level. What’s interesting here is, I originally wanted lasers, like [laser sounds]. I wanted lasers, but I was like, “I don’t know how to make a laser.”
But, if you think about it, a bullet is just a very small asteroid, and I already have the code for asteroids. I just need to make it go up instead of go down, so I copy and pasted. Then I set positive to negative, and there we go. I had bullets that shoot up.
You can’t aim yet, but that was kind of the next day. I figured out how the gyroscope works on your devices, your laptops and phones. Then I hooked that up.
Then the next day I think I was on a plane. I was doing a lot of scary math. [Laughter] I was doing math on a plane on paper, and it looked very suspect.
Eventually I put together this game. It’s a game you can play. You basically have your device, and you rotate your device, your laptop, or your phone pretty much would be the best solution. But, there’s a way. This little ID here, your friends can join in. You can put this up on a conference wall, and your friends can join in and also try to kill asteroids. It’s kind of a lot of fun.
Zelda. Who has played this game? This is Game of the Year, probably. This is an amazing game. This is an illustration of Zelda, Breath of the Wild that doesn’t really give you the sense and depth of the game.
here’s kind of the animated gif of that same shot. Every pixel you see on here, you can interact with. Every pixel in this frame, you can crawl up, you can climb, [and] you can jump. This is an amazing game. It just redefined exploration in video games. It just came out this year.
How did this game start? Any ideas?
It started here in a 2D prototype. How nostalgic is this that the best Zelda ever started with the other best Zelda ever?
Every video game has a physics engine. That’s the motion, the movement, the running, [and] the jumping. Every game has a physics engine. But, they had come up with this idea, this concept of a chemistry engine. That’s sort of like Minecraft. But, if you take fire, you take wood, and you put them together, what happens? Wood catches fire. If you take wind, like a leaf that you make wind and you connect it with a tree or grass, what happens? The tree should move. The grass should move.
They came up with this idea of a chemistry engine. Let’s take an element like wind, fire, ice, [or] electricity. Not an element, but mix it with a material and see what happens. What happens when you mix two materials?
The way they did that is, they prototyped it in 2D.
Here is one of the project leads owners talking about it.
[Japanese] And it just so happened that we had 2D Zelda character models on hand, so we made use of those. The play style that’s now actually implemented in Breath of Wild initially resonated with our staff particularly because they first experienced it onscreen for that simple, 2D prototype. When we decided to implement in 3D and started to add more and more complexity and tweak scenes for greater impact, we began to realize the tremendous volumes of work that needed to be done. That experiment really showed us how great the title could be, but also the amount of work that would be required to make it.
That experiment showed us how great the title could be, but also the amount of work required to make it. – Hidemaro Fujibayashi
There are two Japanese words you maybe didn’t pick up on. He said “Tegotae kanjiru,” like we were able to feel the tegotae, the hand response. We felt the hand response.
Then he said, “Wakari yasui,” and I think it translated to “the play style was enjoyable,” but the Japanese word is “easy to understand.” I think that’s what we’re all after when we kind of do design, UX, and building our products is “wakari yasui,” easy to understand.
Let’s put this in our brain.
I think, if you can understand your work and share that idea, people will start understanding it, the “wakari yasui.” They will start to easily understand the idea. It’s a lot easier to do in a prototype than right before you launch your product.
An experiment to get estimates, better estimates of the work required, that’s another thing they do. They figured out how much work it was going to take and planned for that.
How we do that at my job is Jekyll. We use a lot of Jekyll. It’s a static site generator. Has anyone used it? Okay. Good. A good amount of hands.
I love it. It could be any static site generator, really anything you want to use. This is just what we use. What I love about it is no database. Yay!
This, from a computery perspective, eliminates so much heartache, so much pain because, when you go to the database and you connect to the database, well, you have a lot of problems. You have security concerns. You have, “Oops, I deleted all the users on the website,” concerns. Don’t do that.
When you prototype outside of the production environment, if you pull it outside of your master branch, or not even the master branch, the master project. If you pull it outside of that, and you work on something, it’s very easy. You feel relaxed and free to kind of experiment.
Just because there’s no database doesn’t mean you can’t have data. This is what I like about Jekyll is I can get a dump of all the products from our database. I can get all of the products from our database, and I can iterate through them in a template language. This template language is so easy. It’s really easy to translate to something like a Java template system or Node, or anything really. This is really easy to translate, but you can experiment with your data inside a static site generator.
Let’s finish with something from Microsoft. It’s a 20-page research paper, which I would like to read in its entirety.
This is a research paper from Microsoft Research, and it’s called What Went Right and What Went Wrong: an analysis of 155 postmortems from game development. [Deep sigh] What’s interesting about this is, okay, video games are a good analogy to what we all do. The average video game has ballooned in complexity and now the average video game is a two-year project to make a video game.
They analyze game development postmortems from Gamasutra. What’s different about the game development postmortems and the startup world postmortems is game development tends to be a little more honest. The startup world is usually, oh, we crushed it, but the world wasn’t ready for our disruption. But game development is a little more honest on the problems that occurred. Here’ a chart and graph of all the problems. There are four big spikes. The biggest one is obstacles. These are things that you don’t expect: somebody’s partner passes away, mental health breakdowns, things of that nature that you don’t expect, kind of general business risks.
The next three are very connected. There’s game design, there’s development, and there’s schedule. The problem here is the game design was overly ambitious, and they designed things that were not easy to create. The development struggled to create the designs. Has that ever happened to anyone? Okay.
Then, because of that, the schedule kept slipping, and people got mad. Then project managers were like, “It has to be out by Christmas!” Then everyone is like, “No way!”
They come up with some conclusions. I highlighted one, and here it is. “Prescribe to an iterative development process and utilize prototypes as a method of proving features and concepts before committing them to your design.” Does that sound familiar? It should. That’s what I’ve been talking about for the last 40 minutes.
Third, don’t be overly ambitious in your design. Be reasonable and take into account schedule and budget. Ooph! That one hurts.
Let’s apply this to our brains.
“Prescribe to an iterative development process, and use prototypes as a method of proving features and concepts before committing them to your design.”
That’s exactly what the paper said. Prescribe to an iterative development process and use prototypes as a method of proving features and concepts before committing them to your design. That’s how we get out of this jam.
I want to talk about valuing prototypes. I think it’s really important to value prototypes. I think we all kind of prototype to some degree, but I don’t think it gets the value that it deserves in our production processes. I feel like, in my experience in digital products, pixels are so cheap. We get locked into this idea that, oh, we’ll just commit to master, or we’ll just ship it. Row, ship it. Ship it, ship it. Agile, ship it.
You get in this cycle where you’re just trying to ship things without doing the right amount of thinking before you go into it. So, I think prototypes are very valuable, not only to your business but also just preventing naïve product decisions from making it to market.
The next point I’d like to make is just that prototypes are for everyone. That example with sketching, your boss can prototype. The lady who makes the lunches at your office, she can prototype. Anyone can prototype in your workplace.
When you have a prototype, and you make it visible in your organization. You don’t hide it away on just your computer, developers.
You don’t hide it on your computer. You share it with everybody, and it becomes a communal thing that everyone can use, everyone can contribute to. It has high visibility.
We’ve actually kind of started sort of a phrase. We like the phrase “prototypes, not PowerPoints,” because, how many times have you been in a meeting where you saw a PowerPoint of something you didn’t know about, and all of a sudden it’s your responsibility to make that, to design it, or develop it, and you’re just like, “Oh, no!”? You see this business idea, and you’re like, “Uh-oh!”
It would be better if you were sitting in the meeting and they came up and they showed a working prototype, or they handed you a phone with a working prototype, and they said, “Here. Try this out. This is kind of what we’re thinking for this new feature.” I think it brings a lot more clarity and a lot more helpful discussions.
I’m actually the jerk in my company. When people are talking about something, I’ll just start building it in a CodePen while they’re talking about it because I don’t want to have a discussion later. I don’t want to JIRA ticket later. I just want to solve it in the meeting.
