I’ve recently been thinking about how to better blend Agile development and User Experience Design.
Given my education in Industrial Design (ID), that was a natural first place to see what models might translate. Yes, there is all the prototyping, mockups, and rendering that are highly applicable to any software project. However ID doesn’t really do it because it is classic “waterfall-based” design approach. There is no other choice when designing for manufacturing on an assembly line. Everything has to be defined up front in order to build the tooling and stamp out the parts.
Next, I looked to Architecture (the building kind). Although I’m not an Architect, nor do I have Architectural training, I helped to re-design the kitchen and master bedroom/bathroom of my house. I also served as general contractor on the kitchen remodel. Building buildings is a lot more like software development than ID. You try to define most things before construction begins, but there are always quite a
number of things that can only be tackled as you get to them in the construction process.
I know the big deal with Agile is that design, implementation, testing, etc. are all supposed to proceed in parallel. But IMO this is an immature perspective on requirements and design. Agile development was created by software developers, not designers.
What I’ve come to strongly believe in through repeated exposure to Agile development projects is that Agile development must be proceeded by some iterations of Agile requirements and design. This needs to happen BEFORE any coding actually begins. Prototyping during the requirements and design phase is OK, but trying to create production-code and test it is a mistake during this phase.
I don’t believe you need a lot of these design iterations before coding starts. You just need to ensure that you’ve:
- Got the right requirements
- Defined the big pieces of your product’s information architecture, navigation model, and the key surfaces
- Validated your design concepts with users
Once you’ve gotten the big design pieces reasonably defined; the traditional, synchronous work of Agile can begin. Using this approach allows the design details to plug into the larger design architecture more easily and rationally.
uxstudio 
It’s interesting to see others wrestle with this problem too. We’ve been working on integrating user experience design and agile for quite some time as well, and finding a balance between the two is not easy. They’re two different responses to the fundamental failings of traditional text documentation driven waterfall process. What they share in common is the use of a feedback loop. User Experience Design does user modeling, rapid prototyping from low-fi to hi-fi, with user feedback and modifications along the way. Agile relies on short development iterations to deliver working software that you can use to get feedback to inform further development. Both have their advantages and disadvantages: On the one hand, real software in use by real users is far superior for validation than even the most hi-fi prodotype, on the other, development without big picture design can be sub-optimal. We’ve found starting with a two to four week inception phase including high level user experience design works best for us, followed by two week development iterations. Our designers stay two weeks ahead of the developers so that designs and requirements are ready at the start of the next iteration. There’s a nice presentation on the subject over at http://www.pathf.com/ideas/presentations-and-webinars/agile-design/
Bernhard: 2-4 weeks may be enough lead time provided that:
1) The designers really understand the use cases/requirements coming into the project
2) The project is of a small enough scale that a few weeks of design are sufficient to put all of the high-level pieces in place
The argument I made in my posting is that requirements and design work can still be done before coding begins using an Agile approach (i.e., fixed-length iterations). This also allows developing and understanding of the requirements BEFORE design begins. An added benefit is that alternative design options can be prototyped and validated with users.
I realize that prototypes will never be as explicit as working code, but they can definitely help to answer some of the “big picture” questions about the overall direction of the User Experience.
The reality is that software development is still an immature industrial discipline, and as such is still finding its way towards best practices in design, process, and quality control.
To paraphrase W. Churchill: Agile is the worst software development process there is–except for all the other processes that have been previously tried.