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
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
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
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.
Top image by: kofoed