I’ve been a UX and agile practitioner for some years now. To me, the two go naturally and intuitively together. One focuses on understanding what is of value to users, extracting the way they think, feel, and want to interact with systems and developing something that reflects the way they needs a system to work. A system that works with them, not against them. A system that works relatively flawlessly with the way people work, rather than forcing them into a paradigm of interaction that is alien to them. The other, agile, reinforces the necessity to involve users in the solution design, validation, and to use documentation as a place holder for conversation to confirm what is needed, rather requiring than a bamboozling list of incomprehensible specifications are signed-off.

The tools of a UX (and IA) practitioner are embedded in cognitive psychology and are perfect to establishing the stack of requirements in preparation for work estimates by agile developers and even facilitating prioritisation:

  1. Personas: archetypal representation of users that describe their motivations, needs, capabilities, and expectations. When in doubt about a decision an whether it’s of value to users, just check the persona and ask “what would Bob want?”
  2. Priming: engaging people’s imagination and emotional brain centres to understand how people feel about their context of use, often the workplace, before doing more formal interviewing or contextual inquiry
  3. Card sorting: understanding people’s grouping preferences, order preferences, through simple assessment of how they order cards
  4. Contextual inquiry: understanding how people do activities in the context that they take place through observation, rather than trying to understand them by taking them out of that environment and asking them to report on it (which often just lets you know what they ‘think’ they want, or what they think you want to hear, but not what they really want and need)
  5. Storyboards: a graphical representation (akin to a cartoon strip) of the thoughts and actions of users in the context of use of an application
  6. Collaborative design: pairing (in agile terms) through asking people to come up with their own designs for how they want their systems/applications to work
  7. Navigation and interaction design: producing ways of finding/searching/browsing information that match the ways people think about information
  8. Information classification: mirroring the way people think about and recall information within an application
  9. Navigation design: ensuring that the tools for discovering information mirror the way they think about information
  10. Wireframes and prototyping: demonstrating that you understand what requirements you’ve collected BEFORE the application is built, but also as a tool to test the solution vision works and is intuitive. In fact, I’ve even done elements of UAT in the prototype — the ones that assess whether tasks are faster and more intuitive in the new solution than compared to the ways users have done their work in the past.

If you’re a Product Owner, or an Agile Sensei, then having a UX practitioner is a must! How else are you going to objectively understand users wants, needs, priorities, motivations, and capabilities in relation to the project and the value you’re adding?

Is UX innately agile? Who knows! But it’s certainly a VERY handy skill set to have around when you’re working on an agile project. I would even go so far as to say you can’t really do agile justice without it.

M