How UCD and Agile can live together

User Centered Design is the methodology by which you design a holistic product while considering the needs of stakeholders and users. Agile Development is a programming methodology and philosophy intended to overcome the challenges of the waterfall development process and to deliver clean and functional code. How can these two methodologies come together?


In order to have this discussion, I would like to define a few terms as they will be referred to in this article. These are by no means absolute definitions, but in writing this article and soliciting feedback from practitioners I thought it prudent to define what I do (and don’t) mean by certain terms for the sake of the article.

  • Agile Philosophy: the tactical, iterative and transparent perspective on a project engaging all stakeholders and members of a project team. The ultimate goal is a clean and functional product built through transparency and accountability;
  • Agile Method: also referred to as scrum, the actual development process including all the hard deliverables including user stories, backlog, burndown charts and all the other tangible by products of an agile team;
  • User Centered Design, The iterative strategy where design and research practitioners involve stakeholders and users to gain a cohesive view of a project and to empathize with users. The ultimate goal is a cohesive vision and product definition backed with qualitative and quantitative findings;
  • User Experience, or IxD, or any other of dozens of titles: the actual process of qualitative and quantitative research, concept validation, and design. The end deliverables include system visualizations, information architecture, and design spec’s.

Strategy and Tactics

From Strategy to Tactical

As you might have recognized, I defined Agile as tactical and UCD strategic. I don’t mean to say they are mutually exclusive to each other. The nature of the deliverables tend to lend each philosophy more to one than the other.

So, Agile is predominantly tactical. Established with developers in mind Agile has expanded to include product design, QA teams and business managers. The roles of each are defined by Agile and each stakeholder understands their roles and the deliverables expected of them.

UCD, while spanning both more evenly, is strategic at its core. Information architecture, mappings of ecosystems, and other deliverables are more interpretive than the deliverables expected of an agile team. The importance of these deliverables should not be lost though as it is these initial frameworks that help guide the overall purpose of the product.

It should be noted that while UCD spans strategy and tactics more evenly, both UCD and Agile have equal weight in the project overall.

Chicken or the Egg?

“We’re locked in a perpetual jr high dance. Arms stretched out stiffly, knowing we should like each other, but just not sure how”
– Will Sansbury

Figure 2. Project lifespan

So what comes first? The chicken or the egg? Agile or UCD? The short answer is: both should be present at all times. But which philosophy is in the drivers seat should change throughout the project.

In order to build any type of successful project there must be an agreed purpose or goal, a unified vision, and a determining plan to get there. Understanding this path, it fits a flow from high level strategy to tactics and hard deliverables. Figure 2 breaks a project lifespan into three high level phases that capture this transition. Let’s look at each phase individually.

Phase 1: Purpose

A project exists for a purpose, but understanding the goals, motivations and needs of users requires a deeper understanding.

Phase 1 is the chance for UX practitioners to perform literature reviews, competitive analysis, user research and high level concept validation to narrow and define scope. Hard deliverables could include personas, mappings of ecosystems, concept scenarios, and initial sketches of the final interface.

Since the bulk of Phase 1 is determining the ultimate purpose, member of the agile development team might feel on the sidelines. This is a prime opportunity to gather technical requirements and to perform preparation for the actual sprints. Stress is off the development team so it is a great time to determine technical requirements and to discuss potential pitfalls. Deliverables could include setting up QA environments, sketching potential infrastructure needs and challenges and gathering hardware, software and personal required.

Phase 2: Vision

The product is by no means locked in or fully defined but frameworks are being established. The weight on UCD begins to shift to Agile as deliverables become more measurable.

UCD is still involved in research, performing Round 2, 3, n-1 of research and design. The ultimate goal of Phase 2 is not to have a fully designed product but to understand all the moving parts with a few key pieces well defined. At the same time, agile developers are creating user stories and building out the backlog.

Hard deliverables from Phase 2 should include design requirements for Sprint 1 from the designers and an executed or started Sprint 0 from the developers.

Phase 3: Execution

Now Agile takes lead. By the end of Phase 2, the UCD team should have established enough requirements for Sprint 1. The Agile team can now hit the floor running performing each sprint. In turn, the UX designers will stay one sprint ahead on design requirements and additional research. Scope and requirements may change but based on the Phase 2 research there should be a solid understanding of the product from all stakeholders that changes should be minor and drastic changes can be appreciated by all parties involved.

In these phases, it may be seen how the transition from strategic to tactical deliverables corresponds to the UCD and Agile focus on a project. It must be noted that there is no point where either philosophy owns the project exclusive of the other.

friction exists from misaligned expectations from UCD practitioners forcing their methods too late in the game or agile practitioners trying to wean out hard requirements before purpose is fully understood

Paradise Lost

