Spencer Turner - Designer On Rails

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

2010-07-20T00:00:00-04:00

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?

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.
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.
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.
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:

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.
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).
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.

Interface should indicate behaviour

2010-05-06T00:00:00-04:00

OK, so it’s sad to admit, but I think about user-interface quite a lot outside of work. (And should write about it more often, but that’s a different issue!) We recently bought a new house, which is great, but like a UX project, coming to someone else’s work, you suddenly realise all the things you take for granted as ‘just right’…

The cupboard handle that prompted a blog post

There is lots of built in storage in our new house, which is great. However, the handles on the cupboards look exactly the same as the door handles on the actual doors…Sounds correct, right? Good design, giving a consistent finish.

The only problem is that the cupboard doors don’t have latches, they have magnets and so are a pull handle, the main doors are turn and pull as they have mortice latches. The cupboard door handles still turn, so I find my self turning the handle, finding it stiff and wondering why the door isn’t opening with a click. I know in the back of my head that this isn’t the behavior as I’ve learned that through repeated annoyance, but I still do it wrong more times than right.

The thing this triggered in me was that interface should indicate behaviour, above design consistency even. I’d rather have different cupboard door handles (that look nice in combination with the main door handles, aesthetics being important as well!) but that clearly indicate the behaviour to be a pull, not a turn.

Things that look simple and ‘just right’ are only that way because the person planning it did a good job

We were spoilt with our last house, and I didn’t realise it. My father in law is a retired electrical engineer and kindly helped up plan the electrics in our previous house. (which needed a total rewire) I have to say, at the time I thought the number of light switches he was suggesting seemed overkill. Why would I need to be able to turn the downstairs light off from upstairs? Why do I need a pull cord over the bed to switch the bedroom light off? Surely it’s common sense to have enough power sockets?

No so. Our new house, I have to walk downstairs to turn the light off, I can only turn certain rooms lights on from one side, so I have to follow a specific route in the dark to get to where I want to go. (not the shortest route obviously) If I want more than 2 appliances plugged in, in any room, I need a trailing socket. Now, none of these things are life-threatening, or even seriously annoying, except when you have come to expect that level of thought to have gone into something, you miss it when it is not there.

The lessons for me here were 2 fold. Firstly, that things that seems obviously correct, often aren’t as simple as someone made it look. Secondly that craftsmen are everywhere. Unassumingly doing a good job, and not shouting about it.

Finally, I’d like to say thanks Bryan for the excellent planning of our electrics. I only now understand how clever that ‘simply right’-ness was!

Welcome

2009-12-14T00:00:00-05:00

Welcome to the new Designer On Rails blog. Now with added Jeykll!