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

by Ken Kocienda

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

Code Rush,

Back in the early days of our browser project, Steve told us he wanted it to be fast. Don gave us his rule to realize this goal, never make the browser slower, as well as the Page Load Test, the means to accomplish it. Our browser team incorporated the PLT into our daily workflow, and we used the test results to measure and monitor our progress. Around a year later, when we were ready to release Safari, Steve could stand up on stage and, in a straightforward manner, tell the world what we had done. Our speedy browser lay at the end of a long chain linking inspiration to proposal to plan to process to product.

Empathy is a crucial part of making great products. 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. Even before we realized these detailed typing problems existed, there was the initial visual impression of the keyboard. As Phil did in my demo with him, people reacted to the appearance of the keyboard. Its look communicated what the keyboard was and what it did.

Yet when it comes to making products, philosophical discourse is the wrong tool for the job when practical decisions are needed.

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.

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.

I’ve given a name to this continuing progression of demo -> feedback -> next demo: creative selection.

These kinds of anti-patterns can prevent creative selection from functioning correctly, since they block the steady accumulation of positive change while developing a product.

We managed to steer clear of all such pitfalls. If I were to take a stab at explaining the why, I would say that our clarity of purpose kept us on track,

Unlike the unspoken idea of creative selection, we did talk about “working at the intersection” among ourselves.

To make products more approachable, designers must lighten the load on people trying to use the things they make. Even small simplifications make a difference.

We used algorithms and heuristics like they were the left and right sides of our collective product development brain. Employing each involved an interplay of craft and taste, and we always tried to strike the correct balance.

it’s crucial to make the right call about whether to use an algorithm or a heuristic in a specific situation. This is why the Google experiment with forty-one shades of blue seems so foreign to me, accustomed as I am to the Apple approach. Google used an A/B test to make a color choice. It used a single predetermined value criterion and defined it like so: The best shade of blue is the one that people clicked most often in the test. This is an algorithm.

At Apple, we never considered the notion of an algorithmically correct color. We used demos to pick colors and animation timings, and we put our faith in our sense of taste.

sometimes we used heuristics to temper algorithms. In keyboard autocorrection, the pattern skew algorithm could always find the closest-matching dictionary word for any sequence of letters.

Other times we chained algorithms and heuristics together. The output from a heuristic often became the input to an algorithm whose output, in turn, became the input to the next heuristic.

This is what working at the intersection is all about. 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 was often difficult to decide where an algorithm should end and a heuristic should take over.