When Agile and User Experience Click

By Todd Zazelenchuk and Jeff Larson

Published: January 21, 2013

“No two software development teams are the same. They may vary in their composition, experience level, the proximity of their members, and their organizations’ willingness to embrace agile development methods.”

Try this test: Find three UX friends and ask them about the compatibility of UX design with agile development. Odds are that one of them believes UX design and agile can work well together, one swears that they can’t, and one has yet to decide. There are many reasons for the divided opinion on this issue.

In the same way that consumers’ experiences are highly contextual, no two software development teams are the same. They may vary in their composition, experience level, the proximity of their members, and their organizations’ willingness to embrace agile development methods. To be successful, it is necessary to apply strategies that best serve our team’s context. In this article, we share our recent experience trying to make UX design and agile click by examining the design and development of the Android app Find MyHeadset™ and highlighting the strategies and activities that we found most helpful.

Find MyHeadset

“Find MyHeadset … gives people two methods of finding their lost headset…. If a missing headset is powered on and in range of its paired smartphone, a user can have the headset emit a tone to reveal its location.”

We design software for Plantronics, a global leader in high-performance, audio communication devices. One of the company’s most popular product categories is the compact Bluetooth headset. While these devices vary in their styling and feature sets, they come in a single size: extra small. Not surprisingly, they are easy to misplace. In May 2012, Plantronics formed a team to address this common problem.

Find MyHeadset is a mobile app for the Android platform that helps Plantronics customers locate their missing headsets. The app gives people two methods of finding their lost headset, as shown in Figure 1. If a missing headset is powered on and in range of its paired smartphone, a user can have the headset emit a tone to reveal its location. If a missing headset is powered off, out of range, or has no battery charge, the BackTrack feature lets users retrace their steps by displaying the most recent headset events and their corresponding locations. After four months on the market, customers have downloaded Find MyHeadset over 40,000 times and awarded it a 4.5-star rating on the Google Play Store.

Figure 1—Find MyHeadset app helps people find a missing headset

Find MyHeadset app helps people find a missing headset

The Find MyHeadset project was the first official agile initiative at Plantronics. The eight-member team was geographically distributed, with User Experience, Product Management, and Quality Assurance (QA) located in Santa Cruz, California, while Development and additional QA team members were nine time zones away in Eastern Europe. Team members’ experience with agile varied, ranging from extensive to none. The team adopted a Scrum approach and executed two- to three-week sprints to develop the application. We completed development in four months, launching Find MyHeadset on September 17, 2012.

Advice Worth Heeding

“Jeff Patton’s 12 best practices should be required reading for any agile UX team that wants to sidestep the inherent challenges of designing in an agile development context.”

Both prior to and during the Find MyHeadset project, our team benefited greatly from advice and experiences shared by the global UX community. In turn, we’d like to share the strategies and activities that contributed to the success of Find MyHeadset in the marketplace.

Follow Jeff Patton’s 12 Best Practices for Agile UX

Jeff Patton’s 12 best practices [1] should be required reading for any agile UX team that wants to sidestep the inherent challenges of designing in an agile development context. On the Find MyHeadset project, our team benefited from two of these best practices in particular:

  • Use a RITE (Rapid Iterative Testing Evaluation) approach to iterate on concepts prior to development. Although planning and implementing this approach can be challenging, its benefits make the effort worthwhile. For three of the five sprints on the Find MyHeadset project, we dedicated a day to usability testing concepts for future sprints. More than once, the results from these rapid tests led to significant changes that directly improved the user experience of the final product.
  • Prototype in low fidelity. Low-fidelity prototyping was critical to our conducting effective evaluations of our design patterns and workflows. By beginning with sketches like those shown in Figure 2, then progressing to mobile wireframes in a tappable PDF format, the Find MyHeadset team was able to collect highly relevant usability data that helped shape the architecture, functionality, and content of the final app.

Figure 2—Creating sketches

