Agile User Experience: If you don’t have a user, invent one of those too…

Noel Rappin, Thursday, January 24, 2008 @ 2:35 pm

Following up on Brian's point...

A customer proxy of one kind or another is also important in integrating Agile practices with User Eexperience Design.

One of the long standing issues in combine Agile development with User Experience Design is just the differing time cycles between Agile developers, who are running on a test, develop, refactor cycle that could be mere minutes long, and the UXD designer, who is working on a longer, perhaps more traditional, cycle.

The problem comes in when the developers start making coding decisions for the interface. Without immediate feedback from the UXD designers, the developers are often left to their own devices for the initial versions, with revised designs coming weeks or months later.

Our goal is to keep the development team moving forward with current feedback from the design team. For exactly this reason, the original XP book listed Onsite Customer as a core XP practice. However, that's not always feasible, and in any case for User design you want the user's feedback, which may not be the same as the customer's.

What we try to do is use the idea of a customer or user proxy to allow us to have incremental refinement of design, and allow the development team to get quick feedback and continue with the next fine-grained task.

When a developer has a usability question, the developer asks a team member acting as a user proxy. This is either an analyst on the project or one of the designers. The user proxy makes a decision on the question -- if not a final decision on all details of the problem, at the very least a consensus on some aspect of the problem that the developer can do next. While the developer does that task, the user proxy goes off and consults with the design team and the customer.

Ideally, by the time the developer is ready for the rest of the task, the user proxy has more detailed requirements and design for the developer. The key is making sure the developer's next step is always covered.

This does require some effort from your team -- the developers have have awareness of usability issues and concerns and the design team has to have the ability to respond to developer concerns quickly. Again, though, the design team doesn't need to have all the answers at once, they just need to be able to give incremental details to the developer.

(The image of the floor appearing directly underfoot is from the ad campaign for Gatorade G2)

Have I mentioned my upcoming book Professional Ruby on Rails, yet? Available mid-February wherever fine computing books are sold.

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment