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

by Ken Kocienda

There weren’t any company handbooks describing these elements. Nobody outlined this list in a new-employee orientation. There weren’t any signs affixed to the walls of our Cupertino campus exhorting us to “Collaborate!” On the contrary, we felt, on an instinctive level, that imposing a fixed methodology might snuff out the innovation we were seeking. Therefore, our approach flowed from the work. This happened from the top down, stemming from the unquestioned authority and uncompromising vision of Steve Jobs, and it happened from the ground up, through the daily efforts of designers and programmers you’ve never heard of, people like me and my colleagues, some of whom I’ll tell you about.

Although Steve’s opinions and moods could be hard to anticipate, he was utterly predictable when it came to his passion for products. He wanted Apple products to be great, and he insisted on being involved in the process as it went along, to guide the development of the work through his reviews. That’s why I was waiting to show him my demo. He wanted to see my latest progress and then push the work toward his ideal with his feedback and suggestions.

The software we created at Apple was an accumulation of such small details. Steve looked to Scott not only to make these kinds of intuitive leaps himself but also to build and lead a team that could make them in volume.

As they reviewed work, they decided whether a design might pass muster with Steve while also estimating whether Henri’s programming team could implement the idea in a high-performance, bug-free manner given the remaining time in the schedule. They were always wary of showing Steve something he might like but that we might not be able to ship in a product. Scott didn’t run an ivory tower research and development department. Our demos to Steve carried the promise that we could deliver, and since showing work to Steve implied this willingness to commit, very few demos shown for the first time in these earlier meetings proceeded to him without further refinement.

The relation of Diplomacy decision to shipping software also shows how important demos were to us at Apple. Demos served as the primary means to turn ideas into software. The setup of these demo review meetings reveals how we went about making our software great.

This statement includes the assumption that Apple made making great software an important goal to begin with. We did, and that came straight from Steve. He set the company’s priorities, and he stressed, in public statements and internal communications, that making great software was a core corporate focus. What’s more, Steve wasn’t merely interested in paying lip service to this goal. He demanded action, and so the software team produced demos in a steady stream, and whenever there was interesting new work, Steve found the time to attend a demo review so he could see it. His involvement kept the progress and momentum going.

Such hierarchically restricted access to the CEO can’t be too different from what happens with other large companies, but the way to get admission to these high-level meetings at Apple had much less to do with your place on the org chart and much more to do with your ability to make the products better.

He believed that stripping away nonessential features made products easier for people to learn from the start and easier to use over time. He wanted products and their software to speak for themselves.

Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products.

In the same way, software demos need to be convincing enough to explore an idea, to communicate a step toward making a product, even though the demo is not the product itself. Like the movie, demos should be specifically choreographed, so it’s clear what must be included and what can be left out. Those things that aren’t the main focus of a demo, but are required to create the proper setting, must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision.

The Mozilla project leaders had designed a system they hoped would turn their software into components they could snap together like LEGOs. However, this scheme required reams of extra boilerplate code—programmers had to do something like filling out a pile of forms to register new code with this reuse system—and this buried their browser in red tape. Now that we saw the implications of this engineering decision and the resulting 10:1 ratio of Mozilla code to Konqueror code, it seemed obvious that their component notion had gotten wildly out of hand. Mozilla was bloated, unwieldy, and troublesome.

Don and Richard endured this build ordeal along with me, and during lunch and coffee breaks we commiserated with each other about how bored we were. 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.

All this mattered, but I think Edison’s large-scale success was built on a foundation of tending to small details. I would like to turn the discussion back to how Edison himself described his approach for constructing the foundations for his innovative work, specifically, how he solved problems like finding the best filament material for his lightbulb: “None of my inventions came by accident. I see a worthwhile need to be met and I make trial after trial until it comes. What it boils down to is one per cent inspiration and ninety-nine per cent perspiration.”

It may seem like a stretch to draw a comparison between winning football games in Green Bay and developing web browser software in Cupertino, but a significant part of attaining excellence in any field is closing the gap between the accidental and intentional, to achieve not just a something or even an everything but a specific and well-chosen thing, to take words and turn them into a vision, and then use the vision to spur the actions that create the results.

Steve and Scott wanted this new feature. If Apple was going to deliver it, someone had to “sign up” for the work and get it done.

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.

I had succeeded in getting my colleagues invested in my insertion point behavior work, not just by asking for their help in a single meeting and saying thanks when it was finished but by demonstrating through my ongoing actions in code changes, demo reviews, and lunchtime chats that their advice had mattered to me. Getting the insertion point to behave correctly wasn’t just my project anymore. It was now our project.

