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

by Ken Kocienda

Yet we never thought about such big numbers. We were too busy focusing on small details.

you’ll see that working in the Apple style is not a matter of following a checklist.

I got feedback on the autocorrect feature from just a few dozen people before the whole world got a crack at it.

In the years since, I’d seen him demonstrate his calmness again and again. In the lead-up to a Steve demo, he could be counted on to keep his composure and smile through the tension. Henri acted as a buffer between his team of programmers and the company’s hard-to-please leaders. He edited expletives out of the executives’ requests before passing them down to individual coders. He might say to me “I just heard Steve reported a bad bug.” The actual message he’d received had been more like: “THE F***ING CAPS LOCK BUTTON DOESN’T WORK IN TODAY’S BUILD! DON’T YOU PEOPLE TEST THIS F***ING KEYBOARD?!” As Henri sifted through and related the details at such times, I appreciated his ability to project the confidence that everything would work out. He seemed to know that applying pressure on me wouldn’t help me figure out the fix for the bug any faster but that I would drop whatever I was doing and get right on it. In his way, Henri filled a role created by the personality of our intense CEO. He was a source of coolness that prevented us from constantly getting burned by Steve’s searing heat.

VP software

Scott, Henri, Greg, and Bas wouldn’t have earned their place in Diplomacy unless they had a well-tuned sense of when it was best to say nothing.

Richard Stallman didn’t favor. Stallman wanted code to be free as a political and social good. His notion was for software to be “free as in freedom.”4 For Netscape, open source was an attempt to save the company from going under. It was making its source code “free as in beer.”5 The hope was to earn money by running the best beer bash.

Even as I write, but perhaps more so in the early 2000s, programmers are predominantly youngish men just a few years out of college, geeks who gulp caffeine to fuel long hours of coding, often against impossibly tight delivery schedules. When tired and short on time, tempers flare, immaturity clobbers professionalism, and disputes, technical or otherwise, come out in the software.

a representative example of inappropriate language in source code might be: cleanUpBobsSh_tStormHeIsAF__kingTurdBlossom();

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.

We couldn’t fob this work off on junior programmers or interns either. Apple didn’t work like that. Secrecy was one reason, but, more important, Apple didn’t separate research and development from software implementation. We were responsible for coming up with the ideas for our web browser and writing the shipping code that went out to customers too.

Knuth is the consummate craftsman. Here’s what he has to say about optimization: Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.2 (Emphasis added.)

In later years, I would learn more about how Steve prepared for these big-splash product announcements. Three weeks or a month before the keynote itself, Steve would start rehearsing with portions of his slide deck in some venue at Apple, often in Town Hall, the auditorium on the Infinite Loop campus. Slowly, day by day, he would build the show by stepping through it as he wanted to present it at the keynote. This was one of Steve’s great secrets of success as a presenter. He practiced. A lot. He went over and over the material until he had the presentation honed, and he knew it cold.

The closest term we had in the Apple lexicon was more management speak: directly responsible individual (we pronounced it as D-R-I in conversation), the person who has to do whatever is necessary to develop a piece of hardware or software, some technology, some critically needed thing—the DRI was the person with their butt on the line.

Williams asked Steve where he “fit in the American family of thinkers and inventors.” At first, Steve attempted to brush off the question, but when Williams pressed him, 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.”

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.

The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.

At Apple, we built our work on this basic fact. Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next. 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. Concrete and specific demos were the handholds and footholds that helped boost us up from the bottom of the conceptual valley so we could scale the heights of worthwhile work. Making a succession of demos was the core of the process of taking an idea from the intangible to the tangible.

Making demos is hard. It involves overcoming apprehensions about committing time and effort to an idea that you aren’t sure is right. At Apple, we then had to expose that idea and demo to the scrutiny of sharp-eyed colleagues who were never afraid to level pointed criticism. The psychological hurdle only grows taller with the knowledge that most demos—almost all of them—fail in the absolute, dead-end sense of the word.

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.