Creating sketches

Create a Holistic UX Workflow for an Application

“Without a clear vision, an agile project can quickly devolve into an incoherent collection of features and functionality that are driven solely by the prioritized user stories for each sprint.”

Both Nielsen [2] and Gothelf [3] emphasize the importance of a UX team’s developing and maintaining a holistic vision for an application. Without a clear vision, an agile project can quickly devolve into an incoherent collection of features and functionality that are driven solely by the prioritized user stories for each sprint.

For Find MyHeadset, we created a UX flow diagram to map out the core elements of the application and communicate our vision. While such a master plan may seem counter to an agile process, this holistic view helped the team understand what we were creating and how things were supposed to fit together.

In an agile development context, the key to creating an effective UX workflow is to keep it lean and incomplete, as shown in Figure 3. Focus on the portion of the workflow that supports the current sprint’s user stories without losing sight of the overall vision. In our case, each iteration saw the flow diagram expand and adapt to reflect the parts of the app that we were targeting during a specific sprint. Because we updated our flow diagram regularly throughout the entire development cycle, it served as an evolving blueprint that QA could rely on to conduct its testing.

Figure 3—Maintaining a lean UX workflow

Maintaining a lean UX workflow

Get Ahead of Development During a Sprint Zero UX Design Phase

“Prior to the first sprint, the UX team dedicated two weeks to ideating on design concepts, exploring workflows relating to the app’s two primary features—Send Tone and BackTrack—and conducting internal design reviews.”

Creating a holistic UX workflow and vision for a product doesn’t happen overnight. Depending on the scope of a project, it can require significant time at the front end of an agile project. [4] [6] Some people argue that a Sprint 0 design phase simply amounts to a waterfall approach, in which the UX team completes its design of an application up front. Others acknowledge the value of a Sprint 0 design phase, but question just how far in advance User Experience needs to design prior to embarking on a first sprint.

On the Find MyHeadset project, prior to the first sprint, the UX team dedicated two weeks to ideating on design concepts, exploring workflows relating to the app’s two primary features—Send Tone and BackTrack—and conducting internal design reviews. This effort permitted team members to effectively plan the first sprint and establish a design framework that provided a foundation for detailed design during subsequent sprints.

Stay Ahead of Development by Dedicating Time for UX Design for Future Sprints During the Current Sprint

Agile planning tools can help UX teams stay ahead of Development, but UX designers must ensure that they attend to designs for future sprints even when the current sprint is demanding most of their attention. On the Find MyHeadset project, we earmarked 30–40% of each sprint for detailed design and testing of user stories for future sprints. Ideally, we would have allotted even more time. More than once, our cushion evaporated, and we failed to stay ahead of Development. Had the project been any larger in scope, we would have needed to implement a design spike [5] to get ahead of the Development team once again.

Partner Closely with the Product Owner

“User stories are at the heart of an agile process. They drive what a product is supposed to be and do to meet the needs and goals of target users.”

User stories are at the heart of an agile process. They drive what a product is supposed to be and do to meet the needs and goals of target users. Product Owners usually write the majority of user stories and own the responsibility for prioritizing them. By collaborating well with the Product Owner, a UX designer can directly influence the user stories and, in turn, help define the product.

According to Patton [1], “In the best teams, the UX folks have an active hand in deciding what is built, the overall business strategy that drives what’s built, and the tactical prioritization of work done first. In some successful agile organizations, the UX team is the agile customer team or product owner team.” On the Find MyHeadset team, User Experience and the Product Owner regularly worked together to groom the backlog of user stories and ensure that their details and acceptance criteria were compatible with the holistic design vision for the app.

Figure 4—Collaborating on user stories and UX design specs

Collaborating on user stories and UX design specs

Schedule Dedicated UX Reviews with the Team as Part of Sprint Planning

“ For the Find MyHeadset project, a regularly planned review of the UX design spec prior to each sprint planning meeting quickly emerged as a requirement for success.”

