The Agile manifesto says: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Yet User Experience (UX) teams have traditionally struggled in the Agile environment. That’s because the feedback you get from customers only occurs once the finished ‘thing’ is live and being used by the customer.
Most Product Managers, UX Designers and UX Researchers are trying to figure out how best to embed customer feedback in the problem definition and design phase, as early & as often as possible, so that they can save time and money by not building and releasing a product that users don’t actually want or need or cannot easily use.
In a traditional waterfall development process, you get weeks or months for discovery, with plenty of time to conduct just the right research. So, on the surface it feels like research (customer feedback) might not fit within rapid agile development.
Typical challenges to integrating customer feedback during product definition & design iteration phase for agile:
- Assets are too ‘early-stage’ for gathering useful insights
- Participant recruitment takes far too long
- The team lacks the necessary research skills
- There are just too many research questions to answer every 2 weeks
The solution(s)
The good news is, all of the above can be solved, you just have to learn to adapt your methods to be more… uh… agile. Once you figure out your research goal, the same UX research methods you traditionally use still apply, you just have to adapt the methods to fit the time frame.
1) Pre-plan with the Product Owner, Designer, and Researcher
Get Stakeholder buy-in and support early on. Gauge to see if your stakeholders are excited about getting UX research into an agile cadence? If yes, then great! If not, then it’s time to help them understand the risks they’re taking by skipping research during design and identify which of the perceived barriers they believe to be true. Look for success stories and sharing share them with your team.
Decide on a research cadence: a 5-day, 8-day, or bi-weekly Sprint suit your organization best. Add research activities as agile “stories” with “story points” to fit into agile cycles. Pre-planning research, even when you don’t know exactly which assets will be available when works best for several UX teams. Time box research like other activities in agile sprints.
Top five questions that product owners and designers typically need to ask & answer are as follows, with some simple ways of answering them:
A) Before we start designing, what’s most important to the customer? Answer: A simple survey might be a solution.
B) What do users think of this concept? Answer: A simple prototype and small sample think out loud basic usability study might provide some insights.
C) Can users find items on a screen? Answer: A simple ‘click test’ or ‘5 second time out test’ with a static screenshot might do the trick. High fidelity prototype might not be needed at this stage.
D) Are there usability issues with this prototype? Answer: A typical small sample unmoderated usability test might provide some top issues.
E) Should we use Design A or Design B? Answer: Depending on the level of decision & the impact on business a simple basic usability study would do. Alternatively, this might need a higher sample size study to be confident in the outcome of the decision.
2) Run early-stage design tests
You don’t need to present users with finished, or nearly finished assets to gather useful feedback. You can start getting actionable insights on very early designs – even hand-drawn sketches, as well as wireframes, flat visuals or prototypes.
This type of early-stage design research is known as directional testing, and can often be as simple as checking where people would click on a series of flat images, or a think-out-loud study of a more complete journey in a tool like Axure or AdobeXD or Figma or any prototyping tool.
3) Use a recruitment service that can source participants for you within hours or create your own ‘standby’ pool of participants
With traditional recruiting approaches, it can be a struggle to recruit enough participants within a Sprint to conduct testing. Even finding one or two participants that fit your profile can be a challenge.
However, if you use an automated participant sourcing engine, such as our own IntelliZoom, where you can choose from a global pool of more than 120 million users, you can source in advance and be able to view results within hours of launching a study. Giving you something better to do with your time than looking for users.
If budget is an issue, you could create your own small, reliable pool of participants to have at the ready before your Sprint. These people could be gathered from your mailing list or via a pop-up on your site/app.
The key is to get enough information to be useful without losing the integrity of your research efforts.
4) Democratize UX research with templates that don’t require a Human-Computer Interaction degree to use
Just because there’s no researcher in your Sprint team, it doesn’t mean your team has to skip user research. In fact, you can speed up and scale the entire organization’s research capabilities without hiring hundreds of researchers by ‘democratizing research’.
This simply means enabling non-practitioners to run their own tests within Sprints.
You can do this by using a UX platform, which automates time-consuming activities (like recruitment) and is already pre-loaded with test templates – to enable designers, product owners and anyone who is not a full-time researcher to run their own testing, quickly.
Or if you have a minimal budget, you could set up your own repeatable study templates to answer the most common questions that product teams need answers to.
5) Answer the most impactful questions first and consider implementing a research backlog
You need to be clear that it’s simply not possible to test everything (or even most things) while running research in Agile. However, working in a two-week sprint should focus your mind on answering questions that will be most impactful to the business.
Rather than measuring your output (just finishing the product), focus on the outcomes (delivering revenue, driving conversion, making $$$) by answering fewer, but more business KPI related questions, faster.
In contrast to directional testing, you can carry out foundational research (exploratory research on a topic that hasn’t been clearly defined) on a separate track over weeks and months (example: Sprint 0). This ensures the big questions are given the time they deserve so you can reach the right, user-centered conclusions.
Kuldeep Kelkar, VP of UX Consulting & Professional Services, UserZoom