For me agile software projects is all about maximizing the customers’ value of the software being built by encouraging and incorporating feedback, new features and change requests as quickly and cheaply as possible. To achieve agility we adopt agile project process like Scrum, which helps us manage and prioritize the features of the software we are building into short iterations. To build a flexible code base that enables us to quickly add, remove or change features throughout the project we adopt agile development practices like Test Driven Development. We try to follow good design principles like SOLID, and we build and integrate our code frequently using Continuous Integration. But what can we do to become more agile in the way we build the User Experience (screen layout, navigation structure, colors and graphic design, imagery, error messages, texts and labels) of our application?

On most of the software projects I have worked on the User Experience have been left up to the developers to decide. Towards the end of the iteration we bring in the customer for a demonstration of what we have built, implemented as running HTML, Windows Forms or perhaps XAML code. In many cases the customer immediately starts focuses on the tiny (perhaps unimportant) details of the UX. Like, “the title should be bigger and bluer”, or “the save button should be 4 pixels to the left”. One of the reasons for this reaction might be that by demonstrating a complete implementation of the UX straight away the application looks too complete, and the customer might feel that it is too late in the project to make substantial changes to the UX of the software. However, if this does not happen and we do get good feedback, suggesting that we need to rethink the UX of the application, the reaction from the development team might be hesitation. If you have put lots of effort into building the UX of the application you don’t want to throw it away. And in contrast the business logic of the application we do not have the same refactoring and testing support for the UX of our application as we do for the other parts of the system, making it harder to make big changes with little effort.

One way to work efficiently with UX in an agile software team is to create low-fidelity prototypes. These prototypes can be created using pen and paper, or tools like Visio, PowerPoint, Balsamiq or SketchFlow. Low-fidelity prototypes feel less finished, but are at the same time concrete enough for the customer to really “get” the concepts being prototyped. Using low-fidelity prototypes the customer is more likely to give constructive feedback about the important aspects of the UX, like how the screen layout and navigation should work, which fields are needed, or how we are going to display error messages, than if they were presented with a high-fidelity prototype or near complete version of the software.

The developers are going to be less attached to a low-fidelity prototype, as the amount of effort put into it is far less compared to a real implementation done in code. Using prototyping the development team and the customer can do multiple iterations trying out different ideas and concepts for the UX, hopefully coming up with a great solution in the end. After all, good design is all about exploring multiple ideas, before narrowing it down to the right design for the problem. Good design is not about picking the first solution that pops into a developers mind.

I think UX prototyping fits perfectly with agile software development, and should be a natural tool for any agile team building software that interacts directly with end-users. My next blog post is going to be more concrete, giving an introduction to two great prototyping tools: Balsamiq and Microsoft SketchFlow.