Everyone’s doing agile. The days of the monolithic project are seemingly numbered. Whether that’s true or not I’m not sure. There will always be the big enterprise stuff going on somewhere.
But for the rest of us it’s getting quicker and cheaper to build web products and services. OSS, SaaS and a plethora of APIs has reduced the time frame down to days to get something out into the wild.
At the same time that all this is happening, the increased complexity of the user interactions online now necessitates greater attention to the design of a given site. But, with the deadlines getting shorter, where does the extra time come from to get the design right? This is something I’ve been asked a number of times. Most recently by a developer specialising in Ruby on Rails development – the grand daddy of all web 2.0 rapid, agile development platforms.
I’ve worked on a couple of agile projects. And let me say, it’s not for the feint-hearted. No room for newbies here. Sorry. You need to begin with a designer who has plenty of experience in designing and delivering web projects. That designer also needs to let go a little, become less precious and realise that if it’s not perfect now, it can be in 24 hours time – but more of that later.
Right let’s get started.
Defining the interface through sketching
As I may have mentioned before, I like to sketch. I find it’s the best way of getting an idea down in visual form and in front of the client quickly. What’s great with this approach is that the client won’t get bogged down in the details of colour and copy. They’ll focus on content and the broader layout and examine if everything they need/requested is on the page. Just to note at this point, I’m not talking about managing scope creep in this post, just how the design bit might work within the wider project.

What’s lovely about sketching is that it lowers the barrier to producing layouts to anyone who can hold a pen and apply it to paper. In fact, one method I have used historically is to gather the project team around a whiteboard and gradually ‘build’ the interface as a collaborative exercise. A snap with a camera phone then records it to be shared. Which ever way you do it, the sketching process helps to iron out any potential issues with development before committing pixels in Photoshop.
Working up the interface
The developers can go and start to build some stuff working from the sketch as a starting point. It’ll be ugly (probably) but at least they have something to build. Without the sketching bit they may be hanging around waiting for your designs which creates a bottleneck.
You’re probably looking at getting a design out in a couple or three days from here. Before the project started you may have done some initial investigative design work and got a broad ‘look and feel’ working which makes this stage a little easier.
It’s a convenient point to mention that working in the same room as the client on an agile project really helps. They are engaged, not going to any other meetings (this is agile – it takes both a physical and time commitment) and are, therefore, on hand to answer any questions. That client also needs to be in a position that allows them to sign things off quickly. No committees allowed. No 6 rounds of design amends. Get a design done, keep reminding them of the deadline and hopefully get it (largely) signed off. If there is one particular widget or element that isn’t working, you may be able to ignore it for the time being and commit the rest of the design leaving the sticking point to later.
This signed off design can then go and start the transition into CSS, XHTML and Javascript. As this is happening you can start to work on other screens or refine the design of that widget that the client wasn’t happy with. Again though, you’re not holding the process up. Everyone has plenty to do and aren’t wanting for finished designs.
This should be the way the process then works for the rest of the page templates on the site/service.
The PSD is not king – the prototyped site is
One point to mention in an agile project and, in my eyes, it’s very important. Unlike other projects where the client likes to see armfuls of printed out PSDs; in an agile project the PSDs have a diminished authority. As soon as they’ve started to hit the front-end mark up guy, the prototype site has the authority. That’s the working, living, breathing product. We’re not in the habit on an agile project of creating artwork for gallery walls.
A very efficient method of working I’ve found is to screen-shot the prototyped site and work on that in Photoshop for the subsequent iterations. That way you don’t waste time recreating PSDs to match the prototype. It’s all in place for you and you can get on with designing the portion of the interface that you need to get done.

The only certainty is change
Always remember that this is a two-way process. Development / client / HTML can come back to you at any point for clarification or indeed amends for any number of reasons. Ideally you should commit 100% of your time to this project. Dividing your time between projects may mean that you miss decisions being made and have no idea of functionality that may have changed from half a day ago. Services such as Twitter (or any enterprise variant) come in handy to help keep communication channels alive on the project. Perpetual contact with the team and multiple releases a day make it both and exciting but at the same time exhausting process.
Talking of multiple releases. As mentioned earlier, precious designers may find the whole process a nightmare of frustration and chaos. If you let go a little and remain pragmatic then you can still produce well crafted sites. The very thing that may create this frustration allows you to change things very quickly – the multiple releases. If you embrace the process and adapt to a way of working that sits well with you and just as importantly with the rest of the team, there is every chance that you will be able to get a great product out in a time-frame that you never thought possible.