Response: Why XP and UX have Something in Common

In many ways, I'm not surprised that Extreme Programming (XP) and user experience design (UX) approaches could be mated (see the UN news story: DIS 2002: Xtreme Programming makes Good Partner to User-Centred Design). Both use an iterative prototyping approach. The important thing to realize is that the Big Upfront Design that XP rails against is really _system_ design. So if you take the UX approach of designing from the "outside-in" i.e. designing the user interface first and then design the system to support the user interface, then they become quite compatible.

When I was at Scient, I was involved in a project where the tech lead proposed to use an iterative development cycle (I don't know if she was an XP adherent or not). Round 1 had HTML wireframes (all the necessary screen components in a rough layout, but no formatting) of all the templates needed. Step 2 wired in essential back-end functions to the wireframes, which were expanded to show each page. (This wasn't a huge amount of effort since pages were driven from the database.) Round 3 added the actual user interface,with look-and-feel, with most of the functionality complete. Any outstanding user interface issues were refined in the final delivery, which also had complete functionality.

Unfortunately the client flamed out before Round 2, so I can't comment on how well this approach would've worked. But the tech lead claimed to have used this approach successfully before, while minimizing the need for an extensive spec. Which could be a good thing, since I think most telephone-directory-sized specs are worthless because the programming team rarely actually reads them front-to-back. But, I'm also a bit leery of the "prototype is the documentation" approach. On another project where this ended up happening due to poor project management, the lack of documentation meant that when we got to QA, it was difficult to know whether what we'd intended to be built was what was actually built.

I think part of the documentation dilemma can be resolved by by rethinking how we document things. Most traditional IT specs I've seen are text-based, with lots of words used to explain something that could be more concisely - and more clearly - described via flowcharts, storyboards, annotated sceen mock-ups, etc. These are artifacts of the UX design process anyway, so ideally it doesn't take that much extra effort to refine it into spec documentation.

The biggest failure of XP is its viewpoint that you can iterate your way to good design - the "throw it against the wall and see what sticks" approach. Having worked in an enterprise environment I can sympathize with XP's proponents throwing up their hands and feeling like those wacky users can never tell them what they want.

But I'd argue that's in large part because their definition of "customers" overlooks the people who are really crucial to the process - the real users of the system, not their managers, not the business analysts, not the project sponsors, or other ersatz users - and these are the folks that UX's approach focuses on. Having a good idea what users really need to accomplish their goals (while also balancing this with what's needed to meet business needs) can bring the focus to the development process that XP seems to assume is unattainable.

Unfortunately, from what I've heard from UX people who've worked on XP-oriented projects, it does take a fair amount of education to convince XP programmers that Big Upfront Design _is_needed when it comes to designing the user interface (and its underlying interaction design and information architecture). Refactoring - a key principle of XP - may work behind-the-scenes, but it doesn't work for what's visible. In fact a key tenet of refactoring is that doesn't change the observable behaviour of the software, it improves its internal structure. Which needless to say requires that the programming object be well-designed, even if it's first implementations are kludgy.

While XP programmers understand this in terms of programming objects, we need to get them to understand this is true of the user interface. In essence the entire user interface is just a big collections of "objects" (screens), each with required inputs and outputs. These need to be well-designed before you start coding. Otherwise, just as changing programming objects can wreak havoc when other objects try to interact with it, changing fundamentals of the user interface in different releases (XP advocates smaller but frequent releases) can wreak havoc upon the humans trying to interact with it.

Which is where UX's design phase comes in. It's true your initial design may not be perfect the first time, which is why UX works best when you take an iterative approach - and that's where things like card sorting exercises, paper prototyping, etc are just as necessary as the programming prototypes. Sometimes these need to precede the programming, sometimes they can proceed in parallel. But failing to do them results in a product that looks like it was munged together as various things were tried out.

George Olsen
User Experience Architect
Interaction by Design

All change at the top for System Concepts
Source: System Concepts Ltd, 3 July 2009
 
Leslie Fountain has been promoted to joint Managing Director of leading usability consultancy System Concepts.

Life in UCD immortalised in fiction: you couldn't make it up
Source: UN, 2 July 2009
 
Sarah Herman's fictitious book on life in a user-centred design company has hit the shelves and The Guardian's book pages...

Interfaces Magazine - Issue 79: The Education Issue
Source: Interaction Group, 1 July 2009
 
The latest issue of Interfaces is now available as a free download from the Interaction Website.

Two new Behavioural research Tools from Noldus
Source: UN, 30 June 2009
 
Tool updates make on-site behavioural data collection easier.

Cell Phones that Listen and Learn
Source: MIT Technology Review, 29 June 2009
 
New software tracks a user's behavior by monitoring everyday sounds.

Top Six Don’ts for Usability Testing
Source: FutureNow Inc., 27 June 2009
 
Six tips for creating quality usability tests to ensure useful feedback from testers.

Usability: ‘Lovely software. But I can’t work it’
Source: FT.com, 26 June 2009
 
In a recent survey by Global Graphics, 77 per cent of office workers estimate they lose up to one hour a week because business software is difficult to use.

And what do you do?
Source: Dexo Design, 25 June 2009
 
How do you describe your job role? Here are the results of a recent 'Preferred UX/UI Title' Poll.

Most Doctors cite Usability as critical to Electronic Health Record Adoption
Source: TMCNet, 24 June 2009
 
It's all about 'meaningful use'.

Glossy monitors look good but can hurt
Source: QUT, 23 June 2009
 
A new advisory cites research which suggests high gloss monitors make users sit awkwardly.