Monday, July 13, 2009 11:57 PM
A few weeks ago I held a talk at the Italian ALT.NET Conference and my talk was about how to design the User Experience of an application, but soon it turned into a hot discussion about how to adopt the approach I was explaining, building the prototype of the UX first, when using an Agile development methodology.
From the objections I received I understood that Agile developers think that UI prototyping is against incremental process, but this is not true.
When it come to prototyping the UX of an application, it doesn't mean you have to prototype the whole application in the finest details. I think that is possible to prototype the concept of an application, with the macro functionalities, the graphics and usability behavior and give the imprinting to the client. Then when the project enters in the development phase, you can use prototyping to design and define the UX in a more detailed way and so develop the single feature in a vertical way.
You can design the functionalitis with the schematics, static graphic and functional mockup and put every single functionality on the client approval process and then implement it. It isn't a closed process, there are a continuous dialog between designers, developers and clients.
Talking with a more precise Agile terminology, you can see the prototypes are a better way to define use cases: a way that shows the customer what he wants, not only from a functional standpoint, but also from a usability one (this is an interesting thought by Simone Chiaretta ). And since this use case is more similar to the final implementation than a bunch of sentences, the customer can understand earlier in the process that what he told you want not what he meant, or that he wants it in a slightly different way. And since this brings earlier in the process something that without prototyping would have been discovered only after the first iteration of the given feature, this save both you and the client time and money.
Obviously, since you are building something concrete (still a kind of sketch, but more concrete than just text) refactoring of the main plan is necessary. Since there are always continuing changes during a project, the process without a global view is too dangerous as it might lead to inconsistencies in the overall design and user experience of the application.
My grandmother says: the truth lies in the middle. Don't think in absolute way, and don't think without a global and elastic mindset. Approaching this you have to adopt the approach that works best with your team: every single project, like every single team, has a particularity that makes it unique.