Even when demos went well, there was always a steady flow of feedback, suggestions for changes, impressions on how the software might behave differently. Everyone spoke up. Demos were an open forum for exchanging ideas about how an interaction might look or function better. When demos went poorly, as sometimes happened, there was the same stream of comments and constructive criticism. There was never any finger-pointing; however, there was an expectation that new demos would include a response to the feedback from previous demos. This was the one essential demo expectation: progress.

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

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.

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. 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.

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.

At Apple, we sought to be as empathetic as possible in both the initial and the ongoing experiences with a product, but we realized we couldn’t try everything during our design and development phase. We needed to whittle down the unbounded possibilities for how a product might look and behave, and to do this, we used our design and technological taste.

I have my own definition of taste, and while it isn’t as profound as Kant’s, it’s a useful tool, like a carpenter’s hammer. Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.

as part of a 2003 New York Times interview discussing the iPod, Steve drove his point home: 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.

In similar fashion, all my experience tells me there’s a fundamental notion about practical inventions, about making a product, and if I had to choose one sentence to pass on through the Feynman void to those who come after us, it would be this: Design is how it works.

A properly judged mixture of taste and empathy is the secret formula for making products that are intuitive, easy to use, and easy to live with.

The appeal of the iPhone wasn’t the result of piling up a bunch of features early on in our project development schedule, opening the requisite number of bugs to track the implementation of those features, and then converging, fixing them one by one as the schedule led us to ship date. Bug squashing might help to make a decent product, but it’s not the secret for making a great one.

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.

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.

Maintaining headway toward a goal was a key part of the way Apple did software development. It’s fair to say we were always in a convergence period of a sort, even though we didn’t think of it in that way. Yet our forward movement always had a destination. We were constantly converging toward the next demo.

The key is man’s power of accumulative selection: nature gives successive variations; man adds them up in certain directions useful to him . . . It is the magician’s wand, by means of which he may summon into life whatever form and mould he pleases.

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. Detached high-level managers making all the key decisions is such a widespread affliction that it has its own internet meme, the Seagull Manager. It describes a top executive who is rarely around but flies in occasionally and unexpectedly from who knows where, lands on your beach, squawks noisily, flaps its wings all over the place, launches itself back into the air, circles overhead, drops a big poop on everyone, and then flies away, leaving the rest of the team to clean up the mess, figure out what it all meant, and wonder what to do about the inevitable follow-up visit.

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.

You could build and release products without ever living on them to see if they’re any good, as we did with Nautilus and our online services at Eazel. You could hold demo meetings and then adjourn them without deciding what to do next, a mistake that interrupts the chain of criticism that provides the logical connection from demo to demo. You could assign oversized project teams to the tasks one or two people could handle, a fault that can lead to muddled communications and a dilution of each person’s ability to make a difference. You could have conflicting lines of authority and fail to ever reach universally recognized final decisions. You could design for looks, or for fashion, or for some abstract ideal instead of designing for how a product works. You could stage A/B tests to help make simple decisions, as was done, apparently, to choose colors at Google.

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.

He had a conviction about the iPhone in that moment; I only had hopes for it.

It’s difficult to maintain a wider perspective in the midst of making; you have to make sure each individual demo feedback and response cycle eventually adds up to something more.

“The Intersection,” the title of this chapter, was an idea that helped us. It speaks to the way Apple valued expertise in both technology and liberal arts.

Steve Jobs told everyone what he thought about this topic himself, on stage, during the keynote presentation to announce the original iPad: 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.

We used algorithms and heuristics like they were the left and right sides of our collective product development brain.

Our goal was comfortable technology and computer-enabled liberal arts, a combination of both.

1. 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 2. 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 3. 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 4. 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 5. 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 6. 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 7. Empathy, which means trying to see...

No detail is too small. This brings me to the third part of my answer. After creative selection and the seven essential elements, we needed one more intersection to make great work: a combination of people and commitment.

Creative selection and the seven essential elements were our most important product development ingredients, but it took committed people to breathe life into these concepts and transform them into a culture. The culture we created is inseparable from the products we created. In my experience, this manner of culture formation works best when the groups and teams remain small, when the interpersonal interactions are habitual and rich rather than occasional and fleeting. The teams for the projects I’ve described in this book were small indeed. Ten people edited code on the Safari project before we made the initial beta announcement of the software, and twenty-five people are listed as inventors on the ’949 Patent for the iPhone.

So, here’s my take on the Apple Way, our recipe for making software for products like Safari, WebKit, iPhone, and iPad, my explanation for how we made great products: A small group of people built a work culture based on applying the seven essential elements through an ongoing process of creative selection. Expanded out, it reads like this: 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.