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.
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.
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:
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.
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:
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.
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:
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.
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: