Our company is using the agile development method, which for UX designers can initially be a real challenge. (For those of you who aren’t familiar with Agile: http://en.wikipedia.org/wiki/Agile_software_development)
Our agile consultant recently passed these two articles about how UX can use Agile to its advantage:
Both of these articles had really good suggestions. Here are the ones I that stood out to me and could be applied to projects not using agile as well:
“Best practice” suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1. The iteration zero is deservedly becoming an accepted way of buying time, but some teams are extending this idea with an additional mid-project iteration zero, in which no user stories are delivered. Instead, developers can tidy up code and plan next steps, while designers can revisit the vision and check that brand, aesthetics, and experience are coherent across the site so far.
Bill Buxton remarked that a problem with Agile development was iterating without ideating. I'm paraphrasing here, but basically Bill asserted that Agile teams lock onto a solution and iterate to refine it without considering that there may be a better solution out there. He's right, but not just about Agile teams. I see a fair number of designers guilty of the same behavior.
Today it's easier to respond to Bill's call to action with some concrete practices like Adaptive Path's Sketchboarding and Jeff & Jim's Design Studio approach. Desiree Sy described using interns to prototype 10 or more design solutions to a possible design problem.
The smart people at salesforce.com have taken RITE and cranked the dials up to 11. They build html prototypes and iteratively test and repair them using remote usability testing. They'll complete several rounds of this on each chunk of work before it goes into a development time-box.
In an attempt to travel light, I often hear UX people describe their prototypes as their specification. It's common to deliver only the prototype, or ideally the prototype + a discussion with the team building the software. During the discussion annotate the prototype by hand if necessary. No need to produce detailed documentation.
Cultivate a user validation group for use for continuous user validation. Use customer time to do some contextual inquiry style observation and interviewing, then sit down and review a prototype for something that may be built in a future iteration, then to review the working software testing features just built in a previous iteration. The trick here is to leverage that user face time for research and validation. Don't segregate your work.