There has been a lot of talk of the influence of Agile development on user-centered visual design. The Agile manifesto says this: “Working software is the primary measure of progress.” With software, it is very clear when something is working or broken. With visual design, it’s a little harder to tell. Of course we can all tell good design from bad (or can we?), but empirically defining something as “working” or “broken” is much harder to do in the realm of visual design. Here is a sliding scale of the possible outcomes of the design of the landing page of an e-commerce site selling pickles:
1. Broken design: when customers are turned away either by poor design, poor functionality, both, or just too many distracting elements such as ads and pop-ups on the page
2. Somewhat functional design: when customers are intrigued but not likely to return. This could be either due to doing too little (usually the case) or doing too much (too much shock value)
3. Design that “works”: when the customer is surprised and delighted. The visual design is on the money, and the site functions smoothly.
As designers, we are accustomed to working with a blueprint, a plan. Some of us know what the finished thing looks like even before we open a blank Photoshop document window. How do we reconcile this visually final thought process with the highly iterative methodologies of Agile development?
http://www.boxesandarrows.com/view/bringing-user
http://37signals.com/svn/archives2/extreme_programming_vs_interaction_design.php
