Agile UXD

Alice Toth, Thursday, May 31, 2007 @ 1:33 pm

Instead of the typical hand-off of deliverables accompanied by a firm handshake and a heartfelt "good luck!", recent projects have us iteratively engaging with both the business stakeholders and the developers early on in our design process. Yes, we've gone agile and that's not necessarily a bad thing.

Once a project has the green light, we begin by directly working with development in an iterative fashion, bringing them into our process and getting their input early on in the project lifecycle. First up, translating the initial requirements into visuals -- defining actors, diagramming the user activities, task flows and personas. During this flurry of visuals, we're presenting and discussing the diagrams, etc., with the team to determine that we’re on target and to get their input. From here, iterations of screen flows and wireframes are diagrammed and discussed with the developers to demonstrate how the presentation layer and user interaction are being envisioned, get their input, check that requirements are being met, that the back-end can support the design, etc., etc. Rinse and repeat.

In a way, we're not exactly breaking new ground -- we're just
rearranging the timeline.  We're engaged in the same iterative process
as before, except now we're creating our designs before all
requirements have been identified and our early discussions have
expanded to include development. The fast pace, though, allows for
quick iterations with new requirements being uncovered and defined the
further we go into the design.

One major advantage with this method is that we're learning about
any back-end restrictions sooner rather than later.  Nothing is worse
than finishing up a beautiful design and tossing it over the wall, only
to have development take one look at it and say it can’t be supported
by the current configuration. Agile, by its very  nature, promotes
teamwork which means within the project team we have more of a culture
of "how can we solve this" rather than "us v. them".  In addition,
developers bring to the table a wide knowledge of what’s possible at
the presentation layer so it's to our advantage to involve them during
the design phase.

As with any new process, we're working out the kinks and improvising as
we go along. However, the main advantage to working closely with
development is that it gives us direct input in keeping the demands of
the presentation layer aligned with the needs of the users.

user experience design

Comments: 2 so far

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

1. 

   Thanks for an interesting post. What are the biggest challenges you’ve had so far in incorporating the Agile approach?

   I’ve written on this topic before here:
   http://www.infoq.com/articles/agile-useability-churchville

   Always curious how other pracitioners are merging UX and Agile methods.

   Comment by Dave, Thursday, June 7, 2007 @ 5:23 pm

2. 

   For me, one of the bigger challenges is having to design and develop before all of the business requirements are known. As you stated in your post, you don’t really want to refactor the UI with each public release.

   So we need to create a UI that’s flexible enough to accommodate change gracefully without necessarily knowing if the changes will be incremental or a 180. Naturally, this can be easier said than done. The key is having an entire team that’s committed to having change (or iterations) as part of the process.

   The value with an agile UXD, however, outweighs any discomfort. We start getting user (including developer) feedback early in the development lifecycle where we can optimize the design or a workflow at less cost to the project. In the end, I believe we create a more usable product resulting in subsequent releases that can focus on features, not fixes.

   Comment by Alice Toth, Thursday, June 7, 2007 @ 11:15 pm

Leave a comment