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

by Ken Kocienda

It’s not just what it looks like and feels like. Design is how it works.

Usually we kept the rate of our progress above the level of our stress, mostly because we hit few roadblocks that wouldn’t give way to a good idea.

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

When it came to choosing a color, we picked one. We used our good taste—and our knowledge of how to make software accessible to people with visual difficulties related to color perception—and we moved on. Or did we? Well, yes and no. We always made quick choices about small details, but we were always willing to reconsider previous decisions. We took more time with bigger questions, but never too much. We were always mindful of making steady progress.

We didn’t shuffle around printed specifications or unchanging paper mock-ups for weeks on end, waiting for an epiphany that would jump us directly from an early-stage concept to a complete product design, hoping we could somehow flip the ratio of inspiration to perspiration

Detached high-level managers making all the key decisions is such a widespread affliction that it has its own internet meme, the Seagull Manager.

You could hold demo meetings and then adjourn them without deciding what to do next, a mistake that interrupts the chain of criticism that provides the logical connection from demo to demo.

You could assign oversized project teams to the tasks one or two people could handle, a fault that can lead to muddled communications and a dilution of each person’s ability to make a difference.

You could have conflicting lines of authority and fail to ever reach universally re...

We always started small, with some inspiration. We made demos. We mixed in feedback. We listened to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another and then another. We improved our demos in incremental steps. We evolved our work by slowly converging on better versions of the vision.

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.

Unlike evaluating algorithms, heuristics are harder to nail down. For instance, how quickly should a scrolling list glide to a stop after you’ve flicked it? We always made demos to evaluate the possibilities.

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.

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.

We tried to be tasteful and collaborative and diligent and mindful of craft and the rest in all the things we did, all the time.

In my experience, this manner of culture formation works best when the groups and teams remain small, when the interpersonal interactions are habitual and rich rather than occasional and fleeting.

Our leaders wanted high-quality results, and they set the constraint that they wanted to interact directly with the people doing the work, creating the demos, and so on. That placed limits on numbers.

This had a follow-on effect as well, in that keeping our development groups small fostered feelings of personal empowerment and a sense of team cohesion.

Apple University is an internal company-sponsored training department whose mission is to capture, communicate, understand, and preserve Apple best practices.