Creative Selection Inside Apple's Design Process During the Golden Age of Steve Jobs

Highlights

In the years since Richard showed me his browser demo, I’ve emulated his approach. When I make a demo, I think about the intended audience, and I make a specific decision about what features to include. I draw a conceptual ring around those key details, and I use a thick imaginary marker to do it. The demo points inside the ring are the focus, and like the lamppost in the movie scene, I depict them with the highest fidelity. I leave outside the ring other less important details that will eventually have to be addressed, but not immediately. I pay them as little attention as possible. Like the inside of the hat shop, I omit them from the demo if I can get away with it. I take extra care at the boundary. Some elements are right on the thick imaginary line, details that need some attention, since they help to set the scene and get my audience to suspend their disbelief.

▶ 0:07

Over time, Don and I began to understand and absorb the model Richard showed us. Look for ways to make quick progress. Watch for project stalls that might indicate a lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make demos. We learned all this from Richard. He changed the way we worked.

▶ 0:57

Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”

▶ 1:30

When Scott arrived to see keyboards on demo day, everyone on the software team was gathered in the main Purple team conference room, which was called Between. Across the hall, there were two other rooms: A Rock and A Hard Place.

▶ 1:42

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.

▶ 1:56

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. Here’s an example: 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? The scenario is ridiculous. There’s no way to resolve this conflict. Without a concrete and specific example of a cute puppy, there’s no way to make progress. Now, I can make this easier. Here are pictures of two cute puppies. Now we can talk about the merits of these options. I can make my case for the cuteness of the golden retriever on the left. You might favor the lovable bulldog and attempt to persuade me that the dog-smiley happy face and single flopped-over ear make it cuter. I might argue back, pointing out the extraordinarily cute way the retriever’s paws are buried in the not-so-tall grass. If we weren’t satisfied with these two choices, we could search the web for countless others.

▶ 2:14

We didn’t do this on the Purple project. We rarely had brainstorming sessions. I recall only a few times in my entire Apple career when I stood around to rough out big plans at a whiteboard. Even when it did happen, as in my story from chapter 3, when we hashed out the porting strategy for our web browser project, we chatted, sketched, and came to our decisions as quickly as we could. If brainstorms run longer than an hour or so, or if there are more than a handful of people in attendance, or if they’re a common occurrence, they can devolve into a form of sneaky procrastination. Whiteboard discussions feel like work, but often they’re not, since it’s too difficult to talk productively about ideas in the abstract. Think of a cute puppy.

▶ 4:04

Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all. This worried me because, as matters stood, my derby-winning keyboard might wipe the smile off someone’s face on International Talk Like a Pirate Day. On that holiday, my keyboard had to deliver on Arrr!, not cause people to give up in frustration, exclaiming “Argh!”

▶ 4:49

Convergence was the term we used to describe the final phase of making an Apple product, after the features had been locked down and the programming and design teams spent the last three or four months fixing bugs and polishing details. Entering a convergence period was the moment we had a clear picture in our minds about how we wanted our finished software to work. It also meant that the hardest part was over—we had been largely successful in navigating the course from idea to product.

▶ 5:24

For this I turn to Douglas Bowman, a designer with a résumé that includes stints at Twitter and Wired. He also started at Google in 2006, becoming one of its early visual design leaders.* Here’s how he justified his departure from the web search firm almost three years later: 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 . . . Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better.3 Forty-one shades of blue sounds like a lot, but if they were willing to go that far at Google, why not test for a hundred or a thousand? If some data is good, more must be better, right? As Bowman suggests, it isn’t.

▶ 5:50

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.

▶ 7:03

There are innumerable ways creative selection can become bogged down, since this working method must be applied consistently over a period of time to yield results. Consequently, our success was as much about what we didn’t do as what we did. Mostly we avoided falling into any of the typical product development traps common in Silicon Valley and that, I expect, occur often in other kinds of creative organizations and businesses. For example, we didn’t take two-hour coffee breaks or hold daylong offsite confabs to talk about projects without examples to ground the discussion—we didn’t have lengthy discussions about whose imaginary puppy was cuter. We didn’t shuffle around printed specifications or unchanging paper mock-ups for weeks on end, waiting for an epiphany that would jump us directly from an early-stage concept to a complete product design, hoping we could somehow flip the ratio of inspiration to perspiration Thomas Edison spoke about, the relationship between the time it takes to get an idea and the amount of hard work it takes to transform that idea into something real. I learned my lesson on this count, and in my Apple career, never again did I spend a week of my time to make anything like that fifty-step Building the Lizard document I described in chapter 2.

