A few weeks ago I attended a lecture by Jeff Gothelf about Lean UX, the process of integrating user experience design into an Agile development environment.
Traditionally, design (in a web or software context) is done in a waterfall process, meaning the steps happen sequentially. Figure out the requirements, then design the product, then implement the design, then test, then refine, then you’re done! This process has some valid strengths, as there’s little ambiguity and it gives everyone involved a very clear sequence of steps to follow to get from beginning to end.
However, waterfall and Agile don’t work well together at all. Agile is all about rapid development and frequent iteration. You quickly develop a version of the product so you can see how it works in the real world and revise it quickly. In a formal Agile environment, these iterations are structured to last 2 weeks (or sometimes 1, 3, or 4). It’s impossible to incorporate a traditional waterfall UX design process into Agile development, because the fast pace and frequent iterations of development can’t wait for UX design to be “finished” before they begin.
So how do you bring UX design into the agile environment? Jeff explained how he first failed and later succeeded in merging design and development in an Agile framework. At first he tried to maintain the waterfall mindset (design then development) with shorter timeframes to fit into the Agile “sprint.” This inevitably failed. Trying to compress months of work into a few days wasn’t the solution.
What ended up working was treating UX design as a part of the development process. Bring designers and developers together into paired units to work together in a collaborative iterative environment. Sketch out ideas as a group then refine the code and design independently based on what was created together. Focus not on deliverables (such as “final” design), but rather on creating anything that can be implemented, tested, critiqued, and refined.
Obviously, this is a significant change in work from the traditional method, and implementing it in any work environment will require commitment and buy-in from everyone involved (and those paying the bills, obviously). But as Jeff emphasized, the value of constant iteration and improvement is significant compared to the cost of doing all your design work up front and then assuming (hoping?) it’ll be exactly what was needed by the time the project is complete.
P.S. The lecture I attended was organized by the Boston PHP Meetup group. I’ve attended a few of their events and I’ve been consistently impressed by the group’s level of organization and the quality of the presenters. If you’re in or near Boston and like this type of thing, check out the group and attend some of their events.
P.P.S. The image above is a sample from Balsamiq Mockups, a rapid wireframing tool. I haven’t used it professionally, but the demo is pretty awesome.