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

by Ken Kocienda

Demos like this were the foundation of the Apple software development process, as you’ll see in the case of this iPad demo and as I’ll describe in many other demos throughout this book.

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

On the rightmost end of the couch, sitting close enough that Steve could have kicked him with his outstretched leg, was Bas Ording, a designer on the HI team. Bas possessed genius-level skills in illustration, animation, and demo creation, and his deftness contributed much to the intuitive feel of iOS devices. When we needed a way to move up and down a list of items on a touchscreen device that didn’t have a mouse or arrow keys, Bas created inertial scrolling, the system of finger swiping that speeds up as you scroll repeatedly, glides to a rest when you stop touching the screen, and pleasantly bounces at the end of the list. All of us take this behavior for granted today only because Bas’s solution so clearly matched our sense for how this interaction should behave.

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.

Scott didn’t run an ivory tower research and development department.

I reverted to my natural state as an introvert, and having just received far more than my recommended daily dose of concentrated eye contact, I looked at the floor.

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.

Once we submitted work for a review with our team or with more junior people who were performing work on assignment, the team manager would be the decider.

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. When he gave me the specific feedback to remove one of the two keyboards from my iPad demo, it had a cascade effect toward greater simplicity. It meant we could also take out the Bas zoom animation. We could also take away the zoom button. We could also take away possible confusion about which keyboard to show in different situations. For example, should the software remember that you used the bigger-keys keyboard in the Notes app and the more-keys keyboard in Mail, and should these keyboard choices be restored in some situations but not in others? These questions became moot, and that’s good, because they don’t necessarily have easy answers. 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.

Don’s approach was a wink combined with assurance that it was a “big job.” Everyone turned us down.

“When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.”

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.

“Folklore calls Edison the inventor of the lightbulb, but in truth the lightbulb came into being through a complex network of interaction between Edison and his rivals . . . Edison built on the designs of at least a half dozen other inventors who went before him, including Joseph Swan and William Sawyer.”

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

Even so, his experience taught him something about producing inventions: Hard work was essential.

We want to believe geniuses like Edison can conjure worldchanging inventions out of thin air. Easy explanations are alluring, and Edison-like inspiration seems magical. Perspiration, we know, involves drudgery. When Burns crafted his popular retellings of famous inventions like the incandescent lightbulb, he highlighted an imagined magical moment. Edison knew the actual story was more about the drudgery.

I agree with Edison. Ideas are nothing without the hard work to make them real. So it was for Edison in his search to find the best lightbulb filament material, and although our results with our web browser certainly were less profound for humanity, so it was for us.

In deceptively brief terms, Edison tells us: “I make trial after trial until it comes.” He and his team were willing to perspire, but he also knew what he would be doing with all those hours:

Hard work is hard. Inspiration does not pay off without diligence. We collaborated to get through the drudgery. Our knowledge of our craft—code, compilers, software licenses, and debugging—gave us the confidence to forge ahead and to invest and direct the necessary time and effort to make Richard’s demo pay off.

We were a model of Apple-style collaboration, a small group focused on a shared objective, and ours was developing a fast web browser.

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.

Front-loading feature work and back-loading performance optimizations are typical. Yet, when features take longer to complete than expected and the delivery schedule can’t be shifted, management might have no choice but to drop performance work entirely.

When we deemed such features too important to skip but couldn’t figure out how to add them without causing such slowdowns, we instituted a trading scheme, where we found speedups in unrelated parts of our existing source code to “pay for” the performance cost of the new features.

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.

“Apple’s problem is it still believes the way to grow is serving caviar in a world that seems pretty content with cheese and crackers.”

Coaches and players are also more forthcoming when speaking to the media, since teams rarely impose Apple-style secrecy. Combined with the win-or-lose nature of sports, we might hope for a link between the quality of discourse and the likelihood of victory.

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

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.

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.

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.

When Scott arrived to see keyboards on demo day, everyone on the software team was gathered in the main Purple team conference room, which was called Between. Across the hall, there were two other rooms: A Rock and A Hard Place. It had

At Apple, we built our work on this basic fact. Demos made us react, and the reactions were essential.

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

In the introduction to this book, I described 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.

done much good to quote the great German 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

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

The past is a source of the timeless and enduring.

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.

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.

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. Form should follow function, even though this might seem like a strange notion for pixels on a screen, but it’s not if you believe the appearance of a product should tell you what it is and how to use it. Objects should explain themselves.

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.

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. It also meant that the hardest part was over—we had been largely successful in navigating the course from idea to product.

They introduced me to concepts like Markov chains, conditional random fields, Bayesian inferences, and dynamic programming.

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.

No. Convergence isn’t magic. It’s a workaday high-tech development practice. Netscape’s engineers did bug convergence. It’s also what Don and I were doing during our last few days at Eazel, right up until the morning they fired the majority of the staff. Everybody in professional software development does convergence. So, converging a bug list toward zero can’t be the elusive ingredient necessary for making excellent products. 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.