User Centred Design and Agile Development | December 22, 2006

Clearleft is a UCD, or User Centred Design consultancy. We spend time learning about the people who use our clients products, and then put those users at the heart of the design process. We do this using a variety of techniques from user surveys and contextual enquiry, through to persona creation, wireframing and usability testing. The ultimate goal of this process is to create experiences that are useful and meaningful to the people using our clients software.

As a company we specialise in the architecture and design side of the equation. We understand programming and development, but it’s not a service we offer. When clients come to us for implementation, we prefer to partner with another agency that specialises in back-end development. We’ve been designing a lot of interesting web applications recently, so Ruby on Rails seemed like a natural choice of development technology. One of the interesting things about working with Rails developers is their love of agile development.

Not being a developer, I’ve always been a bit nervous about agile development. I’ve heard people evangelise the benefits of reduced documentation, fast iterations and peer programming, and it logically makes sense. However I’ve always seen agile development as a bit of an ideological clique, and terms like extreme programming and scrum methodologies hardly make it accessible to the lay person. Because of this I’ve been aware of the concept for some time, but never really looked into it. It’s always seemed much more relevant to developers, so we’ve done our thing and let our dev partners do theirs.

A few weeks ago I was lucky enough to attend the Flash on the Beach conference in Brighton. As I mentioned at the time, my favourite talk of the conference came from Aral Balkan. During his wide-ranging presentation, Aral touched on a number of topics, but the one that piqued my interest the most was his take on agile development and how it fitted into a user centred design philosophy.

At first glance you’d be excused for thinking that the two techniques were diametrically opposed. After all Agile development is about making the developer’s life easier, while UCD is about making the user’s life easier. However the ultimate goal of both techniques is to deliver more useful software, and there is a lot of crossover.

Sat in the audience listening to Aral describe agile development, I was amazed how similar parts of it were to our UCD process. The agile process starts with a “Planning Game” where the client and dev team sit down and create a series of “user stories” in plain English. These stories are then broken down into tasks which are estimated and prioritised. This is pretty much exactly what we do, except we call it an IA workshop. We start by talking to the client about their users and examining any user data we may have gathered previously. Using this information, we”ll develop a set of “user personas” and create “scenarios” and “user paths” based on these archetypes. The user paths are broken down into tasks and each task is estimated and prioritised based on utility, complexity and time/cost.

In agile development, project specifications and other documentation is eschewed in favour of rapid implementation. We take a similar approach, and avoid written documentation in favour of representative wireframes. Rather than spending weeks trying to explain how a system will work in words, we build a non-functional paper prototype or a semi-functional XHTML/CSS prototype. Our clients can then start playing with the site before a single line of code has been written, so changes are fast and involve little overhead.

This is where we diverge slightly from the agile process as we wireframe the whole system in one go whereas agile devotees will only implement one user story at a time. I prefer to plan the site out fully first as I feel it makes for a more holistic approach. One process invariably affects another, and if you’re only concentrating on one story, it is easy to miss important patterns or vital connections. We’ve never done the small, fast iteration thing before so I’d be interested to see how it works. However I’d be worried that it would make user testing difficult as you would either be forced to do lots of small user tests which would cause resource problems, or wait till enough of the system has been designed to run a multi scenario test, at which point it becomes more difficult and costly to re-program the interactions

Minor issues aside, I think the similarities between agile development and UCD are fascinating. There is a great article over at UXmatters at the moment called Clash of the Titans: Agile and UCD which mirrors my feelings on the subject. I urge you to check the article out and would love to hear your thoughts.

Posted at December 22, 2006 12:29 PM

Comments

Clive Walker said on December 22, 2006 1:26 PM

I am particularly interested in your user-centred design approach which seems very thorough and this is a comment on that rather than agile development. I just wondered how you tailor your approach for smaller business clients? who may perhaps have less budget. I am talking about clients with only a few employees. Or is there no difference in your approach?

soxiam said on December 22, 2006 2:27 PM