Diagrams are pretty, Gantt charts set expectations, but reality is far from perfect. At the end of the day, a project manager must own the project and there must be some sense of reporting. Depending on the project manager’s background and personal goals there will tend to be a focus towards the needs of UCD or Agile. Additional friction exists from formal training. While most UCD practitioners do not hold degrees in the field, there exists a corner of academia that teaches these methods. There is currently no formal training in Agile however… While those practicing Agile typically have a few years experience, there is also a large percentage of project managers using Agile without having a complete understanding of where it fits in the entire process. Add this to any workspace ego and the trained and the not-traineds and there is the opportunity for a volatile work environment, Finally, friction exists from misaligned expectations from UCD practitioners forcing their methods too late in the game or agile practitioners trying to wean out hard requirements before purpose is fully understood.


Agile and UCD can be integrated. I have been personally involved on projects that have used both to perfect harmony and those that were less ideal. A personal belief is that design is about communication. The breakdowns that exist in integrating UCD and Agile exist as a result of miscommunication from poorly set or unframed expectations. As Agile and UCD further develop and members of each camp have training to both methods I see the miscommunication fading as a unified vocabulary and set of deliverables form.

I want to thank Will Sansbury and Jeff Gothelf in particular for their direct feedback and conversations while writing this article.

Top image by: kofoed

David Farkas

David is an interaction(s) designer working in the online and mobile realm. He focuses on the relation between the digital and the physical. Usability, goal oriented design, and consistency are key.

25 comments on this article

  1. Pingback: uberVU - social comments

  2. Pingback: IROAI | How UCD and Agile can live together

  3. Pingback: Johnny Holland – It’s all about interaction » Blog Archive » How UCD and Agile can live together « A Kiwi in NYC

  4. Pingback: Johnny Holland – It’s all about interaction » Blog Archive » How UCD and Agile can live together « Netcrema – creme de la social news via digg + delicious + stumpleupon + reddit

  5. The first principle of the Agile Manifesto is the early and continuous delivery of valuable software. Many (Alan Cooper, for instance) have questioned if a focus on early, and likewise continuous delivery, is even sensible, or capable of procuring a valuable product.

    (It is worth noting that the infrastructure required to make truly continuous, rather than continual delivery, is baroque if not totally unwieldy, not to mention almost completely unnecessary.)

    If we treat software as an artifact of language, rather than a construction endeavour, we can see that the object is not volume of product but conceptual integrity. The cost of producing the right thing is roughly the same as producing the wrong thing, and the detriments of producing the wrong thing are roughly as intense as the benefits of producing the right thing. Given that, there should be significant net benefit in getting things right the first time.

    To tune that concept, however, we ought to distinguish between iteration and incrementality. In the former, we discard or possibly recycle existing material. In the latter, we add onto it, orthogonally. It follows then that if we are to discard or recycle material, we should use the cheapest material available.

  6. Pingback: TwittLink - Your headlines on Twitter

  7. Pingback: links for 2009-12-14 « burningCat

  8. Pingback: IxD + Agile = A great iterative approach to Design Making. « Rahul Sen: Future-Sense

  9. Pingback: IxD and the ‘Agile Method’ | Interaction Design Umeå

  10. Pingback: Weekly links | USiT

  11. Hi David,

    Thanks for the article.
    Scrum is not an acronym for Agile but one of the Agile methods. You can study it by the way, you can get trained as a certified scum Master.
    What I miss here is the role of the Product Owner, which is strategic as well and who’s responsibility it is to create and maintain the backlog. (although agile teams often need to help)

    Jeff Patton has some articles ( where he suggests the UCD people should be on the product owner team.

    @ Thomas Petersen: thanks the link you posted. It’s quite a contrast with this article. This article does put quite some research up front. Your linked article claims that doesn’t work.
    Although he may be overstating it a bit there are some valid points in that article too: you can’t know for sure what the customers reactions are until you’ve build it. Therefore incrementally, iteratively building it will give you feedback that you can’t get through prior research.

    My thoughts are: both could work depending on the product, the amount of risk you are willing to take (succes/no succes) the time you can take before launching a first version, the amount of initial research required etc.

  12. Above I meant synonym instead of acronym: Agile is an example of an Agile method, not a synonym of Agile Method.

  13. Pingback: UCD to zło |

  14. good, but How UCD and Agile can live together

  15. Pingback: Do you speak my language (or reaching a common understanding in Agile speak)? « Agile Tribe

  16. Pingback: Book: Succeeding With Agile « Tales from a Trading Desk

  17. Pingback: links for 2009-12-15

  18. Pingback: Johnny Holland – It's all about interaction » Blog Archive » From whole to hole: a recipe for a holistic design process

  19. Pingback: Agile in Plain English (part 1) « Allaland

  20. Pingback: continuous mappings

  21. Pingback: Agile Design en Scrum in de praktijk | Frankwatching

  22. Pingback: Agile and user centred design working together @ RB Consulting’s Blog

  23. pasi r. on

    Nice article, however, I do not agree with the fundaments.

    First of all, Agile does not equal Scrum although Scrum is Agile 🙂 There is far more to Agile than just Scrum. This leads to my main gripe with this article…

    Scrum is a project framework, NOT a development method. If you get this, then you should have no problem in utilizing Scrum in User Centered Desing, I believe.