The Garage Experience

We assume that coming into this class you have already given thought to prototyping and MVPs in conjunction with setting your "Deliverable 0" Milestone OKRs. What we want to accomplish in this workshop is two fold. First we want to jumpstart the process of actually building that first prototype, advocating for sooner rather than later, and more rather than fewer iterations between now and the next milestone. Secondly, though, we want to stretch our senses of the motivations for and the forms of prototyping.

The workshop will start with a brief lecture introducing some concepts and principles and a menagerie of species in the genus prototype. Next we will each work out the relationship between what we know, think we know, know we don't know, and don't know we don't know and our need to prototype. Finally, we will design a range of prototyping exercises that make sense for our project being sure to stretch the idea of "makes sense for" to its extremes.

Preamble

In the next phase of the course we want to make something. But why? Getting the why right is a critical part of this exercise being a useful one.

It's easy, when doing an IDEO-style design thinking exercise, to have prototyping devolve into little more than getting people who were in kindergarten a long time ago to rediscover the mental playfulness that comes with unselfconsciously doing things with one's hands. That is, arguably, a very worthwhile learning outcome of such exercises.

But is that all there is? How, in a pedagogical context, can we ensure that a little making is more than an opportunity for designers to watch non-designers pretend to be designers?

EXERCISE 1:

IDEO's Take

We can allow our starting point to be IDEO since that's a strong association for many people these days. For IDEO, the motivations behind prototyping are "make it" (a bias toward action), "learning from failure" (our idea gets better when we see it's failure to serve user needs), and "iterate, iterate, iterate" (our conviction that the quality of solutions is best ensured by repeated cycles of learning and trying).

In connection with this latter, an observation from my friend Eviatar Zerubavel. In his book, The Clockwork Muse - and let's do stop for a second to think about what that title conveys: the juxtaposition of rational, measured, recorded, regularity AND the magical irrationality of pure inspiration. One take-away from the book is advice to write in drafts - starting with a zeroth draft OF THE WHOLE BOOK, first chapter to last. Even if many of them are sketchy, poorly written, under-researched.

WHY? Because it's important to keep a synoptic view, even if it's fuzzy and out of focus. AND because you get smarter as the project proceeds. If instead of this all the way through rough draft you perfect chapter one before you start chapter two, your project falls prey to the problem that the designer of chapter one is a different designer than the designer of chapter twelve. AND perhaps most importantly iterating, or rewriting, a chapter is INFINITELY easier than starting one from scratch. The latter approach is much more likely to be strewn with roadblocks that delay the project in the extreme.

Finally, and we'll mention this again later, this approach permits repeated experience of SMALL WINS which has been proven to be crucial to maintaining creative momentum.

EXERCISE 2:

Bret Victor's Wisdom

A creator should be able to see what she is doing. I find the most powerful expression of Victor's insight is the discussion of what happens when we code. The best coders are the ones who can imagine what the computer is going to do in response to each line or block of code. In effect, the creative act of coding involves simulating a powerful computer in your head. But you have a powerful computer sitting right in front of you - why waste all that cognitive horsepower simulating it?

Victor goes on to show us some software tools that allow people who create with code to dispense with simulating computers in their heads. I take the idea a step further. Whenever we are creatively conjuring up some solution to a real problem we are simulating in our heads the world and the users of our solution. We can debate which one is more complex and whether simulating a powerful computer or the real world represents a bigger cognitive load, but the principle is the same: why simulate the world when it is sitting right in front of you?

But how about "WHY?" in the sense of what are we trying to accomplish?

Prototyping is about answering questions and discovery. And it's about answering a whole bunch of different kinds of questions.

Connecting Prototyping to Research

In our research phase we considered a matrix, one dimension of which was levels of knowing and the other dimension of which was functional areas (users, markets, resources, and technology). At the four levels of technology we asked different questions:

1. Why do we believe the things we think we know?
2. How can we test the things we think we know?
3. How can we find out the things we know we don't know?
4. What are we missing?

The last question is basically impossible to answer with thinking alone. Even carefully constructed experiments may not help. It is the realm of prototyping pure and simple. You have to give the world an opportunity to talk to you.

In extending our research into prototyping, we push ourselves to ask questions that demand prototypes to be answered.

Prototyping Things that We Know

1. What prototype can you build that will help align team members and stakeholders about the idea?
2. What prototype can you build to better understand the value of your idea?

Prototyping Things We Think We Know

This is the easy one - our knowledge here is in the form of hypotheses that we need to confirm or disconfirm.

1. What prototype can you build to test your most basic assumptions?

Proof of Concept. What would you need to build to show you that your underlying concept is correct? Sometimes this means building enough of a mockup that we can see you are not fantasizing. It might mean figuring out how to demonstrate that people really would put on this thing you are planning to produce. Or it might mean showing that you could produce a thing that does what you want, even though the prototype is too big, too heavy, or too ugly.

1. What prototypes do you need to build to convince yourself that your technology is feasible?

Stepwise Refinement. Sometimes we have no idea how to build the thing we have in mind. It's just too complex to make a plan, to draw up a parts list, to draw blueprints we can give to a builder. In these cases we need to prototype by stepwise refinement.

1. Identify 3 likely "forks in the road" that you might be able to answer only, or best, by prototyping some aspect of "your thing."

Exploring the Unknown. Sometimes we know that we don't know how the thing would work under water or we know we don't know whether our service would be found legal or we know that we don't know whether plastic parts would work. In these cases we build prototypes to see how various materials and configurations perform or we figure out how to get a framework in front of an audience to see how they will react.

Prototyping the Things We Know We Don't Know

Prototyping here comes in a few different flavors.

Workshop Guide

1. Write a script for acting out a service interaction prototype for your project.
2. Make a "our thing" among "the other things" prototype menagerie.
3. If your thing were to come in a box, what would the box look like? What's in the box?
4. How would you build an environment prototype for your thing?
5. A physical prototype that will help to evaluate the FORM of your thing.
6. A physical prototype that will help to clarify the FUNCTIONALITY of your thing.
7. A physical prototype that will help to clarify the USABILITY of your thing.
8. A physical prototype that will help surface TECHNICAL challenges in your thing.

For more on Bret, see [http://worrydream.com].
Moggridge, Bill. Designing Interactions]
This is Service Design

[[iframe width="750" height="600"]]