What are some successful examples of UX and the Agile Development process playing nicely together? Traditional agile doesn't usually account for it.

  • 8
    Agile accounts for anything that delivers end user value. If the Agile team you're working on is not accounting for UX, that is to do with the team, not the process. Jan 4, 2012 at 19:24
  • 1
    Related post in Programmers SE Jan 4, 2012 at 20:24
  • My one word answer would be 'parallel', especially in an agile development environment. The reasons are all too obvious to those who have been into it.
    – Kris
    Jan 5, 2012 at 5:07
  • 5
    Day 0 - see related question from Jared Spool here on ux.se How do you prevent scope creep in agile projects when usability testing? Jan 5, 2012 at 7:21
  • I think you should repeat the title in the body of the question. The question is so short, we have presumed it is the same as the title and did not even read it in the first pass!
    – Kris
    Jan 5, 2012 at 11:52

10 Answers 10


UX, along with all of the other disciplines involved in your project, should be involved from day one. The team should strive to work in parallel with each other as much as possible. To achieve this, it is imperative that the UX resource(s) participate in all daily Agile rituals and meetings. This is especially true for backlog grooming and prioritization. In addition, the UX resource(s) on your team should open up the design process to the entire team allowing for input and concept ideas to come from developers, product managers, QA, marketing, wherever.

Through these group brainstorming sessions, the UX designer(s) become facilitators and stewards of the design. Their goal is to communicate a vision for the product by building a shared understanding across the team. This shared understanding comes about through regular conversations and discussions around early design ideas. These ideas should be validated with customers and stakeholders early and often to ensure that the team is spending time refining and building the right solution. To put it another way, the team should be minimizing the amount of time they're wasting pursuing the wrong solutions.

