Less waterfall = less design = better design

A lot has been written on the subject of waterfall v agile in many a blog. For what it’s worth, here’s my brief thoughts.

There’s still a persistent school of thought that designing detailed Omnigraffle wireframes followed by pixel-perfect Photoshop layouts is the only way to get design right before handing over to developers (it’s certainly often the only way management feel comfortably in control). Only then months later having awkward conversations with your developers as you try and work out how to make the required designs feasible.

It’s not my favourite method of working. I want a truly iterative and collaborative environment that is flexible and works within the framework of reality. By this I mean if you’re designing ages before you’re developing, you’re doing so without the full, live information of what the state of the site is. Every variable counts and the closer you are to the build the more aware you can be of the other affecting factors on your design. Plus when you work closely with a developer they’ll instantly be able to tell you what works and what doesn’t:

Here, a sketch on a post-it note can be design;

A screengrab of a firebug in-browser mock-up can be design;

Writing a bit of CSS can be design;

A chat over a laptop screen can be design;

A Skype conversation can be design.

You’re empowering the developers to be designers too and as a result the product becomes stronger. It’s a scary world that can put you out there, open to more unknowns. But in a space to be able to adapt and tackle them, which you can’t be from the safety of your Photoshop doc.