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

by Ken Kocienda

If there’s a unique magic in Apple’s products, it’s in the software, and I’ll tell you how we created some of the most important software in the company’s history.

we never thought about such big numbers. We were too busy focusing on small details. Every day at Apple was like going to school, a design-focused, high-tech, product-creation university, an immersion program where the next exam was always around the corner.

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

No matter how good your work was, or how smoothly it had sailed through the preliminary reviews leading up to him, you could never know how he would react.

One exceptionally talented and experienced colleague told me flat out that he refused to demo his own work in Diplomacy ever again because of the way Steve treated people in these face-to-face meetings.

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.

A flannel shirt–wearing, cigarette-smoking New Yorker, Greg had an encyclopedic knowledge of the history of computing, a tinkerer’s knowledge of analog and digital hardware, and a gut feeling for how to create software that made sense to people.

Above the entrance to the Oracle at Delphi, there was a sign that read “Know Thyself,”

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.

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 found the demo unnecessarily complicated, so he unpacked it. This deconstruction wasn’t typical, but it was completely in character.

Even the discussion Steve used to arrive at his conclusion was spare and minimal.

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 used demo reviews to judge for himself whether features met this basic usability standard.

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

Given Don’s technical introduction sessions, I just accepted that web browsers needed to be super-big programming projects, and I got used to the idea that I’d need to understand all this new code.

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.

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.

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

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

Making demos is hard. It involves overcoming apprehensions about committing time and effort to an idea that you aren’t sure is right.

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.

he showed that it was possible to make technical headway by skipping past the problems he couldn’t solve in favor of those he could. So, that’s what I did.

How did I know that? I lived on the software.

She was holding a Purple phone. Untethered. No cable attached to a Mac. The real industrial design. An actual glass screen, not the plastic display of a Wallaby. I had never seen one of these before, and this wasn’t a mere model either. It was a working phone. The hardware was powered up and running with all our software loaded onto it. As Kim handed around this late-stage prototype, she pointed out that there were one or two hardware components that weren’t final yet, and since they were slightly bulkier than the parts we would manufacture at volume, the top and bottom of the case didn’t meet on the lower left corner of the demo device. There was a little gap, maybe two or three millimeters. The Purple phone was converging, but it wasn’t completely converged yet.

Security remained tight up until the last moment, and when I walked into the Moscone Center on keynote day, I still didn’t know what Purple would be called. On the tenth of January 2007, the day after the big product introduction, I edited the autocorrection dictionary to add a new word: iPhone.

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

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.

With our Darwinian demo methodology, we had a huge advantage over artificially selecting breeders and the glacially slow accumulations of genetic improvements that drive natural selection.

We were always so focused on the next demo, the next review session, the next time we were scheduled to show progress to Steve.

Imran used this piece of paper gliding around under his finger to show how iPhone direct manipulation should feel, and for him, the feeling of it was essential.*

this many items in our minds at once. This quiz illustrates a concept I’ve mentioned a few times in this book: mental load.

My experience making products has taught me that this limit is real. Interacting with technology, especially when it’s new or tricky, creates the same kind of burden as my listing quiz. We soon hit our mental boundaries, and it doesn’t take much to knock our minds off course when we’re navigating in a sea of complexity.

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

Determining comfort levels, pursuing smoothness, and reducing mental load are examples of the kinds of ergonomic, perceptual, and psychological effects we often aimed for, and in each case, honing and tuning technology to a high level became the means to achieve people-centered results.

We used the word “heuristics” to describe aspects of software development that tip toward the liberal arts.

Heuristics and algorithms are like two sides of the same coin.

Algorithms produce quantifiable results, where progress is defined by measurements moving in a predetermined direction,

Heuristics also have a measurement or value associated with them—the duration for an animation or the red-green-blue values for an onscreen color, but there isn’t a similar “arrow of improvement” that always points the same way.

How long should it take for an app icon to animate up from its place on the home screen to fill the entire display? How far should you have to drag your finger on the screen for it to be possible to interpret the touch as a swipe gesture? How much should a two-finger pinch gesture allow you to zoom in on an image in the Photos app? The answers to all of these questions were numbers, and might be 0.35 seconds for the app animation, or 30 pixels for the swipe gesture, or 4x for photo zooming, but the number was never the point. The values themselves weren’t provably better in any engineering sense. Rather, the numbers represented sensible defaults, or pleasing effects, or a way to give people what they meant rather than what they did.

it’s crucial to make the right call about whether to use an algorithm or a heuristic in a specific situation.

The output from a heuristic often became the input to an algorithm whose output, in turn, became the input to the next heuristic.

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