Agile development and user experience
There's been a couple recent articles on agile development and UX:
Four Factors of Agile UX (on UXMatters)
Lessons from Google Mobile (on Boxes and Arrows)
I think this is an interesting topic. I have a colleague working in an agile development team, and it has definitely been a mixed blessing. On the one hand, the frequent iterations allows frequent opportunities to fix problems. On the other hand, the frequent iterations makes it difficult to fix BIG problems, particularly if the big problems require significant user testing to find the solution.
Here's what I think are some basic guidelines for how to do UX well in an agile environment:
1. Make sure the frequent iterations are available to users as beta code - this will likely be the best opportunity to get user feedback, even if it is informal.
2. Focus more on the "professional designer" role rather than "usability tester" role - most design problems do not need user feedback, they just need a smart designer.
3. Embrace the positives, accept the negatives - if the process does not allow big problems to be fixed, then focus on fixing the little things rather than tilting at windmills.
4. Set a user experience vision - it's easy to miss the forest for the trees in agile teams, so make sure that you're constantly evolving towards a well-understood goal, rather than constantly playing whack-a-mole with whatever the design defect du jour is.
7 comments:
Pick the right starting point
Picking the right starting point is critical in AGILE projects. What "users" are telling you they want is not always what amounts to the best place to start. One common mistake is beginning in the beginning. This only works if the beginning is actually the most challenging and troubling aspect of what the AGILE project is aimed at solving. An objective analysis of work practices, for instance using ethnographic techniques, can help identify the best points for providing value, perhaps in the way of allowing the user to do things they haven't been able to do before, thus changing how they work, or in doing things much more efficiently.
AGILE is about control, not collaboration
Face the facts, Agile development is really about the developer controlling the design, direction, and schedule of the project. If they just have to code it, show it to a user (accept and reject the feedback as they please), and make another iteration, then they have complete control of the project - no pesky and annoying user experience engineers, usability testers, UI designers to contend with.
"Agile development is really about the developer controlling the design, direction, and schedule of the project."
And that is different than non-agile development in what way? =)
Seriously, I only have extensive experience with one team that is both following Agile development practices AND has a UXer on staff, and the developers on that team seem genuinely concerned with usability and try to work closely with the UXer to get usability improvements into the product... which works pretty well provided the improvements are small enough to contain in one iteration.
Why *any* developer would want to sweat blood and tears coding something that doesn't work in the real world is beyond me.
Nobody (not even the worst kind of developer!) sets out to make bad interfaces.
Developers don't set out to make bad interfaces, I agree. The issue is that developers typically have a LOT of competing incentives beyond usability... such as unrealistic dates, technical achievement, out-geeking their buddies, pleasing management, etc... and usability often takes a back seat.
Have you ever worked on an agile team?
I haven't worked ON a team doing agile development but I've worked WITH several teams doing agile development.
A smart guy I know said recently that agile is "an engineering solution to an engineering problem", which is great provided we don't pretend it's solving a bunch of other problems.
And the biggest problem I've seen in terms of design in agile is when teams don't do architectural design before the beginning of an milestone - design iteration within milestones should be on the little stuff.
Post a Comment