Design research has changed In the 1990s, when the term ‘design research’ emerged, the fledgling practice faced a credibility problem, as many designers were resistant to consumer input. Today, most designers appreciate that consumer insights can inspire their work and provide powerful support for their product rationale. Designers and researchers who understand each other’s fields are embraced by the entire design world.
Design and design research have traditionally adopted an approach known as the ‘Waterfall’ method, a sequential, non-iterative process in which progress flows steadily downwards like a waterfall. The project progresses down through the opportunity-discovery phase and the definition phase, before moving on to design-development and delivery, with research focusing on each stage in the design process. While using research at key stages in the design process is still relevant, increasingly design research needs to work in agile environments, requiring an alternative approach.
In this article, we explore a mix of Waterfall and Agile approaches. While both Waterfall and Agile still remain relevant, we believe that this hybrid approach, where you can more easily plan to be agile, can provide a powerful third way to conduct design research in a more time-pressured commercial environment.
Both Waterfall and Agile have their place
We use research to complement product and service development. When these processes change, so, too, do the requirements of the research. Design research falls into two main categories: Formative, in which research helps you define the problem you’d like to design a solution for, and Evaluative, where research evaluates an existing or new design solution. In Agile, both formative and evaluative methods of research are in sync with each other, helping to continually feed back to the development team. The learning objectives are similar to Waterfall, but the cadence and nature of this type of approach requires a new way of thinking about how best to complement product and service development. A Waterfall sequence of events can be seen in diagram below.
Increasingly, especially for digital development, this sequence of events is less fixed. In this agile world, the sequence of events can be seen in the diagram.
Even in a design world that demands its results quickly and in a leaner way, Agile development hasn’t replaced the Waterfall method, since both hold certain merits.
Waterfall particularly suits the development of physical products, since physical developments require time and money to produce, making it harder to experiment with early launches.
On the flip side, Agile suits digital more than physical development due to the significantly shorter and more naturally agile development lifecycle. This allows software and services to be launched during very early-stage development and evaluated in context by real users.
The challenges of Agile
Uncertainty is challenging for larger organisations where the business depends on future growth, marketing and sales find difficulty in Agile’s inherent shift away from predictable feature-based roadmaps. Resource uncertainties and a lack of specific deliverables make Agile research a mean feat for budget allocation. The fast and messy nature of Agile makes it frightening for senior leadership.
Agile development has to face up to existing hierarchical norms of senior management, governance and innovation process stage gates, all of which can block progress or necessitate delivery of meaningless metrics as a measure of success. There are inherent challenges to Agile development’s integration of diverse skill sets – researchers, designers, developers – as tensions can escalate when each is asked to be faster and leaner.
A new hybrid approach
Waterfall is the better-known method – a linear approach, it’s great for planning and rigour, but slow when it comes to change. Agile methods offer great benefits, being collaborative, iterative and lean, but can be wasteful as they plough ahead without much strategic consideration. At Plan, we’ve devised an alternative approach – one that cherry picks the most useful aspects of Waterfall and combines them with Agile’s ability to iteratively test and learn.
Five steps to a hybrid approach
1. Flex on process not outputs
– Being flexible doesn’t mean giving up all output guarantees. Agree fixed types of deliverables, but not necessarily a fixed timeline.
– Combine a fixed Waterfall ‘Discover’ and ‘Define’ phase upfront with a flexible budget for ad hoc research as test and learn commences.
– Be clear upfront about the number of respondents and hours of research, but agree that these may flex depending on how these interviews are conducted.
2. Align development plan and learning objectives
– Use the ‘Discover’ and ‘Define’ phases to align the full development team on a plan with suggested methodologies for how you might test and learn for each learning objective over the course of time.
– Involve the research team throughout, from sprints to retrospectives, so they can adjust their focus – smoothly, since they’re involved in the design discussions.
3. Set up an Agile ecosystem
– Set up a panel of pre-recruited participants you think will pay dividends down the line. Brief the panellists about their involvement and incentives. Keep this panel engaged as active testers and they’ll provide points of view and recount experiences to inform the development process.
– Top up this panel or even recruit oneoff participants so you can benefit from new and long-term users.
– Set up tools to manage and communicate with this panel including a clear respondent framework for tracking responses, and a digital research platform to communicate with the panel – a great springboard to test and learn from at the drop of a hat.
4.Integrate teams but maintain functional expertise
– Use a research team that can identify with all perspectives (design, research and strategy). Researchers with such a background can bring insights to life in meaningful and actionable ways, and free up development teams, as research teams can solve problems like early mock-ups for research stimulus
– Involve design and development in the research as much as possible. Design and development teams involved in the research first-hand are more likely to get to actionable insights faster.
– Involve the research team throughout – in sprints and retrospectives, but also in design sessions as the voice of the consumer. By knowing the design work inside and out, they are able to shortcut to what is important, and what and how to communicate this.
5. Set up a communication infrastructure
– Align the research cycles to the development sprint cycles.
– Use templates that reference the learning objectives to assist with fast translation of insights as a means of guiding the team.
– Hold mini research debriefs mid-sprint cycle to share high-level insights as well as immediate development actions.
– Keep track of all insights via an insights database so that learnings can be tracked back, developed and evaluated over the course of time. These can be applied to metric data from the development cycle, to bring them to life or add rationale – key for reassuring senior exec teams of the validity of results.