I work at a place where we are neck-deep in XP (extreme programming) and I will say this… EVERYONE needs be get on board or the methodology will show more con’s than pro’s. And I mean everyone, down to the director of sales to marketing folks. As a designer working in such place, I am slowly beginning to adapt to the pace and approach to product development and deployment but I believe it definitely hampers with your effort to explore your ideas further. More often than not, you’re bound by the tight iteration schedule and end up signing off on “good enough for launch” design with hopes that you will continue to improve in later iterations. The reality however for a company with limited resources is that you will move on to the next project slated for the next iteration and rarely have enough time to re-examine what you released.

Pierre Canthelou said on December 22, 2006 2:37 PM

Being a stand alone worker (freelance webdesigner), using agile methods may seems useless. But time, when you’re alone, is a very important variable (I’m talking about those 3 variables, time, budget, work/tasks) so you have to be well organised to manage your projects.
I’m must say that I’ve used eXtreme Programming during my software engineering job, previously to my webdesigner job.
Agile Development and UCD can be considered the same thing to me, because both are centered on human and communication, as opposed to various processes where the human resources don’t talk to each other except for delivering tones of paper and saying “this is what you have to do”.
First of all are “stories” : both AD and UCD use them to delimit the needs, and both needs come from the customer with the help of the producter team (either designer, engineers, … when you’re alone, it’s more simple, you play all those role). So, quite opposed to what R.F.Cecil wrote, I don’t think AD is opposed to design-first, even a whole-project design-first. It just depend how deep you fall in this. Doing usability research prior to any programming is like doing design brainstorming in XP prior to development sessions.
Doing website project implies you have a fully understanding of visitors exceptations, but as any serious IT professional would say, excpectations evolve during the project lifecycle because the customer discover new things and new ways with the “software” in front of his eyes. So, doing design ahead may help. I am found of prototyping, especialy incremental and progressive amelioration to illustrate the probable fusion of AD and UCD : begining with paper based prototype, then evolve to XHTML prototype with fake content, next with fake programmed content, next implementing features by priority…
Doing so help the customer understand his project, helps you understand the customer excpectations, all this being interleaved with dual-communication and incremental programming sessions and refactoring session where you can go from moke prototype to usable prototype and finally fully functional prototype.
I remember an article from K.Beck or another XP guru saying that XP is annoying to certain IT professional because it breaks down the well establish hierarchy of software development : project manager - architect - analyst… Confronting UCD and AD is the same as professionals think their job may be prevalent to the other, btu they desere the same thing, the customer, and if they work together (and as I’ve explained, I think they can, I can), there is no need to separate the two processes.
I’ve already written something about that way of working on codesign.fr in the making of, but it is in french :)

I don’t know if this comment can be useful, but it was a pleisure to expose my thought.

Keith said on December 22, 2006 5:11 PM

Good post Andy.

It’s interesting to see how your methods and process mirrors Blue Flavor’s. They’re not the same, but similar.

Anyway, we’ve worked on a few projects where we’ve been asked to work with teams who embrace Agile Development and it’s usually gone very well.

The one thing that I stuggle with is that UCD often takes a bit more time to do right than we’re given. Now, we are used to working with shorter timeframes, with small budgets and on tight deadlines, but I often feel that if we had a few more weeks, a bit more money, etc. we could do a much better job.

But I guess that could be said for anything right?

Like you we prefer to work on the architecture and design portions of a project or the “front end” and we’ve adopted a flexible, iterative approach that is designed to let us focus on doing good work as quickly and painlessly as possible. Similar in many ways to Agile Development.

In any case, I find that the philosophy behind Agile Development to be a good one that fits quite well with a user centered design approach. If nothing else, it’s got some flexibility to it and takes quite a bit of overhead out of the way.

Ben said on December 25, 2006 11:00 PM

It was interesting to hear Jeff Veen’s talk at dconstruct 2006 about running a UCD analysis on Google Analytics. I remember thinking at the time how incompatible it seemed with Jason Freed’s vision of AD that I’d heard on a podcast the day before, and wondering who was right.

