Tallan Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

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.

Share this post:

6 Comments. Leave new

Brian Hoffman
January 24, 2011 6:46 pm

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!

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.

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).

Tweets that mention Agile User Experience Design -- Topsy.com
February 9, 2011 6:31 am

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

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.

Love the diagram too, and agree with all comments, the time box suggestions are obviously tailorable depending on the product, project size, and user interaction frequency (especially in the military environment)
I’ve found that for efficiency purposes the designers don’t necessarily need to be working next to developers but the team must verify the design prior to any high fidelity design and usability testing.
i’ve also found that this process greatly reduces post demo rework and tech debt build up, allows for better products because all stakeholders have a clear vision of the product and can support design/performance improvements; the customers/users are happy because they were involved with the design and SEE their efforts at the demos; the sponsors take more ownership and assist in championing and are more understanding of changes in capability deliveries…etc.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>