Adding user tests to your agile process
Teams often forego customer feedback in the name of speed. They want to get to market as fast as they can, before their competitors and before customer needs change. But there’s a risk to doing this. Sacrificing human insight to prioritize speed is misguided.
You’re no doubt familiar with the fallout from a failed product launch. The odds aren’t in your favor. According to the late Harvard Business School professor Clayton Christensen, of the dizzying number of products released every year, a whopping 95% of them fail.
We won’t name names, but there’s no shortage of examples of teams who thought they had a winning product, only to find their customers weren’t interested after the launch. The financial loss associated with the sunk costs of development for a product that essentially never sees the light of day is bad enough. Add to that the loss of trust that failed launches can have on loyal and prospective customers and the impact becomes much more severe.
Customer-centric organizations reduce risk by investing time and resources into understanding how their customers experience their product across touchpoints and channels. From researching a purchase, going through a checkout process, to interacting with chatbots for customer service, today’s consumers have numerous touchpoints with brands. All of these steps add up to nearly countless opportunities for organizations to earn—or lose—customer loyalty.
Using an agile process has become the go-to development methodology for reducing risks when shipping new products and features. Even though agile helps many organizations make huge workflow improvements, agile teams aren’t perfect. Despite using these methods, they can still create products that don’t meet user needs.
How product teams and developers spend their time is extremely valuable. In a perfect world, developers would spend 100% of their time building new products and features. In reality, an estimated 50% of engineering time is spent doing rework that could have been avoided. Plus, fixing an error after development is up to 100 times as expensive as it would have been before.
So how do you avoid making these mistakes? How do you reduce uncertainty and prevent the overall failure of the products and features your team ships? The answer is user tests.
User tests can help you understand if the products you’re building are going to help those you support. And, these tests should be embedded into the process, not something you do once the product is already built. If you’re waiting to get user feedback until your developers have built the product, then you’re waiting way too long.
In this guide, learn how user tests support your agile process. Use them in parallel with your design and development sprints to ensure you’re creating products that users will love
What's inside
How user tests can help
With remote user testing, you can get video recordings of real people from your target market as they use any website, mobile app, or prototype. You’ll hear these users speak their thoughts out loud while they complete the tasks you specify. And, with many experience research platforms, you can recruit your exact target audience and get feedback within hours.
Your team can test a new design or user flow within a single sprint, validating that they’ve made the right decision as the feature is built. The process can start with sketched concepts and extend through wireframes, prototypes, and live code.
In this guide, get a look at processes inspired by companies like Google, Facebook, and Home Depot. Companies that have successfully implemented remote user testing into their agile development processes.
Run parallel design and development sprints
Many leading organizations find that the most effective way to incorporate user tests into their agile development cycle is to have their UI/UX designers, user researchers, or product managers, which we’ll refer to as your design team, run a design sprint parallel to their development team.
The purpose of the design sprint is to:
- Identify problems through user research
- Validate solutions through iterative testing
- Prepare user stories for the Product Owner to prioritize in time for the Iteration Planning Meeting (a.k.a. Backlog Review)
That way, while your engineers are writing code for their current iteration, your design team is identifying the problems and validating the solutions for your developers to work on in their next iteration. Some people refer to this parallel process as Iteration Zero because the design team is always one step ahead of the development team.
Design sprint
Conduct user research
On day one, the product owner, UI/UX designer, or user researcher digs into metrics from the live product's existing version to identify the problem areas. Then they run 3-5 user tests focused on those areas to identify what’s causing users to get stuck or confused. If they launch their user tests in the morning, they’ll have results by the time they return from lunch.
If you’re developing an entirely new product, use this stage to do exploratory research. Run user tests on your competitors’ products, or have your target audience show you how they currently handle the problem your product will solve.
Meet to discuss problems
On day 2, the product owner, Scrum Master, and UI/UX designer meet to discuss the problems that were identified through user research. Participants of this meeting should come prepared with metric data and video clips from user tests to use as evidence and guide the discussion. Once your team has defined the problems, start brainstorming potential solutions. The goal is to leave this meeting with a concept for your UI/UX designer to run with.
Test mockups and prototypes
Once a solution has been identified, your designer starts mocking up a solution. Once they have something they can put in front of users to get feedback, they run a user test. Then they iterate on their design based on the feedback they get. They continue to repeat this process—moving from wireframes to low-fidelity prototypes and finally to high-fidelity prototypes—until they validate that the solution solves the problem as intended.
Prepare user stories
Once a design solution has been validated, the product owner and Scrum Master meet to get the user stories into the backlog and prioritized. Each card should include relevant design assets and video clips to support prioritization decisions.
Now that the user stories have been prepared, the product owner and engineering team will kick off the development sprint with an Iteration Planning Meeting. At this point, the design team will repeat the same process to prepare validated solutions for the next development sprint.
Development sprint
1. Meet for an iteration planning meeting (i.e. backlog review)
On day 1 of the development sprint, the product owner and development team meet for the Iteration Planning Meeting. The product owner presents the prioritized backlog, the engineers choose which user stories they will work on during the sprint, and those stories get moved into the sprint backlog.
2. Conduct a tactical meeting
Next, the product owner brings the development team together for another meeting where they look at the cards in the sprint backlog, break them down into the specific tasks they will do over the next iteration, and discuss tactical details.
3. Build software
Now that everything has been planned out, the development team starts building software for the length of the iteration cycle.
4. Validate solutions
Once a solution has been built, either have your engineer or product owner run a user test to validate that it’s solving the problem as intended. Use the same test script as you did for the user test initially used to identify the problem. This will give you a benchmark to judge whether the solution has fixed the issue and maybe even uncover new issues, which should be funneled into your product backlog for future iterations.
5. Complete an iteration review
Finally, hold an Iteration Review where the team demonstrates the software they built during the sprint. Share video clips from your user tests demonstrating that the solution you built has been validated and solves the problem.
Repeat the parallel sprint process
At this point, the design team will have gone through another sprint and prepped the next round of user stories. Both teams repeat their iteration cycles in parallel, with the design sprint always one step ahead, preparing validated solutions for the development team to deploy.
One of the best ways to get the insights you will need to identify the right problems to address and validate solutions is to select the right tools and resources. Choose a solution that will help you rapidly understand how users interact with your product—including where they get confused, frustrated, or fail to make sense of your iterations.
Additional resources
Industry report
2023 Experience Research Industry Report
See how the experience research industry continues to mature and grow as more and more teams understand the benefits of research.
Industry report
Forrester Wave: Experience research platforms
What are Experience Research Platforms (XRPs)? Forrester evaluated the top solution providers in the XRP market to see how they stack up.
Free trial