I guess you could say that AD is definitely ‘user centered’ in that you (repeatedly) refine and change the product based on real-world performance. In contrast, it sounds like it is quite feasible for UCD to be completely ‘un-agile’. Jeff was talking about doing loads of task analysis but it was all in the name of getting things right before beginning development, to avoid having to change things later.

So in UCD-AD presumably you would have to break the UCD bit into stages: do some UCD, build version 0.1, do more UCD, build version 0.2 and so on?

Tom Hume said on January 2, 2007 9:03 AM

Agile is an umbrella term for a whole load of practices; some folks say you need to do the lot for it all to work, others that you can pick and choose bits. Over the last few years we’ve adopted bits of agile pragmatically - testing them individually, discarding them if they don’t work and keeping them if they do… so we’re definitely in the latter camp. I was originally introduced to Scrum by the BBC back in 2003, after they used it on a project we worked on, and was quite impressed by it as a project management process. We’ve tended to adopt the time-boxing and iterative nature of Scrum, alongside software development techniques of “agile” (bug tracking, version control, continuous integration, unit testing, and high visibility of project status using our Nabaztag). We’re not XP evangelists and don’t do much in the way of pair programming, say… though I know companies that do and that speak highly of it.

Agile is definitely not about making the developers life easier: we do it because we think it lets us deliver better software quicker, not because it’s easier or more fun. In fact in many ways it seems to rely on difficult-to-quantify “soft skills” and lots of communication rather than hard-and-fast and measurable documentation… managing an agile process brings its own set of problems. What it is great for is projects where requirements are unclear, or where there’s expected to be a lot of change during development. This is handy for us because we frequently target devices which aren’t on the market when a project begins: a pure up-front design process just isn’t feasible here.

We do UCD and don’t see a conflict between the two: like you, we wireframe whole applications up-front. For a smaller service this is fine. For a larger service, we find we need some sort of overall view of the thing before we can dive down into detail and implement a feature at a time. Without this you tend to lack a consistency of user experience.

Agile doesn’t necessarily eschew documentation: for ongoing maintenance and for our our sanity and communication, we still document the software we develop quite carefully. What it does avoid is the “design everything and express this design in a specification”, followed by “build from this specification” style of development - so it’s true to say there’s less design up front.

I see the connections you’re making between user stories in agile and personas, but when I’ve talked to folks who know more about agile than I they tell me these are different things. I don’t quite understand why, myself - and the story-driven methodology of XP is something we don’t currently do at FP, so I can’t really explain it any better than that. This said, we are evaluating it for use on projects.

You’re right about the testing burden in agile, but I think there’s different sorts of testing for different points in a project’s life: during development, unit tests ensure the underlying framework is still valid (I’m not sure what, if anything, the equivalent for design aspects of a project is). User testing is still necessary, we tend to do this at the end of iterations: so that at the finish of an iteration, a tested product exists and can be launched.

Mike Stenhouse said on January 3, 2007 2:59 PM

As Tom says, the idea of agile development actually isn’t to make the developers’ lives easier - it’s to produce better software. In some circumstances it can actually make life harder, requiring buckets of self-discipline and a lot of cross-training.

User collaboration is in the original Agile manifesto, I believe, but it’s traditionally been the poorest implemented. I saw Luke Hohmann talk about this a few weeks ago… He argues that this is mainly because programmers aren’t trained to communicate with clients. What little I’ve seen of the attempts to remedy this (the innovation game is the only one I can remember off hand!) look interesting and may well be useful tools for UCD discovery too…

Either way, of all the Agile practices emergence is my favourite and the one that applies most to my work. I’d argue that it’s almost impossible to get things exactly right first time. How can you prototype a habitual use app, for example? Get it as close as you can within your time constraints and then iterate feels much more effective to me.

Josh said on January 3, 2007 9:54 PM

See what you think of this approach to Agile. It’s from an article I found in ACM Queue.

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=424

I’m still digesting, but it sounds good to me.

Josh

designer said on January 22, 2007 7:36 PM

Yeah and the latest news ^
Niqui just informed me that registrations for BarCampLondon2 are now open. Ian apparently announced it about 3 minutes ago. There are 100 places and the tickets (which are free) are going fast.