It was hard to orient ourselves—the touchscreen text entry landscape didn’t exist yet. Yet that’s what innovation opportunities look like. The field was wide open, so, when any of us had a new concept for a keyboard, we made a demo to communicate what we were thinking. Literally, we had to demonstrate our idea. We couldn’t get away with telling. We were required to show.

We had to work like this, because the team didn’t accept anything unless it was concrete and specific, a demo showing what we meant. Then we tried out each other’s demos, said what we liked and what we didn’t, and offered suggestions for improvements, which led to more demos and more feedback.

This kind of collaboration was common. The programmers and designers on the Purple project were in and out of each other’s offices all the time. We exchanged frequent feedback on our work, and all of us were expected to field questions on our specific area of development.

Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones.

There’s a common high-tech term for a daily regimen of using and evaluating your own product while you’re trying to develop it: dogfooding. I never liked this term myself, and it didn’t appeal to Apple sensibilities either. Pet food isn’t typically thought of as a pinnacle of product development. On the Purple hallway, we were trying to make excellent products for people, and while we sometimes said “dogfooding” inside Apple, more often, and more officially, we began to say “living on” to describe the day-to-day routine of living on our in-progress software like it was a real product.

philosopher: “The judgement of taste itself does not postulate the agreement of everyone (for that can only be done by a logically universal judgement because it can adduce reasons); it only imputes this agreement to every one, as a case of the rule in respect of which it expects, not confirmation by concepts, but assent from others.”6

Yet when it comes to making products, philosophical discourse is the wrong tool for the job when practical decisions are needed.

It’s important to keep making progress and to keep sight of priorities.

recognized I’m not a philosopher myself; I’m closer to a carpenter. As a maker of products, I always turned less to the theoretical and more to the applied.

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

Developing the judgment to avoid this pitfall centers on the refined-like response, evaluating in an active way and finding the self-confidence to form opinions with your gut you can also justify with your head.

Building trust in a personal refined-like response takes time and practice. It also requires a measuring stick. Studying great work from the past provides the means of comparison and contrast and lets us tap into the collective creativity of previous generations.

When I study the past, I make a point of deciding what I like, and sometimes this built-up catalog of refined-like responses about past works finds a suitable outlet and a natural expression in my present-day work.

On one side, the refined-like response is often a local determination made either early in a design process or at the specific moment of a demo. It often takes the form of “I like this animation since it helps to direct the user’s attention appropriately,” or

The small-scale justifications must contribute to a scheme larger than themselves.

Most people make the mistake of thinking design is what it [a product] looks like. People think it’s this veneer—that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.

His message is clear, and I agree with it. Shallow beauty in products doesn’t serve people. Product design should strive for a depth, for a beauty rooted in what a product does, not merely in how it looks and feels.

We found we had to add a complete collection of hate speech to the dictionary and explicitly mark those words to prevent the software from ever offering them as autocorrections—imagine trying to type “nugget” but narrowly mistyping the first vowel or the last consonant. We didn’t want to offer racial epithets as a “helpful” aid, and we resolved that we would never provide software assistance for attempts to slur or demean.

Did we feel pressure to fill gaps like these in our system? Yes. I handled it by keeping reasonable and regular work hours. If I wasn’t battling exhaustion, I could bear up under the stress.

Navigator web browser, the goal wasn’t zero bugs. Netscape’s engineering leaders knew that no sophisticated piece of software was ever truly devoid of defects. Instead, they shot for zarro boogs, an intentional mispronunciation of “zero bugs.” It was a humorous recognition that they were calling their project “finished” on the ship date, not that they had actually achieved the unattainable ideal of fault-free code, regardless of what a bug database query or a convergence graph might have shown them.

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

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.

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.

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.

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.

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.

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,

We didn’t have an imbalance between influence and involvement, where a senior leader might try to mimic the commanding role of Steve Jobs without the corresponding level of personal engagement.

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.

From its beginnings, Apple always had a characteristic sense of what to select for, a viewpoint on which ideas were strong, and this helped to define the conditions under which the creative selection process unfolded.

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.