When agile teams are entirely colocated and members are working in close proximity, they can communicate their ideas and solutions without additional effort. For distributed agile teams, however, you must take extra steps to avoid communication problems and delays. For the Find MyHeadset project, a regularly planned review of the UX design spec prior to each sprint planning meeting quickly emerged as a requirement for success.

The spec review helped the team visualize the stories that we had prioritized for the next sprint and understand the level of effort the proposed solutions would require. It also provided team members with an opportunity to give us their input and ensured that we gave them the extra details they needed to identify relevant tasks and make accurate work estimations.

Determine the Appropriate Level of UX Design Documentation for Your Team

“While it may be possible to reduce the formal documentation a project requires, it’s still necessary to record detailed interaction design decisions to ensure clear understanding among team members.”

A common misconception about agile development is that documentation should be eliminated. This is especially untrue for projects with distributed teams, where members must make independent progress asynchronously. While it may be possible to reduce the formal documentation a project requires, it’s still necessary to record detailed interaction design decisions to ensure clear understanding among team members.

Our perspective on this is counter to Gothelf’s [3] view that a prototype is the documentation on an agile project and anything more is wasted effort. On the Find MyHeadset project, adopting an “it is what it is” approach to documentation would have made it very difficult to build and test the app effectively.

Mature organizations such as Plantronics often have intensive QA programs that rely on documented design details to build their testing protocols. From the outset, our team chose to follow Govella’s [6] advice to implement well-annotated wireframes instead of producing heavy documentation. Publishing our specifications online made them easy to update and distribute to all team members. We simply emailed team members a link to the current version and provided a clear revision history.

Figure 5—Providing specifications for our distributed team

Providing specifications for our distributed team

Extend Your UX Team to Include Front-end Development

Having User Experience assume some degree of ownership over front-end development can help a team to achieve a higher-quality result in less time.

Team members who can play multiple roles on an agile project help increase the speed of iterations. When a UX designer can work directly with the code to complete front-end development work, Development team members can take on other tasks.

On the Find MyHeadset project, User Experience took responsibility for much of the presentation layer by working directly on branched code once the Development team had built the foundation. This permitted us to modify, review, and iterate on the design by creating our own builds and reviewing the latest code on demand. For a distributed team, even daily builds can be too infrequent to ensure rapid progress, so having User Experience assume some degree of ownership over front-end development can help a team to achieve a higher-quality result in less time.

More Work Ahead

“We need to address these challenges and others before we can realize the full potential of agile development.”

On the Find MyHeadset project, our team discovered multiple strategies that made UX design and agile development click. However, we also identified several challenges with which we continue to wrestle:

  • What is the best way to effectively manage certain UX roles such as visual design and user research that tend to experience peaks and valleys of intensity during a sprint?
  • How can we optimize collaboration and productivity among the members of our distributed agile team?
  • How can we meet our team’s desire to be lean and take risks within a culture that prides itself on avoiding failure through detailed execution and testing?

We need to address these challenges and others before we can realize the full potential of agile development. As the UX community shares more examples of successful projects like Find MyHeadset, we’ll all become more confident—and perhaps less divided—about the compatibility of UX design and agile development.

References

[1] Patton, Jeff. “Twelve Emerging Best Practices for Adding UX Work to Agile Development.” Agile Product Design, June 27, 2008. Retrieved December 9, 2012.

[2] Nielsen, Jakob. “Agile User Experience Projects. UseIt, November 4, 2009. Retrieved December 9, 2012.

[3] Gothelf, Jeff. “Lean UX: Getting Out of The Deliverables Business.” Smashing Magazine, March 7, 2011. Retrieved December 9, 2012.

[4] Walker, Mat. “About Agile, UX, and Sprint 0.” MatWalker.co.uk, January 17, 2011. Retrieved December 9, 2012.

