Saturday, 7 December 2013

Iterative Design

This movie is a series of screenshots of everything we tried as we designed and build Shazam for iPad. One thing that I think this demonstrates is the importance of iterating, trying things out and throwing them away when they don't work, are confusing, or conflict with something that works better.

This is hard in any creative endeavour, of course. But there's a specific way that it seems hard for boss-types to let go of the idea that they can see a 'final design' in a meeting, sign off on it, and then have it built by some devs. You don't really ever know what you're building until it's done— sometimes you don't even know until after that— and so things like navigation and user interaction have to be worked through again and again and again.

Neil (@foley), one of the geniuses I work with, says things like "the first time you think you've solved a problem, you have definitely not solved that problem yet." I think there's room in software development methodology for an embrace of this kind of development: get some really good devs and a designer who doesn't mind a two-way street, give them some basic goals like "build something good" and then, possibly, push the process into a "finalizing/release-prep" stage when it needs some sort of release (public or internal) in order to continue maturing.