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

by Ken Kocienda

I have identified seven elements essential to Apple’s software success: Inspiration: Thinking big ideas and imagining what might be possible Collaboration: Working together well with other people and seeking to combine your complementary strengths Craft: Applying skill to achieve high-quality results and always striving to do better Diligence: Doing the necessary grunt work and never resorting to shortcuts or half measures Decisiveness: Making tough choices and refusing to delay or procrastinate Taste: Developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole Empathy: Trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs

we moved forward, as a group, in stepwise fashion, from problem to design to demo to shipping product, taking each promising concept and trying to come up with ways to make it better.

Whenever Steve reviewed a demo, he would say, often with highly detailed specificity, what he wanted to happen next. “Add more space between these two elements,” or “Replace the green in this graphic with blue,” or “None of this is working. Show me more options next time.”

More generally, he was always trying to ensure the products were as intuitive and straightforward as possible, and he was willing to invest his own time, effort, and influence to see that they were.

The people sitting with Henri on the couch were the true software development inner circle. They were the few Steve wanted around him to advise, consult, and bounce ideas around as he reviewed demos. They had done this for the iPhone, and now they were there for the iPad too. Each person had earned their place, and kept it, by consistently providing feedback that helped make the products better.

Steve valued Scott’s ability to imagine how new technologies might be integrated into our software products. Scott excelled at making these connections. If a programmer told Scott about an in-the-works software change to the touchscreen system that would make it possible to reliably differentiate between quick swiping gestures and slower panning gestures, Scott could visualize a user feature like swiping on an item in a list, say an email message, to delete it.

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.

He set the company’s priorities, and he stressed, in public statements and internal communications, that making great software was a core corporate focus.

Decisiveness was crucial throughout. At the pre-Steve level, Scott was the executive editor. He was the “decider.” Every Apple demo review had a decider, the person with the sole authority to approve or not and the prerogative to declare what would happen next.

Yet, even before formal reviews—say in a meeting between relatively experienced contributors like Bas and me—each of us could decide about our own portions of the work and whether we were willing to exert the effort and hours needed to pursue a new idea or make an additional refinement.

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.

This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry.

Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.

Bas never expressed any disappointment over his zoom animation getting deleted either. Seeing good work wind up on the cutting room floor was part of the job.

Demo reviews were also part of Steve’s effort to model the product development behaviors he wanted us to use when he couldn’t be present.

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.

Since people would be able to download Nautilus for free once we finished it, the company had to figure out some other way to make money. Not surprisingly, this involved creating proprietary software that Eazel could charge people to use: a set of proto-cloud services, including automatic software updates and online file storage. These cloud services would live in an Eazel data center and would not be free. The idea was to integrate Nautilus with these services and position our no-cost software as a lure to draw people to Eazel’s pay-to-use features.

When tired and short on time, tempers flare, immaturity clobbers professionalism, and disputes, technical or otherwise, come out in the software.

Mozilla was our leading candidate right away, mostly because of Don’s connection to that code. He expressed confidence we could leverage the work of those big teams at Netscape.

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.

When we were developing our web browser strategy, the guidance from our executives was less a matter of “free as in freedom” or “free as in beer” and more “closed source as in money.”

Respecting the conditions under which someone else made their work available was simply the right thing to do. What’s more, if we hadn’t honored Konqueror’s license terms, we could have exposed Apple to legal action. I didn’t want to obsess over licenses, but I thought it important to invest some time and careful thought to ensure we had the technical and legal bases covered.

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.

Steve thought speed was the long-term key to better browsing, so making a high-performance browser became our top priority, our definition for greatness.

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.

Steve felt the need to say why Apple had made its own browser, and his explanation led with speed. Some may have thought that touting Safari performance was just marketing, a retrospective cherry-picking of one browser attribute that just happened to turn out well. I knew better. I had been part of the team that had received the speed mandate months earlier, and I had participated in the actions he now described which ensured the speed of our browser.

In any complex effort, communicating a well-articulated vision for what you’re trying to do is the starting point for figuring out how to do it.

Perhaps the most unnerving and fear-inducing source of anxiety is that your ideas, words, and resulting vision might not be any good to start with and wouldn’t yield success even with a faithful follow-through.

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.

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.

Apple is customer-focused. The company always sought to give people convincing reasons to buy its products. If the marketing department wasn’t interested in telling people about sync, then the feature was something Apple felt it needed to do, not necessarily something that it wanted to do or was excited about doing.

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

Demos made us react, and the reactions were essential.

Direct feedback on one demo provided the impetus to transform it into the next.

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.

None of us knew how a touchscreen keyboard was supposed to work. I had to constantly ask myself whether what seemed like a good solution to me was actually a good solution. I didn’t know. Typing on a small sheet of glass was new.

his reaction was just like a prospective customer evaluating a product from scratch. My keyboard would be a part of the overall impression, and Phil was confused rather than convinced.

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.

We’ve all owned devices that had too many ill-considered, overlapping, and inscrutable features, making the products nearly impossible to understand or use. Apple’s whole identity was bound up in not having this problem.

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.

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.

empathy as trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs.

The living-on experiences with the derby-winning keyboard showed several breakdowns in empathy, where the person felt at odds with software attempting to provide assistance.

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.

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

Persist too long in making choices without justifying them, and an entire creative effort might wander aimlessly. The results might be the sum of wishy-washy half decisions.

The small-scale justifications must contribute to a scheme larger than themselves. The design responsibility expands to balancing the many individual refined-like responses against the other side of the taste equation, the attempt to create a pleasing and integrated whole.