[5] Dimmick, Damon. “Fitting Big-Picture UX into Agile Development.” Smashing Magazine, November 6, 2012. Retrieved December 9, 2012.

[6] Govella, Austin. “Agile + UX: Six Strategies for More Agile.” Thinking and Making, May 7, 2008. Retrieved December 9, 2012.

Thanks to Paul Bryan and Philip Hodgson for reading an early outline of this article.

11 Comments

Agree on all counts. Arguably, if front-end skills are part of your team, its presence can be stronger if prototyping is done in high fidelity to get buy-in for redesigned workflows. (See one example: Agile/UX Lineout!.)

I really enjoyed this article and your headset case study. One question about the low-fi prototypes: did you show these to people as paper prototypes, or did you scan them in and chain them together as a clickable prototype on the handset itself? Do you have any comments on the benefits and downsides of each of these ways of doing it?

Thanks, Luis. In this particular case, the front-end development work that UX contributed went beyond prototyping to actually working directly in the code branch to apply the final design to the developers’ foundational code. In your example of creating prototypes to help the team and/or stakeholders buy in to proposed workflows, my experience has been that low-fidelity prototypes often provide the best ROI. Of course, that does assume that your team members have some ability to envision how the final version will differ. :)

Hi David. Glad you enjoyed it. Re: the low-fi prototypes, we actually did both paper and clickable versions during the course of the project. I highlight paper because I used the paper app for iPad to create the early concept sketches (see Figure 2) and obtain feedback from users on functionality and workflows for key tasks. I simply placed the individual PNG screens in a Dropbox folder and shared them with users on the iPad to get feedback on each screen as they stepped through them. Once we narrowed our concept direction and architecture for the various features, I revved the materials to a slightly higher level of wireframes in OmniGraffle, designed for a phone screen, and created clickable PDFs for users to interact with on a mobile device.

I would follow this progression again. The first round is quick and easy to get some early feedback and does not really demand the context of interacting with the design on the phone itself. The second phase requires a bit more time and effort, but helps ensure that you aren’t overlooking aspects of your design being used on a mobile device or ignoring the behaviors and expectations specific to that particular platform—for example, Android.

Great article, Todd. It’s a practical case study that sheds light on how UX and agile can work together. I am interested to hear more about the relationship with the Product Owner. I wonder if most people find that collaboration so smooth.

Thanks, Paul. I’m sure that mileage may indeed vary with each product owner and project, and our advice to partner closely, while valid, is definitely dependent on your ability to forge a productive working relationship. In our case, we were fortunate to have a product owner who had a clear vision, but was also completely open to collaborating on user-story details and balancing them with proposed design concepts. The result was a two-way synergy between stories and concepts, as opposed to the one-way cause and effect that might otherwise occur. Beyond this general advice, I would say that the standard best practice of providing your product owner with multiple concept options to address a given problem and sharing them as early as possible helps make the process go more smoothly as well.

Hi Todd & Jeff

Just wanted to say thank you for such a valuable article. Your clear and specific description of what happened, with a focus on what worked and what didn’t, is very informative.

Congratulations, also, on what you achieved. A distributed agile team with a considerable UX element is quite the challenge. So, while you note that there are things with which you continue to wrestle, I hope you also celebrate what you’ve accomplished.

Cheers, Jessica

Thanks, Todd and Jeff, for one of the better, more informative articles I have read on UX in recent days. Your article details the things your team did to be a success, and your ability to share those things with clarity—and without opinions and fluff—are much appreciated.

Hi Jessica and Erik,

Thank you both for the comments. Glad you enjoyed the article. We hope our experiences prove to be helpful in your upcoming projects.

Can you put up the actual design spec as well—at least a snippet of it?

Hi Mark,

Just email me at todd.zazelenchuk@plantronics.com, and I’ll share a snippet of the spec with you. Let me know if you have any specific questions about it in your email.

Join the Discussion

Asterisks (*) indicate required information.