Apple's design process

Apple's design process
Posted by: Helen Walters on March 08

Interesting presentation at SXSW from Michael Lopp, senior engineering
manager at Apple, who tried to assess how Apple "gets" design when so
many other companies try and fail. After describing Apple's process of
delivering consumers with a succession of presents ("really good ideas
wrapped up in other really good ideas" - in other words, great software
in fabulous hardware in beautiful packaging), he asked the question many
have asked in their time: "How the f*ck do you do that?" (South by
Southwest is at ease with its panelists speaking earthily.) Then he went
into a few details:

Pixel Perfect Mockups
This, Lopp admitted, causes a huge amount of work and takes an enormous
amount of time. But, he added, "it removes all ambiguity." That might
add time up front, but it removes the need to correct mistakes later on.

10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new
feature. Not, Lopp said, "seven in order to make three look good", which
seems to be a fairly standard practice elsewhere. They'll take ten, and
give themselves room to design without restriction. Later they whittle
that number to three, spend more months on those three and then finally
end up with one strong decision.

Paired Design Meetings
This was really interesting. Every week, the teams have two meetings.
One in which to brainstorm, to forget about constraints and think
freely. As Lopp put
it: to "go crazy". Then they also hold a production meeting, an entirely
separate but equally regular meeting which is the other's antithesis.
Here, the designers and engineers are required to nail everything down,
to work out how this crazy idea might actually work. This process and
organization continues throughout the development of any app, though of
course the balance shifts as the app progresses. But keeping an option
for creative thought even at a late stage is really smart.

Pony Meeting
This refers to a story Lopp told earlier in the session, in which he
described the process of a senior manager outlining what they wanted
from any new
application: "I want WYSIWYG... I want it to support major browsers... I
want it to reflect the spirit of the company." Or, as Lopp put it: "I
want a pony!" He
added: "Who doesn't? A pony is gorgeous!" The problem, he said, is that
these people are describing what they think they want. And even if
they're misguided, they, as the ones signing the checks, really cannot
be ignored.

The solution, he described, is to take the best ideas from the paired
design meetings and present those to leadership, who might just decide
that some of those ideas are, in fact, their longed-for ponies. In this
way, the ponies morph into deliverables. And the C-suite, who are quite
reasonable in wanting to know what designers are up to, and absolutely
entitled to want to have a say in what's going on, are involved and
included. And that helps to ensure that there are no nasty mistakes down
the line.