Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

All the discussions about Agile UX relate to how we adjust UX Activities to an agile development process but I want to know how we can turn UCD in to an agile process that supports the development activity.

Any ideas for Agile UCD?

share|improve this question

4 Answers 4

The iterative design that characterizes UCD fits very well with the iterative development that characterizes Agile. You want your design iterations to dovetail with development’s iterations.

But before that, you need time up front before the developers start coding to do the preliminary research to identify the user goals and points of pain, and to get a vision of the product. However, I recommend you start designing (for yourself only) before you finish your research. This will help you focus your research, getting it done sooner. Sometimes, even before you’re done you’ll have the outline of the product from the users’ perspective to hand off to developers so they can start on the backend necessary to support it.

Once you have this foundation, you run one step a head of the developers, cranking out mini-designs, testing prototypes with quick-and-dirty usability tests, then passing scribbled wireframes on to developers. At a certain point of development, the code created by the developers is your prototype, and you’re in sync with the developers. Usability tests are then part of the usual stakeholder feedback that’s part of an agile iteration. At that stage, you begin to fade back, fine-tuning the UI rather than providing strategic direction.

More on fitting UX/UCD with Agile and fitting Agile to UX/UCD:

share|improve this answer
    
Agreed. I always considered UCD a form of Agile (in spirit, at least). –  DA01 Jun 28 '10 at 16:24

I think its important not to confuse Agile with Scrum. To answer this question: Think about UCD and then read the Agile Manifesto Principles below.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Personally, I read these and think:

  1. Are there designers on this team they describe?
  2. How much time does a designer have to figure out the UI before developers are saying they want to deliver working software quickly?
  3. Information architecture changes are extremely painful. Do they really welcome them late in the game?
  4. Is this really how the best UX is created?

I was very UCD at Marketo and delivered a great product with great UX. Our process was kinda messy. We didn't call it Agile, we called it Fragile.

My answer is: Developers aren't designers and neither are business people. Does Agile get in the way of great UX? Yes, sometimes. However, the ability to redo things is critical and I wouldn't trade it for waterfall.

Here is a chart that shows why I like the Agile methodology over Waterfall.

share|improve this answer
    
I agree that developers are designers but i don't agree that UCD is waterfall, is that what you meant? I also don't think that agile gets in the way of good UX. I just wonder how we can make UCD a part of agile development? –  Matt Goddard Mar 4 '10 at 21:43
    
I'm not saying UCD is waterfall. I am saying not to confuse Scrum with Agile. They really aren't the same things. Which do you mean? Agile or Scrum? –  Glen Lipka Mar 4 '10 at 23:44
    
I meant agile. (I'm not sure when scrum = agile in the public consciousness. worries me slightly) –  Matt Goddard Mar 5 '10 at 7:23
    
I've found that almost everywhere I go. Depresses me all the time. –  Glen Lipka Mar 5 '10 at 19:28

At the UPA conference in Portland, last year, I heard a panelist say (I'm paraphrasing) the following:

Agile solves an old problem for developers -- the problem of delivering the wrong thing, too late. Since Agile addresses that problem, it puts both design and usability on the critical path. We need to work with developers to help them understand that the solution to their problem(s) needs to accommodate our problem(s).

For me, what follows from this point is that either the entire Agile team -- developers, QA, and all -- are all involved in design and usability together, or -- if they can't do this well enough -- the Agile process makes room for specialists who can.

-=- Jerome

share|improve this answer
    
I agree to a point, in that with UCD everyone on the team should be developing with the customer in mind. However, if a dedicated UX person isn't involved, then there's no one at an arm's length from development that can act/think like the customer. The consequence is the finished product often suffers as a result. –  Janel Mar 9 '10 at 11:44

The UCD processes enhances Agile and can make it a success for both sides (biz/dev).

If the UX person is involved in both biz and development, works with the Analyst (or is the analyst) and writes/participates in the User Stories, is there when they're ranked (to help the team understand priorities set for UX) and participates in daily scrum to hear the issues that development is having, changes they want to make, listens to QA's test process and issues, etc. It's then a win/win situation and a successful Agile project.

Some designers may fight the Agile process, those who think that pixel perfection and no deviation are what makes a successful project, but there is no real conflict. A design can flex as req's change, just as architecture, data, code can adjust.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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