OK. Let's say you're working on a textbook scrum project. You've got a scrum master collaborating with a product owner. The next sprint is UI-heavy - by the time your coders start building screens, you really want to have some idea what they're going to look like.

Who does the wireframing, and when? The product owner? Somebody supporting the product owner? The scrum master? If you have a UX expert, do they work alongside the coders after the sprint has started, or do they supply wireframes & mock-ups up-front that sit alongside your story cards and constraints to guide and inform the work the developers are doing?

I'm pretty sure we need some UX help, you see, but I'm really not sure where to apply it...

EDIT: Let me rephrase the question.

How do you deliver consistent, high-quality user experience on an agile project?

  • 1
    "textbook scrum"? You mean "rigidly agile"? Agile done "inflexibly by the book"? Isn't that contradictory?
    – S.Lott
    May 23, 2011 at 18:59
  • Wouldn't you just pick the person(s) that know what they're doing and have time?
    – JeffO
    May 23, 2011 at 19:32
  • 1
    UX != wireframing, and UX is much larger than a sprint May 23, 2011 at 20:42
  • Defining the UX role and responsibilities would be a useful starting point in this question. In the broadest sense, UX is everything the user experiences and goes well beyond what the code does and is often the responsibility of multiple people.
    – Jim Rush
    May 24, 2011 at 2:48
  • The keynotes of OGN17 have a talk about UX you might like: oxford.geeknights.net/2010/apr-21st
    – Matt Ellen
    May 24, 2011 at 13:35

7 Answers 7


The interaction designer

UX != UI You need a experienced interaction designer to deliver good user experience, contrary to popular belief that is not a programmer. For all of you programmers who think they can do UX (that includes me) let me say this. Getting good at interaction design requires at least as much time as getting good at programming. How much time have you spent doing pure interaction design?

In the initial phase it's the interaction designers responsibility to:

  1. Extracting the actual goals of the solution from the product owner
  2. Define the personas that will be using the solution.
  3. Write scenarios that are stories on how the solution will be used.
  4. Compile a design document that leaves little room for ambiguity from an UX standpoint

During the project it's the interaction designers task to make sure that those guidelines are followed and address any additional issues that will arise (and they will).

Many programmers will take afront to this approach I'm sure since everyone feel that they're the exception that can design "wonderful" interfaces, you're probably not. On the other hand a good interaction designer - programmer relation is often very nice for the programmer as well as they don't have to fight against a "stupid specification". Unfortunately good interaction designers are hard to find in my experience but they are out there.

As always I deeply recommend Alan Coopers books on the subject ("About Face" and "The Inmates are running the asylum")

  • +1 and and I also heartily recommend About Face. I should also say that there is no reason one person couldn't be an excellent programmer and an excellent UX designer and I know several people who have switched between the two career paths. The trick is what are your priorities on the project. It would be extremely difficult to dedicate enough hours to both tasks and not shortchange one or the other. Especially when you're trying to agile.
    – jiggy
    May 24, 2011 at 18:06
  • jiggy: there's one reason: time ;) But I agree, there's nothing special about neither design nor programming but it's a matter of hours of experience. If you're good at both you're either old or have no life. I try to justify my own foolish beliefs of competency in both areas with that I'm little bit of both :) Sadly though there's a common Dunning-Kruger effect of people thinking design is "easy" and that they're good at it
    – Homde
    May 25, 2011 at 8:49
  • You lost me when you recommended "Inmates". I hate that book because he pushes so much blame out to programmers absolving management. Cooper is also notably poor at giving credit to many of the people who invented techniques he popularised.
    – Andy Dent
    Mar 19, 2012 at 7:03
  • If you think getting good at interaction design is as hard as getting good at programming you must have some sort of natural talent for programming :/
    – robert
    Nov 20, 2014 at 15:03

I suggest to organize work of the UX guy in the same way as the rest of the team. He should be considered an equal member of the team, participate in standups, and communicate closely with programmers.

Ideally, the mock-ups should be done at least one sprint in advance, but for smaller features it might make sense to consider creating mock-ups as a subtask of a story planned for the current iteration.

As always with agile, use common sense, experiment with different approaches, and stick to the one that works well for your particular situation.


