The missing piece: How interaction design can add to Agile

Since Alan and I attended Agile 08 last August, I’ve had conversations with a lot of people about their impressions of Agile. I’ve talked with people working in a variety of settings, from scrappy startups who are iteratively defining their product and market to large companies with complex business problems working with internationally distributed teams. In each of these settings, some folks are strong advocates of Agile, some are still skeptics. It’s a broad field, and I’m still very much formulating my opinions, but I’d like to share some thoughts and observations I’ve had along the way. I also have a few ideas about how Agile and interaction design might be able to work in concert.

Some aspects of Agile create tremendous value

The people who are successful with Agile realize that it’s not just a set of techniques; Agile is about creating better products, and making the process less painful along the way.

  • Agile is about shared responsibility. As Alan says “Someone is going to design your product, it can happen accidentally, or on purpose.” Instead of an indirect cascade of responsibility, Agile makes developers partners with other people in the organization. Instead of delivering software that meets specifications, developers engage with the rest of the organization in a more collaborative way to create products.
  • Agile is about effective communication. By changing the language of product definition from “features” to “user stories” Agile helps people focus on the value the product delivers to real people, rather than the technology used to deliver that value. By bringing people together to play the planning game, Agile makes it possible for developers to ask product managers “what do you mean by that?” and for product managers to ask “this seems easy, why will this take so long?”
  • Agile helps you fail quickly. A focus on working code helps Agile projects stay honest. Instead of working for months on something that may or may not work, there’s a focus on providing smaller parts that are available for feedback and refinement.
  • Agile is a more humane way to work. Iterative development helps development teams work at a sustainable pace, and stops the death march. Agile development recognizes the fact that human resources are finite, and you don’t get something for nothing. By considering the implications of a user story, developers and product managers can have a well-informed conversation about trade-offs.

Some aspects of Agile cause frustration

Agile’s roots are in the product development world, not the product creation world. A successful product is more than well-executed technology delivered on time. As Alan likes to say “The operation was a success, but the patient died.” Most Agile techniques (e.g. peer programming, integrated testing, refactoring) are focused on effective development. Many Agile projects are staffed entirely with people who write code. At a company where everyone isn’t a coder, it can be challenging to fully integrate the contributions of business stakeholders, such as executives and product managers and other team members such as business analysts and interaction designers.

  • The Agile process does not provide tools to define key business or user experience objectives. A clear product mandate makes it easier for everyone on the project to share the same vision and contribute to a shared objective. Somewhere in the process, it’s necessary to define “What does this product do?” “Who is the customer and what does she value?“ and even “What should the experience of using this product feel like?” Many people assume that these things are determined before the Agile development effort starts, or can be figured out iteratively as development continues.
  • An Agile “customer” may not be the same as the “user.” An Agile customer is often the business stakeholder who paid for the project, not necessarily the “user” of the system. When an Agile team does have a chance to show work-in-progress to actual end-users, their feedback can be difficult to interpret or prioritize.
  • You can lose sight of the big picture. Developers need user stories to be small so they can be tested and built in a single iteration. Even when a team starts with some idea of the overall experience they want to create, once it’s broken into granular user stories, it can be difficult to identify useful interaction patterns and maintain a coherent product framework. Using Agile techniques, it’s possible to come up with solutions for every user story, and still fall short on making a product that’s a pleasure to use.
  • It’s hard to integrate visual interface design. Visual interface designers who produce static pixel-level screen mockups can find it hard to integrate their process with an Agile development team. When responding to the needs of the evolving product it can feel like they are always playing “catch up” and trying to rework visual and interaction design decisions that were made by developers as they built the product. Developers can feel that designs of this nature are “brittle” and that visual designers are not responsive to their needs.

Interaction design can help

