Agile User Experience Design


Integrating Agile methodology and User Experience Design has long been a challenge. This diagram shows how the two can work in harmony with each other to produce profitable products that meet the demands of stakeholders.

This entry was posted in User Experience, User Experience Design and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

4 Comments

  1. Posted January 24, 2011 at 6:46 pm | Permalink

    I’ve been researching processes that integrate UX with Agile and this is the best diagram I’ve found. Are there any details you can provide or caveats you’d care to share from using this with actual client projects? Thanks!

  2. Krish Mandal
    Posted February 1, 2011 at 10:02 pm | Permalink

    I’ll be explaining this diagram soo…I hope. It certainly needs a little discussion, but our aim was to just get it up there for everyone to see, first.

  3. Posted February 1, 2011 at 10:41 pm | Permalink

    I like the general approach, and I think it makes sense to say that UX generally works a sprint ahead of development. But, one of the things that is hard to represent in any of these kinds explanations/diagrams is that there is often a disparity in effort between design and development for the same features. For example, “undo” might take 5 minutes of UX time (“here’s the undo icon!”) and weeks of development effort. Another 30 seconds and you have a “redo” icon… and potentially a whole lot of additional development effort (“when we built undo, redo wasn’t a requirement!”). So in practice, either the process is much messier (because the UX and development efforts aren’t really in that close of lock step) OR you have people try to stick to the process literally and the work expands/contracts to fill the available time (I have a week to work on this, so you a week’s worth of design or development on it, regardless of whether it should really take a day, a week or a month).

  4. Posted February 11, 2011 at 3:06 pm | Permalink

    @Adam:
    You are correct. You have hit upon one of the biggest problems in Agile working with UX. It’s not going to go away soon, it’s one of the reasons it took a long time for us to develop this diagram. Furthermore, as you might have guessed, this diagram does not / cannot be the be-all-end-all of Agile-UX relationship diagrams. The problem is that you need a few diagrams to really fully explain all that needs to happen as opposed to all that does happen. Very briefly, the middle blue “stream” between the dev and ux tracks labeled as the Feedback loop is designed to mitigate the problem you are spotlighting.

    To address your thoughts: You’re right of course, in the case of the Undo/Redo example, what takes a UX person 2 minutes to think up and add to the wireframes is certainly NOT 2 minutes in development time. We at Tallan firmly believe that it’s imperative for the designer to have a good sense of the technology that is being used to develop the application, as well as some solid grounding in basic programming and data structure principles so that no UX team member “pulls things out of a hat.” It leads to another diagram I’ve often shown to clients to make them understand how best to marry UX and development stages — you need one member of the product business team, at least one developer, and the UX designers to sit together to really design things right because you do not want to simply throw features and options into the fray without thinking about the consequences to the schedule and budget. But that is easier said than done, especially when the developer on the committee is also responsible for output of production code.

    Moreover, if you’re using Scrum to organize and develop — and are doing it right — some feature that a UX designer might have thrown into the mix is surely to get ousted based on the triage of the backlog. If you don’t constantly review your backlog in relation to the new things that are being added to it, all you’re doing is making a ToDo list, not deciding which are the most important features to work on.

    You only have so many tokens. You put something in, you take something out. Unless your budget, timeline, or manpower increases (and even then it’s not a sure thing) you cannot add more to the development schedule and stay on target.

One Trackback

  1. [...] This post was mentioned on Twitter by donguy, UX Feeder. UX Feeder said: Delicious: Agile User Experience Design: http://bit.ly/eQ8M2W [UX] [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*