Frederic Monjo — Thu, 09 Apr 2009 12:22:59 GMT

There is one thing obvious about UX and Agile: they are both iterative and incremental with frequent feedback. So why is making them work together so subject to discussions? My vision is that we expect different things from a Design iteration and from a Development iteration.

IMHO, when doing design your first expectation is to fail, you look for things users get stucked with. Then you try to make them even more happy with better design, but the minimal goal is to make users succeed in their tasks.
On the other hand, when developping running software, your first expectation is to make it work as “specified”. But if the specifications are “wrong”, you develop the wrong software. The Agile answer is: “Make it work, show it, and correct.” That’s the real revolution with Agile (I’m an Agile evangelist), but I think it is creating waste that can be avoided.

By doing Design upfront to the implementation, you can fail for cheap (e.g. with paper prototyping, low-fi prototying and quick user testing). You waste very little when you are wrong, this is the best aspect of a good and efficient Design process. So when you eventually implement your (iteratively and incrementaly) refined prototype, you minimize the risk of being wrong. You don’t expect to be perfectly right, but only to avoid major mistakes or misunderstandings of users needs. If you are still wrong—which is very probable—you can quickly adapt, and this is where Agile rocks.

So IMHO doing design upfront Agile iteration is the obvious. The only question is how and when? On my current project—huge internal software just starting—we are producing the product backlog from the results of design prototypes (which vary in fidelity depending on the complexity of the problem to solve), and the implementation iterations will start with a strong confidence about the users’ context, tasks, environment, and in UI principles, all attached to the User Stories.

We are not implementing yet (usual poticial issues in big companies are slowing us down in the process), but the first results with our Design process has revealed big requirements mistakes and we upgraded them from the start. We have some mid- to hi- fidelity prototypes which make users understand and approve our understanding of their needs and our proposed solution. I keen on seeing how this way of doing performs when implementation has started.

Thinking and Making: Comments by Frederic Monjo