▶ 7:16

We didn’t establish large, cutting-edge software research departments sequestered from, and with a tenuous connection to, the designers and engineers responsible for creating and shipping the real products. Steve Jobs famously disbanded such an organization at Apple, the Advanced Technology Group, shortly after he reasserted control over the company in 1997.

▶ 8:30

We managed to steer clear of all such pitfalls. If I were to take a stab at explaining the why, I would say that our clarity of purpose kept us on track, in much the same way that Vince Lombardi won football games and Steve Jobs pushed us to make a speedy first version of Safari. Since our focus on making great products never wavered—if for no other reason than that’s what Steve demanded—perhaps concentrating keenly on what to do helped us to block out what not to do.

▶ 8:52

The reason that Apple is able to create products like the iPad is because we’ve always tried to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users. The users don’t have to come to them, they come to the user.

▶ 9:21

The results of Scott’s game showed that if we placed a box on the screen that was fifty-seven pixels square, then we could put it at any location—high, low, left, or right. If we did that, then everybody could tap the box comfortably, with near 100 percent accuracy. Scott’s game gave us the answer we were looking for. The tap targets for home screen icons on the original iPhone were fifty-seven pixels square.

▶ 9:44

This is what working at the intersection is all about. These examples should clarify why we always made so many demos. The photo-swiping example, in particular, should explain why you can’t “engineer” a product in one phase and then slap on “look and feel” in another. It was often difficult to decide where an algorithm should end and a heuristic should take over. It usually took us many design and programming iterations to evaluate all the relevant options. The best solutions were an accumulation of small decisions carefully weighed against each other as we sought to tame the complexity of so many compounding and overlapping factors.

▶ 10:13

Inspiration, which means thinking big ideas and imagining about what might be possible, as when Imran saw how smooth finger tracking would be the key to people connecting to iPhone experiences through touch Collaboration, which means working together well with other people and seeking to combine your complementary strengths, as when Darin and Trey helped me make the insertion point move correctly in WebKit word processing Craft, which means applying skill to achieve high-quality results and always striving to do better, as when the Safari team made the web browser faster and faster by running the Page Load Test, trying to understand what this test program told us about our software, and using these findings to optimizing our code Diligence, which means doing the necessary grunt work and never resorting to shortcuts or half measures, as when we persisted through the tedium of fixing cross-references to get Safari to build in the lead-up to the Black Slab Encounter Decisiveness, which means making tough choices and refusing to delay or procrastinate, as when Steve Jobs made me pick the better keyboard layout for the iPad on the spot while he waited rather than just offering the two different designs Bas and I developed Taste, which means developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole, as when we made the choice to offer a QWERTY keyboard layout for the iPhone Empathy, which means trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs, as when Scott Herz made a game to find the best size for touch targets so it was comfortable to tap the iPhone display and accommodated people with varying levels of dexterity

▶ 10:51

How much decisiveness did it take for Greg Christie to declare that I should go back to single letters per key for the QWERTY keyboard? Such questions miss the point: We tried to be tasteful and collaborative and diligent and mindful of craft and the rest in all the things we did, all the time. Everything counts. No detail is too small.

▶ 12:30

The communication paths among our few team members became well traveled, and these tracks became like ruts in a road, easing the journey to our desired destinations. We always tried to reach those destinations as quickly as we could, with a minimum of dithering and delay. This last point speaks to the first important lesson I learned about product development at Apple, the revelation that results could be achieved more quickly than I had previously thought. Richard’s initial web browser demo demonstrated to me how to get moving on a project, how to marshal inspiration, craft, decisiveness, and taste, and how to kick off a progression of creative selection. From the moment Don and I saw Richard’s crystal ball version of Konqueror, we were willing to invest ourselves in the Apple-style get-it-done product development culture.

▶ 12:50

It’s customary practice in the high-tech world to use paper drawings and cut-outs as prototyping tools when designing and developing software. One of the prime arguments in favor of paper prototypes is that they’re quick to make. On the Purple project, we didn’t use them. The simplest explanation I can offer is that the low fidelity of paper prototypes made it too difficult for us to evaluate how an app or interaction would work in a multitouch system. I honestly think this direct manipulation demonstration by Imran is the only meaningful paper demo ever done for the original iPhone.

▶ 13:40