23 January 2013

Design process

Glenn Reid has a terrific little memoir of working with Steve Jobs.

I can still remember some of those early meetings, with 3 or 4 of us in a locked room somewhere on Apple campus, with a lot of whiteboards, talking about what iMovie should be (and should not be). It was as pure as pure gets, in terms of building software. Steve would draw a quick vision on the whiteboard, we'd go work on it for a while, bring it back, find out the ways in which it sucked, and we'd iterate, again and again and again. That's how it always went. Iteration. It's the key to design, really. Just keep improving it until you have to ship it.

There were only 3 of us on the team, growing to 4 within the year, with no marketing and very little infrastructure around us.

....

It is a process which requires understanding the parameters, the goals, and the gives and takes. Stretch what's possible, use technologies that are good, rein it in when the time comes, polish it and ship it. It's a kind of horse sense, maybe a bit like building houses, where you just kind of know how to do it ... or you don't.

....

One of the things about designing products that can come up is Ego, or Being Right, or whatever that is called. I'm not sure how this evolved, but when I worked with Steve on product design, there was kind of an approach we took, unconsciously, which I characterize in my mind as a “cauldron”. There might be 3 or 4 or even 10 of us in the room, looking at, say, an iteration of iPhoto. Ideas would come forth, suggestions, observations, whatever. We would “throw them into the cauldron”, and stir it, and soon nobody remembered exactly whose ideas were which. This let us make a great soup, a great potion, without worrying about who had what idea. This was critically important, in retrospect, to decouple the CEO from the ideas. If an idea was good, we'd all eventually agree on it, and if it was bad, it just kind of sank to the bottom of the pot. We didn't really remember whose ideas were which -- it just didn't matter.

This should all sound very, very familiar to my colleagues from Cooper.

  • No whiteboards, no design. Know whiteboards, know design.
  • Use small design teams working closely and collaboratively. Don't put too many people in the room. Don't make designers work solo. Don't make the design team confer all of the time with other people.
  • Design with passion but not ego. Ideas belong to the project team, not to the person who proposed them; if they're good, the team will use them and if they're not you can always come up with more. Do it right and you forget who invented what.
  • Iterate relentlessly within the design team's process. Don't settle; you can always make it better. Spend as long at this as you can possibly afford.
  • Design is product definition, not just product execution.
  • Design for the real world ... but also make the developers sweat a little. It's better to propose something that turns out to be a bit beyond what you can do and roll it back a few ticks than to do something mundane. Reality bats cleanup.
  • Design is a knack that some folks have and some folks don't ... but doing design is not sparkle magic, it's disciplined craft.
  • Product definition is the heart of company strategy, deserving executive-level juice.

A lot of people know this stuff, but there are not a lot of companies which actually allow it to be done. Apple did it because their CEO was committed to it and good at it. But you only need the first half of that equation — the commitment — for it to be possible in any organization.

1 comment:

Unknown said...

I have been struck by how difficult it is to convince people of the effectiveness of tiny teams. I long for the days when I can work with a tiny team again -- just creating. Anything. Creating anything at all.