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?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.Sign up to join this community
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:
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.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- 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:
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.
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.
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.
Since this question was first posed, there has definitely been changes within the industry to try and adopt a more 'agile' and 'lean' version of UX. For example, this question that was asked more recently reflects the need to balance agile with ux to take advantage of both approaches and philosophies in design: How to optimize the UX process for projects with tight deadlines?
In my response to the question, it is about dispensing with the practices and methodologies in UX that are not critical to meeting the design objectives, and a summary of my answer to the question was to improve communications with documentation, simply/streamline workflow and focus on the end goal. How the research and testing is carried out depends on how willing the designer is to make assumptions and take it forward in future iterations.
So it is possible and probably a common practice now.