52 Flares Filament.io 52 Flares ×

There has been much discussion lately on how to start integrating user experience activities into the agile way of developing software (you can take a look at this article from UXmatters and LinkedIn discussion). While both development and user experience may have the best interests of users and the business in mind, their approaches to solving problems can vary greatly. From my experience working in agile, I find that there are ideas that can be used from both sides to help get a design specified and implemented (as I have worked in both agile and waterfall development environments).

User Experience Improvements

User experience processes can benefit from agile thinking in the following ways:

  • Less paperwork for paperwork’s sake (this will allow design teams to focus on documenting just enough to transfer knowledge and to move forward)
  • The process should be focused on delivering something that can be picked up and used at any time (to help each team to continue to working)
  • A fast pace focused on delivery (to remind designers of their commitment to their employer and to be able to get concepts out to users for feedback and testing)

Agile Challenges

When I’ve been in an agile development environment, I’ve noticed the following challenges when it comes to designing and delivering a good user experience:

  • The core of agile is focused only on developing a finished idea; when the user experience isn’t finished when it comes to user stories, there will be much controversy and rework from all team members involved
  • Agile and UX are at the opposite ends of the spectrum when it comes to documentation; a good user experience comes from creating the minimal amount of documentation to get the design completed and reviewed
  • User stories have concrete start and end points; for designers, the user experience encompasses much more than start and end points and is difficult to design for small points in an overall experience when the overall experience is still being shaped
  • Once a user story is completed, most of the time, the developer’s job is complete; the overall user experience, though, doesn’t end with the completion of the user story (nor the sprint and release, either)
  • The backlog is the source of truth of what will be contained in a release; without adequate user testing and time to complete the design, there may not be enough to data to convince the product owner how to prioritize improvements to the design
  • Most user experience activities cannot be fit within a 2-week sprint and be considered final and complete, whereas many development and QA tasks can be fit within this time period. It is very difficult to justify to product owners why longer periods of time mean substantial investment into the user experience

Agile and UX Living Together

In a perfect world, I think we can have a UX and development process live together:

  • When a new release is planned, there are pre-sprints dedicated to user research, user experience design, business vision, and requirements gathering. Developers are part of the process to help demonstrate the technical feasibility of a design and tradeoffs with different technology platforms (this will help to provide a backlog with the stories that are needed for development to contribute and plan completion in small steps)
  • The user experience team is motivated to deliver something to the business through delivering something at the end of each sprint, knowing that the design isn’t complete and can change (to help the business and development team understand that UX wants to provide the best experiments, minimizing the change between each sprint)
  • When there are substantial updates to the backlog, there is time to analyze what portions of the design should be updated (change is a natural part of our profession: when there is time spent to replan and update the design, development teams won’t have to have multiple iterations from different stakeholders in the process)
  • A release is planned and executed with sprints when a design is ready to start development. User stories for the release are created from insights gained from the business vision and insights from user research and usability testing (this will help to create relevant user stories for development to implement only what is needed to create a cohesive user experience)
  • There is a developer who can work with designers on pre-release activities to create prototypes for user testing (and to also help with technical feasibility and mentoring oncoming developers)
  • Design and development deliverables are especially small, concise, and fulfill the need of communication (this helps prevent information overload, and removes the focus of making specs and documentation look beautiful)
  • Effort will be needed to help focus individuals on providing users the benefit of they are working on (instead of focusing on code and delivering software)
  • Usability testing with representative users is done at the end of each sprint, allowing time to gather insights and create defects and improvements to the design (to help make sure the “finished idea” that could be released with as few user experience issues as possible for the business)
  • All people involved with the project must be comfortable with changing their work when the vision of the project changes or the business changes funding for a project (to help keep a focus on delivering a backlog that is user-centered and delivers on business objectives)

For the readers of this blog, how do you feel agile and the user experience process can grow from each other. Personally, I feel that there is still room for agile to positively impact the user experience process; additionally there is still a need for separation: after all, development teams cannot organize and deliver quickly if they don’t have anything concrete to develop from (this is the situation that a good user experience can help to deliver – giving a good experience for both the users of a product, and those who develop it).

Casey Addy
Casey M Addy is a user-experience practitioner focusing on data-driven design thinking and rapid prototyping via pen and paper. He also likes to turn paper concepts into interactive stories to help teams articulate and validate design thinking.
Casey Addy

Latest posts by Casey Addy (see all)