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

by Ken Kocienda

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

This was part of Steve’s mission for Apple, the most significant strand of Apple’s product development DNA: to meld technology and the liberal arts, to take the latest software and hardware advances, mix them with elements of design and culture, and produce features and products that people found useful and meaningful in their everyday lives.

Steve moved his eyes all over the iPad screen, rotating his head slowly in small figure eights, in what I took to be an attempt to get a view of every corner of the display, both straight on and in peripheral vision.

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 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. He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday lives.

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

Seeing good work wind up on the cutting room floor was part of the job.

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.

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.

“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.”6

Steve Jobs himself had decided how he would judge our browser as a product. The focus would be on one thing: speed.

On our browser team, as in most serious software development efforts, we followed an editorial process to make changes to our source code. Whenever I finished editing some code, I would write a detailed summary of what my edits did, what feature it implemented or what bug it fixed, and how well I thought my code change accomplished these goals. Then I would find a teammate to review the work with me.

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.

When Steve spoke to a slide, he went fully into his keynote persona. His tone of voice, his stance, his gestures, everything was exactly as if he were presenting to a packed house. For as long as everything proceeded to his satisfaction, he kept going.

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. Such connections of words to actions can be meaningful, and in our case they were, since the words led to the actions we used to make our product.

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.

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.

People matter more than programming.

As a programmer and self-professed geek, possessed of a typical geek programmer’s communication skills, it was a revelation to me that both the setting and the solution to my hardest technical problem turned as much on the social side of my job as it did on the software side.

From his perspective, I had gotten the management opportunity I said I wanted, and now I was asking for something else just a few months later. I had signed up for sync. “Unsigning up” just wasn’t done. Scott wanted to understand and help me, but he wasn’t convinced I knew what I wanted, and as I think back, he was right to have his doubts. He asked me to wait before I made any decisions, and with that, our meeting was over.

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.

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.

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

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

So, is the QWERTY keyboard a pleasing and integrated whole? Is it well balanced and justifiably likable? Is it a design that works? The intervening years have provided the answer. The autocorrecting QWERTY keyboard did not sink the iPhone as a product, as did the disappointing handwriting recognition on the Newton. The opposite happened. Two-thumb typing on a touchscreen is now normal. It’s the default for mobile devices.

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.

When Scott asked me to cut a feature like the suggestion bar, it didn’t make me grumpy, even though I had been working hard on the feature for over a year. As Apple product developers, we were always happy to improve our user experiences by lightening the load of our software.

You might think that when you tap the iPhone screen, the tip of your finger touches the screen, but that isn’t so. Given the curved shape of our fingertips, the point of impact is actually lower, and it’s this spot on your finger that contacts the touchscreen first. The software modifies the geometry of your actual touch points, shifting or warping them upward to account for this difference, giving you a sense that your touch targeting is right on.

For instance, how quickly should a scrolling list glide to a stop after you’ve flicked it? We always made demos to evaluate the possibilities. I would often sit down with an HI designer like Bas or Imran 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.

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.

Apple University is an internal company-sponsored training department whose mission is to capture, communicate, understand, and preserve Apple best practices.

As we made the first couple annual revisions to our software, Steve and Scott were committed to keeping our development teams small and focused, to maintain the culture we had used to develop the iPhone in the first place. Although the software team did start to grow during these years, we were still just a few dozen designers and programmers, and we kept working as fast as we could to make the iPhone into a full-featured platform.

Without looking up, still staring at the display of the iPad, he declared his opinion on the elastic effect: “This animation . . . this is Apple.”