In my opinion this is somehow special case which must be handled in the special way. Scrum master will definitely not participate in this - it is not his role at all. Team is usually group of developers and most of them has no experience with UX and it will be waste of their time to force them to this. You will hire UX expert and the expert will not be the part of the team - team should be cross functional and UX expert will probably not be a developer. Also UX expert will not be on the project for the whole its duration. The UX expert will work with the product owner one sprint ahead to prepare mock-ups and wireframes for upcomming user stories so that team knows what will have to be done in the next sprint - mock-ups will be available during the planning meeting. There should not be too much waste (except rare occasion where requirements from customer will change a lot) because the product owner knows what are the most prioritized user stories which will be done in the next sprint.


I did some additional research because I knew I read about this somewhere and I finally find it in Succeeding with Agile: Software Development Using Scrum by Mike Cohn. Mike discusses exactly the role of UX designer in the team. His initial description is similar to mine and he consider its as natural shift when company change the development method from waterfall to Scrum but later he concludes it as not recommended way. The reason is that if UX designers are not part of the team they can think about themselves as the separate team and they don't have to share commitment of the development team.

In spite of this @Adam Byrtek's answer looks like the correct one. Make UX guy part of the team and let him cooperate with developers on currently implemented user stories. It will not take all the time of the UX guy so he will also cooperate with product owner or customer to prepare mock-ups and wireframes for upcomming one or two sprints.


I am subscribed to Jakob Nielsen's alertbox (mostly because of his criticism on annoying web design practices) and I recall I have recently read some articles on topic (although I hardly have a slightest understanding of the whole agile development process), maybe they would be of any use for you:


For "textbook Scrum":

First off, Scrum Masters don't collaborate with Product Owners - well not in any sense other than that the entire team, including the SM and PO collaborates to build the system.

Secondly, Scrum teams are supposed to be homogeneous with cross functional team members. So you wouldn't have a "UX Guy".

Also, you probably wouldn't build out the UX a Sprint ahead of the functional code. Features are delivered completely within a single Sprint. If the UX associated with a feature is too complex to deliver along with the functional code in a single Sprint, then you carve the whole feature down to something that can be done, including the UX elements, in a single Sprint.

  • """Secondly, Scrum teams are supposed to be homogeneous with cross functional team members. So you wouldn't have a "UX Guy".""" - not really. It is OK to have specialists such as graphic artists, UX, SQL, documentation who are swing players.
    – Job
    May 24, 2011 at 2:54
  • 1
    There's a special circle of hell reserved for software whose user experience was created by whichever coder had a couple of hours free. May 24, 2011 at 11:45

Who does UX on a waterfall project? Who does mainframe development on an XP project?

The project methodology doesn't matter. Every technology project requires certain specialized roles. Sometimes, a project can get away without a fully licensed and bonded "interaction designer" (whatever that means). Sometimes you do need someone that specialized. But the same could be said for every other role.

So onto your second question of how you deliver high quality user experience using agile. We managed it in the last scrum project I was involved with by involving the business analyst and the customer early and often. Also, we had a developer that had a particularly good eye for UX. He tended to make minor tweaks to the UIs the devs were working on after they had done commits.

We didn't deliver perfect UX at the end of every sprint. The demos generally exposed an issue or two from a UX perspective. But we fixed those for the next sprint (if they were worth it to the customer) and by the time we released to production we had a very solid UX.


If by UX, you mean user interface designer, they are just another role or resource for the team. User Interface design, like any design, cuts through a project. There is a reasonable amount of architecture/design work that should be done up front and there is an amount that can be done as you go along.

It should be noted that UI design tasks often don't fit into the same scope as a development sprint. In designing a UI component, the design may take numerous sprints to implement.

In practice, I tend to find UI/UX designers need a reasonable lead time to deal with aspects that must be consistent across the solution. I like to think of it as software architecture. Specific component design can often be done a sprint before implementation, but I tend to find that once the designers get underway, they can far out pace implementation. Later sprints tend to be good places to implement/explore look&feel as well as get usability feedback as the solution begins to take shape. Results of these later exercises are fed back into the planning of the next sprint.

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.