The Power of Prototypes in the Creative Process

As mentioned on this blog, I recently finished reading Ken Kocienda’s book “Creative Selection”.

One of the things Ken frequently reiterated throughout the book dealt with the power of prototypes in the creative process. According to Ken, a big part of Apple’s success with the original iPhone (codenamed “Project Purple”) as well as other products lay in the prototype-driven process that creates them.

Exactly how we collaborated mattered, and for us on the Purple project, it reduced to a basic idea: We showed demos to each other. Every major feature on the iPhone started as a demo, and for a demo to be useful to us, it had to be concrete and specific. We needed concrete and specific demos to guide our work, since even an unsophisticated idea is hard to discuss constructively without an artifact to illustrate it. (153)

An illustration of this:

Think of a cute puppy. Picture one in your mind. Close your eyes if you need to. Make the image as detailed as you can. Take a moment. A cute puppy. Got one? I do too, and I did well. In fact, I think my puppy is cuter than yours. Consider the scenario. Two people have imagined two cute puppies. I assert mine is cuter. What do we do now? Do we have a cuteness argument? How can we? We have nothing to go on. Do I try to describe the puppy in my mind and attempt to sway you that my vision of a golden retriever puppy is superlatively cute—because everyone knows that golden retrievers are the cutest of all dog breeds—and therefore, my conjured mental picture is unbeatably cute. Do you try to make a sketch on a whiteboard of the puppy you’re thinking of but then apologize because you’re a lousy artist, so I’ll just have to take your word for how cute your puppy really is in your mind? Let’s say you’re my manager. What do you do now...pull rank? (155)

This resulted in:

Demos were the catalyst for creative decisions, and we found that the sooner we started making creative decisions—whether we should have big keys with easy-to-tap targets or small keys coupled with software assistance—the more time there was to refine and improve those decisions, to backtrack if needed, to forge ahead if possible.

So why doesn’t everyone do this all the time?

Making demos is hard. It involves overcoming apprehensions about committing time and effort to an idea that you aren’t sure is right. (156)

It’s worth noting we’re not talking about just creating hundreds of unrelated demos because every team member is just scratching an itch for something they’re personally interested in. Rather, the foundation for all these prototypes was the product and design vision.

Without a person at (or near) the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions...Without conviction, doubt creeps in. Instincts fail...When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision (212)

I really love his point about data becoming a crutch for every decision. Data can help you produce a button whose color is most conducive to getting people to click on it (narrow) but it can’t product a coherent, cohesive product that feels like an “integrated whole”. Ken explains:

In this kind of test, commonly referred to in the high-tech industry as an A/B test, the choices are already laid out. In this Google pick-a-blue experiment, the result was always going to be one of those forty-one options. While the A/B test might be a good way to find the single most clickable shade of blue, the dynamic range between best and worst isn’t that much. More important, the opportunity cost of running all the trials meant there was less time available for everyone on the development team to dream up a design that people might like two, or three, or ten times more. A/B tests might be useful in finding a color that will get people to click a link more often, but it can’t produce a product that feels like a pleasing and integrated whole. There aren’t any refined-like responses, and there’s no recognition of the need to balance out the choices. Google factored out taste from its design process. (213)

Factored out “taste”? What is that?

Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole. (183)

How Apple was different:

At Apple, we never would have dreamed of doing that, and we never staged any A/B tests for any of the software on the iPhone. When it came to choosing a color, we picked one. We used our good taste—and our knowledge of how to make software accessible to people with visual difficulties related to color perception—and we moved on. (213)

The tricky part is to not get too bogged down in the details or the grand vision. Take your time, when needed, but always make steady progress. Ken said “Maintaining headway toward a goal was a key part of the way Apple did software development” (214). Everything they were doing was constantly converging towards the next demo session where they would show their prototypes, gather feedback, and iterate again.

We habitually converged on demos, then we allowed demo feedback to cause a fresh divergence, one that we immediately sought to close for the follow-on demo. (214)

This was, in essence, their “process”:

We were continuously producing fresh rounds of software like this, to test our latest ideas and assumptions. As a whole, a succession of demos, feedback, and follow-up demos created a progression of variation and selection that shaped our products over time. (214)

It was a kind of “Darwinian” software development. It was—dramatic pause before inserting the name of the book—“creative selection”:

As best we could on the Purple hallway, we sought to wield a similar magician’s wand to mold our products, building variation into our demos, keeping the strong aspects and discarding the weak, and making the next demo based on those decisions. With our Darwinian demo methodology, we had a huge advantage over artificially selecting breeders and the glacially slow accumulations of genetic improvements that drive natural selection. Working in software meant we could move fast. We could make changes whenever we wanted, and we did. We created new demos that were concretely and specifically targeted to be better than the previous one. We constructed Hollywood backlots around these demos to provide context and to help us suspend our disbelief about the often nonexistent system surrounding the feature or app that was the focus of our attention. We gave each other feedback, both as initial impressions and after living on the software to test the viability of the ideas and quality of the associated implementations. We gathered up action items for the next iteration, and then we forged ahead toward the next demo. I’ve given a name to this continuing progression of demo -> feedback -> next demo: creative selection. (215)

It’s all about “the steady accumulation of positive change“ (217). Round after round towards the goal:

We always started small, with some inspiration. We made demos. We mixed in feedback. We listened to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another and then another. We improved our demos in incremental steps. We evolved our work by slowly converging on better versions of the vision. Round after round of creative selection moved us step by step from the spark of an idea to a finished product. (218)

Apple never thought about an algorithmically correct color. They used their taste.

At Apple, we never considered the notion of an algorithmically correct color. We used demos to pick colors and animation timings, and we put our faith in our sense of taste...We developed heuristics. (242)

And how did they develop heuristics?

[we] always made demos to evaluate the possibilities. I would often sit down with an HI designer...to make preliminary decisions about gestures and animations, then we would review our preliminary choices in larger groups, then the whole team would live on the results over time. We used the same scheme to develop heuristics for the whole system. (241)

This entire process is how they went from an idea to a product. It was like a snowball rolling down a hill, accumulating positive change demo after demo after demo:

When we got an idea, we cobbled together a first cut on the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources—code, graphics, animations, sounds, icons, and more—to produce a demo. After we showed the demo and shared some feedback with each other, we made decisions about changes that might be an improvement. Many times this came down to tuning some heuristic, or modifying how an algorithm and heuristic combined. Whatever it was, the concrete and specific modifications we chose to make led to the actions items that justified making the next demo. Repeat, then repeat again. Doing this over and over again set our projects on the slow path to accumulating positive change. This is how we started with an idea and finished with software for a product. (246)

As he summarizes at the end of the book:

A small group of passionate, talented, imaginative, ingenious, ever-curious people built a work culture based on applying their inspiration and collaboration with diligence, craft, decisiveness, taste, and empathy and, through a lengthy progression of demo-feedback sessions, repeatedly tuned and optimized heuristics and algorithms, persisted through doubts and setbacks, selected the most promising bits of progress at every step, all with the goal of creating the best products possible. (252)