Lean UX is one approach to solve this Agile UX integration problem. The ideas espoused by Lean UX (at least as I've defined it) require the UX design teams to work in a much more transparent fashion then they've had to in the past. In addition, the process they employ must be far more inclusive than the more traditional ways of designing. These processes manifest in the forms of "light" deliverables (if any) like whiteboard sketches, rough wireframes and prototypes of the experience (that ultimately become "the spec" for the product).

There is a ton more detail in an article I wrote for Smashing Magazine, Lean UX: Getting Out Of The Deliverables Business.


My response may be biased because I run a pure UX research, strategy and design firm, but as UX practitioners, we're involved in agile projects at the very beginning. As zsiberian stated, getting ahead of development by 1-2 sprints is the only way to keep the process agile. UX involvement in the iteration planning session allows the user story definition to get ahead of the front end development. In our experience, we get 1-2 sprint jump on development by cranking on the conceptual / interaction model, branding/visual design concepts and the first 1-2 user stories (wires) when the development is identifying and standing up the various back end technologies / architecture. Hope this helps.


Agile seems to come in a variety of flavors, but the theory is all the same, and based on that theory, UX is part of the mix from day 1...as is business line owners, customers, IT, marketing, etc.

I usually find the problem is when UX is still doing waterfall but dev is trying to go AGILE. Lots of UX teams still want to pump out piles of wireframes, which is the antithesis of what Agile is supposed to be.

A great place to start is to google 'Lean UX' and read up on some of those concepts. In my opinion, 'Lean UX' is a clever way to brand 'Agile' so that UX teams will embrace it.

  • Thank you, this is a great tip. That is the current challenge. Jan 4, 2012 at 21:42
  • How true! -- 'when UX is still doing waterfall but dev is trying to go AGILE'. And, +1 for 'Lean UX', gotta check that one out rightaway.
    – Kris
    Jan 5, 2012 at 11:48
  • @Kris +1 for Lean UX. Don't miss Jeff Gothelf's answer below. Jan 6, 2012 at 0:47
  • @PatrickMcElhaney: Thanks, it sure's a learning experience.
    – Kris
    Jan 6, 2012 at 4:29

An approach which I find very fitting on where the UX role should intervene in Agile (Scrum in this case) development is:

  • In the product backlog, translating end-user feedback into specifications.
  • In the sprint planning meeting, providing mockups so both the Team and Product Owner have a better idea of what will be built and how.
  • At the end of each completed task, where sometimes tests or Unitary Testing is run, also Usability and UX should be tested.
  • In the review meeting, to test overall UX and taken into account for next increments.

The role of UX in Scrum

You will find a lot of presentations about UX+Agile in SlideShare.


From my own experience I would say you work in a parallel stream ahead and after Development and if you take it literally not in Agile Development at all.

Why? Because in my understanding Scrum, which we do at my company, is about production and development in iterations. But tasks itself not. You take a single task and work on it until its finished. Then next one. Thats how coding works. As you said Traditional agile doesn't usually account for it.

But Design works different, because you have Iterations in tasks. So, I found myself working on task cards, putting it back to ToDo Column (Scrum), and for refinement taking it again, and so on, until its finally done. (Actually its the way I work because I can't finish Designs on a single day - I like to have a fresh view some days later.) So, in Design you have iterations in tasks, but thats not possible in Scrum. and if you take a close lok at Naoise's scheme you will see no UX Designer in Scrum Sprint only beginning and end.

I think thats the reason why most Designers work in parallel streams and Im not sure if they work with Scrumboards for Design as well. Design is still a little Waterfall - you need to think and know what you are doing, you need a glimpse of a big picture, you need to think and try, not just doing. Lets say its a small, quite vivid waterfall.

I had some trouble to get it running well (working in a small team) and at the moment I think best suited for Design in a Agile enviroment is Kanban, but haven't tried it yet. I like Kanban because you can merge working process of both, Design and Development, or open a Kanban board for Design only. Kanban and Scrum are quite close, but the main difference is, you can place as many columns as you like to, not just Todo and in Process. enter image description here

You could put columns like Analysis, Raw Design, Fine Design, Testing, Production here to scope Designers workflow.

Kanban links: What is Kanban and Kanban and Scrum - making the most of both Picture source the latter pdf.

I know this answer is going slightly to be offtopic with this Kanban stuff. But its agile and development/design process as well.

  • +1 for introducing me to Kanban...something I had never heard of before. Off to research it!
    – DA01
    Jan 6, 2012 at 1:30
  • I've been running UX in a Kanban-styled project for a year. Works beautifully, as long as you apply Lean UX-thinking and deliverables. Jan 17, 2012 at 12:59
  • Ah, it works ;) May I ask, what colums you have? How many and what tasks? Any recommendations?
    – FrankL
    Jan 18, 2012 at 10:29

Ideally it needs to start as early as the final stages of the opportunity pursuit when the UX lead is invited to the closing meetings with the potential client and has reviewed the SOW. That does two important things: gives you voice in conversations about scope, which in tern gives you heads up about project and what it's going to take.

Christie - I know you asked specifically about "the development process", but that sort of implies that you've been through the Discovery (6 - 10 weeks) and have already cranked out an approach and few high level wires to stay 1-2 sprints ahead.

If you are brought into a picture by the time development has started - it's no longer Agile, you'll need to run pretty fast to get ahead of the dev team.

  • In theory that works, but are there any tips to get it to work successfully? Many people think this can be attempted through iteration. While others think the UX needs to be done up front. What are some ways to get everyone to buy into the process? Jan 4, 2012 at 19:48
  • What are some steps you would go through to align ux and iteration with the agile process? Jan 4, 2012 at 20:00
  • Well, 1. I wasn't speaking from theory, rather from personal experience on several projects. 2. Iteration? Absolutely, but only when it's properly aligned with the Agile process. 3. All of UX upfront? Not going to work because you need #2. Getting everyone on board - that is a strange question if you joined an Agile project, the project owner should know the process and where UX fits in, if he doesn't he needs to pick up amzn.to/2Bue0T
    – zsiberian
    Jan 4, 2012 at 20:08
  • Basically the idea behind Agile and UX is whatever you (UX) produce, the dev team builds, and while they are doing that you're working on the next chunk for them to build. So it's a dance where you have to stay a bit ahead (I mentioned 2 sprints before). I would ask to participate in what is called "sprint planning" and get familiar with the project plan - i.e. what gets developed when and how fast. That will give you an idea of how you want to pace yourself, what deliverables need to be done when, etc. It's hard for me to speak without knowing the context. Hope it still helps
    – zsiberian
    Jan 4, 2012 at 20:12
  • I do find it hard, but not impossible, and strangely much more pleasant in the end because it's a bit more structured and you're on the hook for the exact thing you and the client discussed extensively during sprint planning, no more and no less.
    – zsiberian
    Jan 4, 2012 at 20:18

this is not bad at all



Coming from agency-land, agile was a new concept for me. But the way it's shaken out after 6+ months in an agile shop, is that I try to get out in front with wireframes and requirements (I'm about a month to six weeks ahead of the dev team). There's a kickoff meeting in which I get a lot of feedback from Design and Dev, another iteration or two, then those docs form the basis for the sprints. After the release goes into alpha, there's a period for review, usually some remedial WFs, then more dev and progress to beta, QA and final release.

Lighter weight projects get correspondingly "leaner" documentation.


Initially I was finding it difficult to match my standard ux design process to Kanban, but after a little while it started to work. It took a lot of changing and rethinking stuff though.

This was a bit of inspiration for me: http://kanbantool.com/blog/kanban-for-ux-design


UX is something you have to test actively from day one, and keep on testing while the product develops.

Beware! It's super easy to forget about UX testing while you are pushing the developers hard and everybody is working like hell in your team.

UX testing has to be part of your Definition of Done! Meaning that no "story" should be considered as Done, if UX testing was not finished. (obviously note necessary for backend stories)

If you don't have a designer or UX expert in-house. You'll need to do it yourself. There are tons of great resources online about UX, so Google like hell.

These days a smooth UX is not a differentiator. It's a must have for new products. So it can make our break your business!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.