How to do design on an agile project

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.

Sketches

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.

sketch

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.

Advertisements
This entry was posted in design, work and tagged , , , , . Bookmark the permalink.

2 Responses to How to do design on an agile project

  1. MattConn says:

    The new ITN Source site was my first experience of the ‘Agile’ process and I do think it works well, but it’s very much geared to a content heavy site where there’s a lot going on. It wouldn’t be a good way of working on a campaign site for example, which is slightly ironic considering such short lived sites can take many more months to produce.

    Said it before and I’ll say it again, love your sketch work. You should think about creating an actual site interface with it.

  2. James Higgs says:

    Great post. There are a couple of things I’d probably take issue with.

    First is the concept of “signing off”. I think, basically, that it’s not an agile concept at all. The question is: does the client to spend their money on reworking the design over and over? Rather than developing?

    For me, the key thing about agile is to get *working software* in the hands of users as soon as possible, so that they use it for real, deriving real business benefit from it. But, as you rightly say, never assuming that it’s “done”. It can be changed, but, as I pointed out in a blog post that has been lost to the world, not all changes are equal. (I’ve found that I have had to remind clients of this from time to time when they bring out the snide “I thought this was an agile project” defence.)

    If you’re doing short and useful enough iterations, you should never get to a point where massive changes are required.

    My experience is that, crucially, the process you describe also helps to combine design and user experience considerations, since you’re always dealing with something that must work for users, never with an abstract PSD.

    Like Matt, I love your sketches. I just wish I wasn’t such a fat-handed twat and could do something like them myself.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s