I've been thinking about what sketching can teach us about iterative prototyping. Years ago I had the pleasure of working with Lawrence Marvit on a project. Lawrence is an immensely talented illustrator and animator. He brought a bag of differently colored pencils and while we talked about ideas, he sketched. He started with lighter colored pencils, then moved to darker and darker ones as our ideas developed. Only when our ideas were pretty clear did he use a black pencil. It was great. A short period—just a couple of evenings—but one of my favorite collaboration experiences.
It's been almost 10 years since that experience, and thinking back made me realize how frustrated I've been with all of my software/hardware experiences in comparison. Even in the hands of experienced practitioners, the tools just seem limited and limiting. There's much energy spent managing the tool, even when the tool is familiar. So I decided to think about what it is that makes sketching on paper a different prototyping experience and what are the qualities that prototyping tools can aspire to.
I think that there are several things that make drawing on paper particularly good prototyping medium:
- It's fast. You can sketch very quickly and need almost nothing to do it. You can change a sketch quickly by just sketching over what you just sketched. You can make another sketch. These prototypes can communicate an immense amount in a short amount of time. And time is important when exploring ideas. The less time it takes to explore an idea, the more ideas can be explored.
- It's provisional. You know a sketch is not the final product. There are a bunch of indicators that tell you it's not the real thing. The classic visual indicators of a sketch are that lines aren't straight, circles aren't round, and lines go through endpoints, instead of ending cleanly. The nonphotorealistic computer graphics people have been investigating these ideas for a while (another link), but the point is that how sketching looks sends signals that it's not the real thing, so it's easier to keep thinking about the core ideas, instead of being distracted by the details. In consulting, we often have to go to great lengths to communicate the finality, or lack thereof, of our deliverables, and much client-consultant misunderstanding comes from the client thinking something is done, when it's not.
- It's a history. Sketching shows you in one place the record of successful ideas, experiments and failures. You're constantly defining the envelope of what's acceptable and what's not. When you've finally reached a point, you can mark the final version (outlining in ink what has been penciled in, for example), but the history is still there. Jim Dine, the artist, used to erase and abrade his drawings, intentionally leaving a shadow history. History is feedback. It let's you know where to not go again (you know the line about people being doomed to repeat it?).
So if paper is the medium to emulate, how do other prototyping methods stack up? I started writing about how different practices prototype, but I realized that I didn't know enough about each field to do a good job of it. However, that didn't stop me from producing a table that attempts to score media on how easy it is to prototype in them, based on my three criteria. I also included a short list of history media, since I think that's the thing that's most lacking in most prototyping systems. This, too, is a sketch of sorts.
For | Methods | History Medium | Speed | Provisional | History | Score |
Drawing | Sketching | Paper | 5 | 5 | 5 | 125 |
Writing | Drafts | Revisions, Change tracking | 5 | 4 | 3 | 60 |
Architecture | Wireframes, models | Series of models | 3 | 4 | 1 | 12 |
Software | Iterative development | Revision control | 2 | 3 | 4 | 24 |
Screen-level interfaces | Prototyping | Paper, wireframes, Flash, toolkits | 2 | 3 | 1 | 6 |
Interaction design | Flowchart | Series of designs | 3 | 2 | 2 | 12 |
Hardware | Prototyping | Hardware toolkits | 1 | 1 | 3 | 3 |
Music | Rehearsing | Tapes, scores | 5 | 5 | 1 | 25 |
Theater | Rehearsing | Script, Video | 5 | 5 | 3 | 75 |
Information Architecture | Sketching | Series of diagrams | 4 | 2 | 1 | 8 |
(to exaggerate the score sale, I've multiplied the numbers, rather than just adding them)
Part of my agenda in doing this was to understand just how bad prototyping in hardware is—it's really bad, even with all of the new toolkits on the market—and if there are other media that physical computing can learn from when thinking about how to prototype its systems. I'm not sure I have an answer to that yet but I'm starting to think about it, just as I'm starting to evaluate some of the hardware prototyping systems out there to see if I can learn from their thinking.
Here are the ones I know about:
One final thing: after I wrote most of this (and a bunch more, which ended up on the cutting room floor because it makes even less sense) back in July, I discovered that Bill Buxton talked about this very thing in a series of lectures. I haven't been able to find a transcript of what he said, but it's interesting to me that these ideas are appearing now. It says to me that the field is maturing in a way that the constraints of the medium are giving way to the constraints in our abilities to use it creatively and efficiently. Buxton, as always, is in the forefront.
Oh, and there are a bunch more excellent Jim Dine drawings in the National Gallery of Art show. Dine rocks.
A couple more advantages to paper sketching:
- It's easier to gather round a piece of paper than a screen.
- It can be done unobtrusively, during a conversation.
So, to combine those with maximum verbosity... sketching allows easy movement along the public-private continuum. Or something.
You remember Hernando Barragan from Ivrea, perhaps? He created a hardware prototyping language for his thesis project called Wiring. It's based on Processing, the platform developed by Casey Reas and Ben Fry.