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

by Ken Kocienda

we had few actual Eureka! moments.

Sometimes he’d say he loved or hated something but then reverse himself in midsentence. Perhaps his change of heart might come a day or two later.

either accept it, or don’t demo to him. It could be difficult to hang on while riding this emotional workplace roller coaster, and some begged off.

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.

Greg often provided the insight that some difficult development path was the best way to make our products easier to use.

However, to those who shared his high standards and his abhorrence of lazy justifications, he was unceasingly loyal and supportive.

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.

My new job was open-ended. I was expected to find, create, and contribute to projects that made our software better.

Director enabled Bas to make quick prototypes that provided a good sense of how the real thing would work.

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.

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.

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.

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.

Chief among our missteps was failing to conceive of our software as a single product instead of as a set of separate projects.

I know the demo isn’t an actual product, and my audience knows it too, but creating the illusion of an actual product is essential during the development process to maintain the vision of what we’re actually trying to achieve, and so my colleagues can begin responding and giving feedback as if the demo was the product.

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

technical grammar and syntax, and both systems could build and run programs written

The Mozilla project leaders had designed a system they hoped would turn their software into components they could snap together like LEGOs.

Mozilla was bloated, unwieldy, and troublesome.

Even so, his experience taught him something about

We want to believe geniuses like Edison can conjure world-changing inventions out of thin air. Easy explanations are alluring, and Edison-like inspiration seems magical.

I agree with Edison. Ideas are nothing without the hard work to make them real.

Since Edison suggests that dreaming and brainstorming consume so little time, then what is this 99 percent of toil that takes up the remainder?

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.

He issued a managerial edict: No more code changes without running the PLT.

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.

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.

We initially released Safari as a beta, and within a day or two, we discovered a nasty bug that could delete data from people’s computers.

He urged me to put the management change behind me, and, to help me do that, he said he wanted to know more about what made me tick.

Our CEO had continued sending email on a NeXT computer for several years after rejoining Apple because he thought the experience offered by his former company’s software was superior.

Scott not only wanted this work to get done—he needed 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.

There’s no programmer’s handbook on this topic,

Word processors are like birthday cake orders. When you type in a word processor, then select a word and make it bold, then click someplace else and type some more, you create a stream of data that directly indicates how the text should look.

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

My programming skill suddenly didn’t matter, and I didn’t have an intuitive sense for what I needed to do to be successful as a manager. I had taken the job for the wrong reason.

would tell him that I had made a mistake and that it would be better for everyone if I just admitted it and moved on.

Does this demo close the prototype-to-product gap, even a little?

He told us to stop what we were doing, to set our current projects aside, to temporarily halt all work on Safari, Mail, SpringBoard, Notes—everything. Henri told us that Scott was pushing a big Purple pause button. He wanted everyone to start making keyboards right away.

“Starting from now, you’re all keyboard engineers.”

Back then, those features would have seemed like moon rockets when we were still trying to make a slingshot.

a demo to be useful to us, it had to be concrete and specific.

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 a succession of demos was the core of the process of taking an idea from the intangible to the tangible.

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.

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.

People who love tech gadgets want new products that do cool new things.

Yet none of us wants these products and features to be confusing, to lead us astray, to drive us down a software dead end and dump us there.