Prototyping Magic Tricks and Software

In Penn & Teller’s Masterclass (no. 12 “Principles of Performing”) they explain how one of their favorite ways to design a magic trick is to come up with an idea and then act it out as if they already know how to do it. Here’s Penn:

We still start with an idea for a trick, how we want the whole thing to go without knowing how we’re gonna do it…Some of our best tricks have come from [this way of designing a trick]. [We like to] do the trick as though we didn’t have to do any trick. Just walk through it. Just go out there like the trick is going to work…We want to go out, have a card selected, know what it is, put it down, have a knife go through Penn’s hand, and there’s the card with blood coming down. Let’s just do that, like theater. Let’s just go through and act it.

To borrow parlance from digital design work, I would call this “prototyping a magic trick”.

The beauty of this approach, which Penn points out, is that you uncover aspects of the design of the trick by acting it out (hint: that means it’s “design” work).

For example, during the trick you may need to stealthily conceal something. It could be really hard to think about when and how you’re going to fit that into the trick. But, if you just start acting the trick out, you may discover that at a particular moment in time during the trick your hand naturally goes into your pocket. Eureka! Now you don’t have think about when and how you’ll conjure a moment for concealing, as you’ve instead uncovered how and when it falls naturally into the act.

Similarly, you may think you need something in the trick like a particular moment in time to shuffle the deck. And you could spend a lot of time thinking about how and when you’ll fit that in. But, as Penn notes, if you just start acting it out like theater (as if the trick worked) you may discover that there’s no need to shuffle the cards at all — in which case you’ve solved the problem by simply eliminating it.

So by acting out the trick, as if it worked, you discover things along the way you wouldn’t have thought of. And that discovery then informs the design of the trick.

This is the value of prototyping: you don’t have to figure everything out beforehand. You pick a place to start and let the natural process of problem solving birth the design of what you’re trying to make.

We think we can: 1) define a problem, 2) design a solution, and 3) implement it.

But the truth is: it’s difficult to define a problem without also beginning to solve it. “Implementation” is part of the problem definition phase — that’s why teams that go “define -> design -> implement” inevitably find things they couldn’t anticipate which then pushes back timelines because they thought they were almost done.

You have to start working on problems to fully understand them — and prototyping is a beautiful way to do that.