My experience with UX and Agile

Recently I’ve been considering how I would help other user experience designers work with the my product team as collaboratively as I have for the past two and a half years…what do I do?…how have I been successful? The feedback I’ve gotten is that I’m an integrated part of the team – appreciated by the engineers I work with almost to the point of relief. This means that I work with the team to make decisions daily. Ideally these decisions are informed by domain knowledge, and/or by direct user feedback. Design decisions have to be grounded in the product, division goals, and practical considerations of current and future state of technology. Not every decision can be researched, and designers have to trust their instincts as designers and their knowledge/history on products and workflows to make decisions.

During the course of our most recent release, I set up continual research with a set of senior stakeholder users that I consider product advisors. These users tend to be evangelists, or could be so, in their companies and want to work in 3d and understand the potential of modeling large scale infrastructure projects in 3d. Continual research means ongoing meetings, either one or two sessions per month with ten or so users. This roughly equates to 3 – 4 hours of informal interviews per week to discuss requirements, review design concepts, and to perform usability audits of prototypes.  Conducting continual research is hard, but keeping it informal makes it manageable, and keeps me in touch with how our key customers are using the product currently and where there are gaps in the workflows they hope for, and provides a mechanism for concept direction and design validation.

Knowing the medium I work in has also been a critical component, and allows me to create the best interaction model within the current state of the technology….handing Van Gogh a stone block and a chisel would would have perplexed him, because its not the medium he knew and he would likely have struggled.

Let’s break this down…

What does it mean to be an integrated part of the team?

  • You are not the defacto expert, and you don’t need to be
  • Start with the assumption that software engineers, QA engineers, product managers (and others stakeholders) have addressed detailed problems in the domain and have a deep understanding, and therefore are a source of input
  • Make decisions on the fly with the team on a day in and day about basis. If you’ve done research you tend to lead the discussion
  • Don’t be afraid to fail. Agile means you can correct mistakes
  • You are an interaction designer making software. You are not a mock-up designer producing documents. Testing early mockup is great for validating design concepts and design direction but fails terribly for testing interaction design.
  • Testing working end-of-iteration prototypes makes you a better UX designer.

But making design part of the scrum team means I’m losing authority as a designer….

  • This could not be further from the case
  • Believe it or not, engineers want the best experience, set of workflows and features for the user as possible
  • Talking to users continually means you understand how they think
  • Engineering will look to you as the lead in making decisions on the scrum team because of your thinking and the discussions you’ve had with users….
  • Because the nature of agile means breaking down stories to atomic levels, it is up to UX (and product managers/product owners) to make sure the big picture is not lost when piecing together user stories back up to the epic and theme level

Category: Agile, User Experience Comment »

Leave a Reply

You must be logged in to post a comment.

Back to top