These challenges seem to suggest areas where interaction design techniques can help. Interaction designers can partner with product managers and developers to evolve Agile from a development process to a product creation process. Although some people have the impression that interaction design is solely a “waterfall” method, in reality a highly iterative, sketch-based approach to interaction design can be quite nimble.

  • Interaction designers can partner with product managers and other business stakeholders to understand and balance business and user goals. Interaction designers can clarify and articulate the product mandate through stories and sketches that create conversation and consensus.
  • Interaction designers are experts in observing and understanding user behaviors and making this information available to the development team in the form of personas, mental models and scenarios. Depending on the timeline and project scope, this work can be done in a very compressed timeline, or successively as new insight is needed.
  • By thinking about the design problem at a higher level than user stories, (I’ve heard some Agile teams call this a “big story” or a “narrative”) interaction designers can help developers understand the underlying interface patterns and framework of the design and assist with the sequencing of user stories as they are implemented.
  • Interaction designers can facilitate design brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions. Interaction designers can also take these varied inputs and create coherent design solutions that people can understand and use.
  • By working through interaction problems in low-fidelity sketches, interaction designers can quickly iterate on different design solutions, which helps developers save time and make good decisions.

From reading other blogs and discussion groups, it's obvious that a lot of people see the potential that Agile represents for the interaction design community (and vice-versa), but there are also a lot of questions about how this combination should work. I look forward to hearing your stories as we figure out how to best develop this opportunity. Please feel free to comment on this article, or drop me a line if you want to talk about your experiences. As I continue my research, I’ll share further thoughts on this Blog.


This is EXACTLY what my team and I are going through and EXACTLY the kind of wise words we (and our dev team) need to hear. Briliant!
Chris Blow
Definitely agree that it is hard to keep a visual design ahead of the developers, there's no way out of this except hard daily work responding to the latest and greatest ideas, IMHO.
duncan Brown - Caplin Systems
At Caplin we work on our Interaction Design (one sprint in advance). Whilst keeping it ‘agile’, using overlapping pre-sprint/sprints, lets us involve the ‘Business’ in the design process, getting approval on the Interaction Design before the Dev. Team sign up for the sprint. During the sprint we have open communication between the Dev. Team and ‘Business’ but this is more for clarification rather than dealing with any big surprises. The Interaction Design team offer the developers support during the sprint (whilst also working on the interaction designs for the next sprint!) We’ve been following this overlapping process for a little while now and so far it seems to be working well, and increasing productivity (it’s a lot easier to rework a wireframe or storyboard!).
Thanks for your comments, David and Chris. Duncan, I have also heard of other teams that are successful with an overlapping process like yours. Thanks for sharing! -lane
Chris Gielow
I am trying to reconcile Agile with Alan's wise words about "the Perils of Prototyping" written 10(!) years ago. I still think Alan is right!
Rob McKeown
Working ahead of development has been a process I have been trying to implement for some time. The challenge for me has been the pushback I get stating that spending time "up-front" ahead of development is anti-agile. I have also been told "This sounds like waterfall to me" because the outcome of design is passed into development. I have been working in an Agile (Scrum specifically) environment for sometime and have heard about the origins of it in manufacturing. The analogy to software development doesn't quite add up. For example, I would expect that before a car is put on the production line, it has been fully thought out. The position of the widgets on the dashboard, the console, the styling, etc. are not designed "as-you-go" on the production line. However, this is exactly what Agile proponents are suggesting must be done in the software world. Throw usability testing into the mix and it is labeled "a waste of time" because "we are experts in this domain, we know what users want". There has to be some balance of Agile development and Interaction Design/Visual Design methodologies. I would love to hear more about the successful ways this can work.
Leandro Alves
I work on a ixd consulting firm at Brazil and we work with agile and non-agile teams. When working with agile teams, the major problem is the "inexistence" of the user in traditional agile metodologies. So, we need to spend an initial effort to show then that a user is VERY different from an customer. It became clear with a few concept prove or rapid usability testing. Almost every interaction design process were developed based on a "scientific" environment, where the research is the key feature and the long time spent understanding the problem and finding a solution, is not the big deal. But, in an agile environment, it tends to be innaproriated. An agile ux team needs to focus on specific goals and adapt some of the existing metodologies to get what is relevant to the next or current sprint (depends if the team uses overlapping sprints or not). The sprint zero is relevant to collect user information and define the initial concept of the product. All the other decisions should be made during the development of the product. But with that approach, the ux teams fall into a common mistake: creating an interface that looks like an frankeinstein. To avoid that, a "global vision" of the product should be clear to the entire team, at the beginning of each sprint and the interaction designer should have it in mind, when creating a solution to "part of the problem". To do this, one good tool we found is user story mapping, that is a great tool for telling a story about the product and undesrtanding the releases of it.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment