Agile UX and Design - What's in it for me?

A friend nudged me on twitter to write a blog post about this, which was great for two reasons, firstly I was having a bad case of writers block (or at least procrastination), lots of things had made me nearly write a blog post, but not quite catalysed. (UX of Riverford’s new store, Should you try and make your copy SMART? etc.) Secondly, we are going to a UX retreat this weekend, and I think this might be a topic I want to discuss there, so thank you James for the timely inspiration.

Creatives and agile – The smell of fear…

When I first started at Eden; in the designer part of my role, faced with an agile developer asking me to commit to short iterations, my gut instinct was panic. Not because I felt incapable, but because creativity isn’t something you always have, or can turn on, on demand. This was of course not the right reaction, or even justified. It was however, I suspect what most ‘creatives’ feel when faced for the first time with seemingly short iterations.

Reality Check

It’s true, creativity waxes and wanes, but we cope with this all the time.

What are the tricks we use to do this?

• Limiting the fidelity that we work at (In the traditional design world, Marker visuals, Lorem ispum, Photoshop comps, low-res thumbnails of photos)
• Trying our ideas out as quickly as possibly and discarding LOTS of bad ones. You still scribble stuff, right?
• Slowly refining and enhancing ideas and designs (thumbnails, to mockups, to proofs etc.)
• Working with a team to get things done quicker
• Only presenting part of the solution (e.g. We need the Brochure first, lets start there)
• Getting feedback from the client and refining at each stage.
• Building some extra time into the deadline to make sure there is ‘wriggle room’

Hmmm - Maybe it’s not so bad… Breathe.

You are already doing it!

• Limiting fidelity, Agile Story Cards are a lo-fi method of capturing the idea of a piece of functionality.
• Slow refinement - well that’s iterative development
• Working with a team - You are part of the team (and maybe have your own team as well - double win!)
• Only present part of the solution - Work on a small chunk of functionality at a time
• Getting feedback early - Weekly (or even daily or less) releases mean constant feedback.
• Wriggle room - You should be in the planning meeting and state if you can do it in time.

But What’s in it for me?

1. Shorter time-frames add focus. Given longer, I won’t actually get more done, I’ll procrastinate until I have a looming deadline, then find focus.
2. You’ll have happy customers At the end of the day, we all want to deliver things customers are happy with. The problem is that at the beginning of most projects, the customers think they know what that is (and don’t) and you think you undertsnd what they want (and don’t). If you do Agile design right, you can combat this by really establishing what the needs are and then delivering a solution to the real problem.
3. Built in Fail. Sounds odd, I know, but it is liberating to acknowledge that you don’t have a crystal ball, and it’s not reasonable to expect to entirely acurately understand every problem and therfore, it’s impossible to provide a correct solution first time, every time.
4. When you do get to see the whole, you have something real to design If you’ve iterated on your project, and kept the design (skinning) to a minimum, you can at the last responsible moment, start doing PSDs with the benefit of a working prototype which removes the ‘we’ll probably need a twitter widget here’ page filling that creating PSDs often induces.

What techniques can I use.

This is a blog-post (or series) in itself. However, we’ve been trying out Story Mapping, and Sketchboarding, both of which we’ve found pretty helpful.

My main tips are:

1. Pens and paper Scribble your ideas, perfect drawing is not required (anyone can draw a box!) and use it as a tool to facilitate conversation about your ideas.

2. Conversation You need to talk. To your client, to thier stakeholders, to your team, to your developers and ideally along the line, you should talk to users (a lot).

3. Avoid Photoshop early on We’ve found that photoshop gives a false impression of a finished solution. Unless your stakeholders need Photoshop visuals to get buy in, we say avoid them. Try and steer them towards wireframing. If they need them for buy-in (which many do) be very clear that they are an indication of what could be. Nothing more.

Caveat lector

No amount of Agile allows you to not have to think. You still need an overview of the whole project in the back of your mind, when you are working on a small piece.

You’ll have to have an understanding not just of the problem, but of the solution, the technologies, the implications of decisions on the team and budget.

You will have to push back against developers and customers from time to time. That’s OK. Defend the things you genuinely feel are required.

You are part of the team

Agile is all about collaboration. You need to be one of the team. Seriously, the siloing of creative vs. technical is just rubbish. Developers are unlikely to have your skills and vice versa. You will learn and teach a lot (as will they). Share your skills liberally, and everyone will benefit.

I think there is a whole post in how you get ‘on the team’ and as it’s late and this is already a long post, I’ll come back to that another time.