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

by Ken Kocienda

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

It takes effort to find what these things are, which is appropriate, since the etymological root of “heuristic” is eureka, which (of course) c...

good heuristics don’t come in brilliant flashes, but only after patient searches, and it wasn’t always clear to us that we had found ...

We arrived at our final decisions only with judgment and time. Heuristics are like ...

We used algorithms and heuristics like they were the left and right sides of our collective...

Employing each involved an interplay of craft and taste, and we always tried to st...

Algorithms and heuristics must coordinate to make a great...

However, 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 algorithmic...

We used demos to pick colors and animation timings, and we put our faith ...

we made a subjective call. We developed heuristics.

What was important was that there remained a tension and flow between the algorithms and heuristics—making the correct choices to lean toward technology or liberal arts could be complicated.

sometimes we used heuristics to temper algorithms.

The goal for autocorrection was to give you the word you meant, given what you did, not unconditionally conform your typing to the dictionary through the use of some clever calculation.

After a certain point, unexpected autocorrections made the software seem confusing rather than helpful. Where was this point?

I could find out only by asking people, and then, based on their feedback, picking a heuristic cut-off point for how much intervention I should allow the pattern skew algorithm to make and when I should have it back off.

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.

you can’t “engineer” a product in one phase and then slap on “look and feel” in another.