Agile Research: Enhancing Web Projects with Ongoing Feedback

Large web initiatives often kick off with an initial research phase. The thinking is that investing in up-front research will pave the way for a successful project and ensure that what gets built meets the needs of your end users. This sounds great in theory, but large up-front research efforts end up being a costly and time-consuming way to produce documentation that often gets disregarded. 

Web Project Research Strategies and ROI 

For the best ROI (Return on Investment), you need to deliver content, features, and functionality that helps your end users. It must be informative or useful and easy to use. The best way to ensure you are building the right thing is to get input from the people you are designing for. While customer feedback can be incorporated into any type of project at any time, agile projects are more conducive to ongoing feedback cycles. In contrast, waterfall projects favor up-front user research.  

Conducting Research in Waterfall Projects 

In waterfall projects, research typically precedes design and development. The rationale is that an implementation team won't agree to a timeline and cost without seeing the design. So, all design happens ahead of development. And the design team will want customer insights before, not after, they do the design work. 

Whether all work is performed by one team, or multiple agencies or departments are involved, the work is usually divided across projects. This introduces several problems, which can be compounded if contracts are involved: 

1. Because each phase influences the scope of future phases, delays between phases occur while contracts and scope are finalized. Even if the deadline is fixed, precious time is lost to contract negotiation. 
2. As the timeline extends, so does the distance between initial research and building the site. The further removed teams and stakeholders are from research findings, the less impact those insights have on decision-making. 
3. The longer a project lasts, the more likely it is that the research will become (or seem) stale. Customer expectations may evolve. Stakeholders may change, and new stakeholders may place less weight on research conducted before they were involved. Insights that were once fresh in people’s minds slip through the cracks, making teams more dependent on research documentation. 
4. Comprehensive documentation becomes a necessary measure to prevent insights from getting lost across hand-offs. While capturing customer insights is important, this approach increases the time and cost of documentation—thus increasing the barrier to development. 
5. The cost in money and time for up-front research makes future research a tougher sell. Often, higher-ups who approve funding could care less about the value derived from the research—they just want to see the project completed and have been convinced that research is a blocking cost. Spoiler alert: most people who fund projects and have invested in an upfront research project think twice about spending more post-development to potentially discover that what their teams spent many months building is not quite what end users want. 

Some waterfall projects do incorporate feedback at different points across the entire project, such as during design or after development. But the reason most research is front-loaded is that in a sequential workflow, it’s much easier for insights to move downstream than upstream. For example, if you learn that users are struggling with a feature on your website, it's easy to incorporate that feedback as you enter the design phase. In contrast, if you were to discover this information during implementation, it could affect your scope. After all, the design was already signed off on, and the development scope was based on the design specifications and functional requirements. Substantial change can require a change order or eat into your contingency budget. 

Either way, these new insights mean the agreed-upon plan will change unexpectedly. And in a waterfall project, protecting the project means protecting the plan. 

Conducting Research in Agile Projects 

Agile projects still value research to collect insights and inform decisions, just not as a large and blocking precursor to starting implementation. The agile approach emphasizes delivering completed, demo-able work in small batches and encourages frequent feedback loops so learning can happen continuously. This has a few advantages: 

1. Working in sprints creates an opportunity to conduct research for future work, validate in-progress ideas, or test completed iterations. 
2. Conducting research and usability testing in smaller chunks can reduce planning effort and allow the research to be more focused. 
3. When user feedback and concept validation occur at regular intervals, it reduces the effort to correct things, because it prevents the team from straying too far down the wrong path. 
4. Feedback carries more weight because it is relevant and applicable to decisions being made at that time. 
5. The documentation effort decreases. Because research happens in small, regular intervals and is being acted upon, documentation need not be as comprehensive. You aren’t trying to document any and everything a future dev team may need to know. 
6. Seeing the direct, timely connection between research and design decisions increases the stakeholders’ perception of its value. 

With an agile approach, there is a better return on investment for the money you spend on research because you learn what you need to learn, when you need to know it. Being timelier and more relevant, it carries more weight with stakeholders. Smaller ongoing investments in research seem more palatable to stakeholders, paving the way for continuous learning.   

A Healthier Way to Think About Research 

User research can take many different forms. It can include interviews, observation, usability testing, and participatory design just to name a few. When many people think of research in the context of web projects, they usually are considering: 

• How can we learn what our users want? 
• How do we know if we built the right thing? 

The catch with this mindset is that it frames research and testing around what’s getting built, positioning research before design and testing after development. An alternative outlook is to shift the focus on research from what we are building to what we are assuming. In projects, decisions are made daily based on assumptions about what users want and how things should work. Lean and agile research methods promote testing these assumptions often. By replacing assumptions with quantitative data and qualitative insights, we reduce the risk that teams will waste time and money building features that fail to produce the desired outcomes.   

Making the Shift to Continuous Learning 

Regardless of your project approach, some research is better than no research. Too many times I have seen teams disheartened when research gets cut from a project scope and considered an unnecessary expense. Business stakeholders are typically more interested in outcomes than the process. In their defense, research is often pitched and performed in a wasteful manner that does not make it worth the investment, given budgetary constraints.  

As advocates for research, we need to spend less time preaching the value of research and standing on principle, and more time developing pragmatic approaches to how it’s incorporated. We need to take research off its island and embed it in our workflow in a way that expedites, rather than blocks, the delivery of business results and improved user experiences.  

Shifting from large up-front research projects to continuous learning in an agile workflow can help you make faster and better-informed decisions throughout the duration of your project.  And keep in mind, there is nothing to preclude some research from occurring pre-design or post-development. It’s a matter of not blowing your entire research budget upfront or holding site development hostage in the process. 

Recommended Reading

Interested to learn more about this topic? Check out the following articles, and work by these authors:

• Solving Agile UX: Advice from Laura Klein
• Product Discovery Basics: Everything You Need to Know by Teresa Torres
• Lean UX: Getting Out of the Discovery Business by Jeff Gothelf