Agile doesn’t do good UI does it?

There is an argument that goes like this. Give two development teams the same problem. Get one team to use a waterfall model, the other an Agile model and see what you get. Chances are that the agile team’s code will be more elegant and cleaner than the waterfall team but their UI design will fall short of the Waterfall team’s.

Truly incremental development of code, adding features as they are required (according to business value) is just not suited to developing a consistent and intuitive interface. Without a model to specify what the interface consistencies will be the developers will build the interface according to the requirements of the current feature, not necessarily how it contributes to the overall experience of the application. This is often compounded by listening to the wrong “customer”. All too often the people who buy software are confused with the people who use it. Buying decisions aren’t using decisions. (Anyone who has used Lotus Notes primarily as a mail client will testify to this: you are a captive users. If you as an end user could choose you would probably use something different, but you didn’t buy Notes and were probably never invited into the discussion about it’s purchase).

Big up-front design?
If “change” is a dirty word in Waterfall approaches then “Big-up-front-design” is a dirty phrase in the agile vocabulary. Anything that smacks of design and specification documentation before a line of code has been written is guaranteed to get the backs up of agile zealots. Yet it is clear that in an absence of any roadmap for a UI, the interface could go anywhere, and for a component as critical as the interface between the user and the functionality this can have disastrous consequences. Any feature is only as good as the users’ ability to use the feature. The underlying code the developer has written may gain the admiration of her colleagues, but if it takes the user twice as long to use the new feature because of a poor UI then any business value promised in the application has been destroyed. On a project iteration level, the lack of any detailed UI design can cause a number of issues ranging from inability to get customer sign off on stories through to rework (not refactor) as the UI metaphor starts to evolve.

In practice it doesn’t have to be like this. You don’t have to do “big up-front design” to get the UI right, rather just do enough to produce a model that drives the project forward (what original XP called “metaphor”); an understanding of what we’re all striving for, so we can make emergent design decisions that match that metaphor. The question therefore is what is “enough”? As always it depends.

The user interface is rarely specified as a requirement. It is just assumed it will have one. A starting point to getting the UI right is by capturing it as an emotional requirement. How are users to engage with the application, how do we want them to feel about it. By doing this we can quickly ascertain whether we are looking at a “world class, best in breed, competitor beating application;” an “application that will help transform the productivity of our employees [happy workers = productive workers]”; or “just a maintenance application that the tech guys use”. Business value can be placed upon each of these requirements and should be prioritised against feature requirements, both in terms of benefit (builds the brand, faster transaction times, fewer mistakes etc) and in terms of cost (interaction designer and graphic artist input on project team).

The GUI model
Once we are agreed that the UI is important to the success of the project, we can produce models for the look and feel of the UI.

Feel
The model isn’t the UI design for the application per se, but rather the vision and the basic structure of the UI for the application to fit into. It provides some guidance for developers and BAs as they begin to analyse and implement stories – some basic structure the application can fit into so we don’t have to struggle to invent so much UI stuff for each story. And, so the finished application feels a bit coherent. The model may have two halves, firstly the vision that illustrates the feel of the application; how the user will flow through processes, an information architecture illustrating where pages will fit. Secondly the model may be prescriptive; how the will the user know what to do, how will widgets work. The primary artefact of this model might be ‘wireframe’ sketches of pages – a low fidelity prototype that walks through key user journeys. Alongside this may be basic interaction patterns, for example how a search mechanism will work, how forms are to be laid out. Just enough to ensure consistency in the feel of the application and prevent avoidable re-work at a later date.

Look
Alongside the feel model is the look model. The developers need not care too much about this, provided their html is cleanly marked up. The feel will be created by the graphic artist and interaction designer, and implemented in the style sheet. Obviously if the goal of the application is to be a customer facing “world class” website, more attention will be required on the look than if the application is a development support tool.

The important thing with these two models is that they are sociable, communicable and flexible. The whole project must be aware of them; when new people are brought onto the project, the starting point of the communication should be the wireframe sketches. “This is the vision of the project… currently we are working on these parts… you see that tab – that is release two…” They may also change. We originally thought we’d have a ‘wizard’ to complete the process, but after showing the wireframes to users they wanted it all to go on the same page. But it is better to have something to hold the UI together than assuming that it will evolve through incremental development.

(These thoughts are not entirely my own – much of it is distilled from a ThoughtWorks email thread on UI design, agile methods, and BUFD… or BUFUID as someone commented).