Why iterative design isn’t enough to create innovative products
Iterative design is a proven approach for optimising the usability of a product or service. Teams create prototypes, test them with users, find problems and fix them. But iterative design does not guarantee innovation. To develop innovative designs, we need to question the way we have framed the problem and instead focus on our users’ underlying needs.
Innovation: it’s about more than bean bags
The 21st century organisation, we’re told, needs to be innovative, creative and customer centred. Senior executives implore their staff to get out of the building. HR departments clear desks from a meeting room and replace them with beanbags, a foosball table and a games console. Teams install whiteboards and plaster them with sticky notes and flow diagrams.
Then the work starts. Users are recruited for research. Customer conversations are analysed, interpreted and then presented as fundamental truths. Iterative design and usability testing becomes a new mantra. Teams adopt an iterative development methodology like Scrum.
And the benefits are immediate. Week by week, products get better. It seems to work.
But then a startup appears, disrupts the industry and changes the rules of the game.
Iterative design can be deceptive. It does a great job of delivering incremental improvements. Those improvements build upon each other after each iteration.
But iterative design is not enough.
We end up with incrementally better versions of the same product. But what if we need an entirely different product? How do you truly innovate?
Two kinds of research
In 2005, the Design Council introduced a design process model known as the Double Diamond. Divided into four distinct phases (Discover, Define, Develop and Deliver) the model maps the divergent and convergent stages of the design process, showing the different modes of thinking that designers use.
I have re-drawn the diagram below and annotated it with some of my own thoughts. (Click the image for a larger view.)
On first glance, this may feel like a familiar process. But my experience with design teams shows that they don’t spend much time, if at all, in the ‘Discover’ phase of this model (where they are understanding how users solve the problem now) or in the ‘Define’ phase (where they decide on the user need they will serve). Yet it’s in these two areas where teams have the best chance of creating a great user experience.
Instead, teams rush to optimise the usability of a solution based on preconceived ideas before they have properly explored their users’ goals, needs and motivations. This is a common problem in organisations that use Scrum, because managers want to see developers developing.
Yet an exploration phase is critical to innovation because you will never iterate towards a transformative solution. If you start with a web site and iterate, you'll end with a web site. It may be the best possible kind of web site, but it's still a web site. To be truly innovative, you need to spend serious time in the Discover and Define phases to give you the ideas you need to create innovative solutions in the Develop and Deliver phases.
Teams aren’t always aware that they are making this mistake because they do indeed explore a range of alternatives in the later, ‘Develop’ phase. In this phase, teams run usability tests of prototypes and modify the designs based on the results. It’s easy to mis-characterise this kind of iterative design work as ‘Discovery’ and ‘Definition’.
Don’t get me wrong. I think usability testing is a terrific tool. However, a usability test is inward-looking. It focuses on the detail of the thing you’ve designed. The aim of a usability test is to discover how people do specific tasks with a product and what problems they experience when using it. Since you will only ask people to do tasks in a usability test that your product will support, you’re unlikely to spot significant gaps in your thinking.
A field study, on the other hand, is outward-looking. It focuses on the big picture: how people currently solve their problem. The aims of field research are to discover the workflow across multiple channels, user behaviours, needs, goals and pain points. With field research, you don’t know what you don’t know. It’s here where true innovation happens.
How can you tell if you’re doing it wrong? Seth Godin has famously said, “Don’t find customers for your products. Find products for your customers.” So to check if you’re in the ‘Discover/Define’ phases and not in the ‘Develop/Deliver’ phases, ask: “Are we showing users a prototype?” If the answer is Yes, you’re actually in the ‘Develop’ phase because you’re already thinking in terms of solutions. This isn’t the way to become innovative. Innovation happens only when teams fundamentally question what they are designing — and the best way to raise these questions is by understanding users’ needs, goals and motivations.
From field research to innovation
So to be truly innovative, we need to discover the boundaries of the research domain and the rough shape of the experience for which we are designing. We make progress by creating hypotheses about the context of use and we then test these hypotheses to help us understand what’s going on.
One of the interesting challenges with field research is that you are not making predictions about an audience. With innovative, discovery research, you are making predictions about an experience. This can cause difficulties for design teams who believe they already know who their users are. The team may expect you to speak with representative users, but if you do this, you’ll be digging in the wrong place. With research in the discovery phase, when we are trying to innovate and come up with new product ideas, we don’t know our audience.
As an example, let’s say we want to understand how people use headphones because we want to innovate in the headphone product space. We need to start somewhere so let’s begin with a commuter who wears headphones on the train. Then we ask: “Who is most different from that user? Who would be the ‘opposite’?” That should lead us to someone who has an entirely different context: perhaps an audiophile who uses headphones only at home. But we still haven’t explored this space fully. Let’s look at some of the edges: professional musicians; sound recordists; teenagers.
These types of user will probably fall squarely within the preconceptions that the design team has about its users. But now let’s look further afield. To adopt the terminology of jobs-to-be-done, we might question what “job” the headphones are doing. If people are using headphones to shield out noise at work from co-workers, then maybe we want to understand the experience of people who wear ear defenders. If people are using headphones to learn a new language on their commute then maybe we want to look at the way people learn a foreign language.
One of my favourite examples comes from IDEO. They were designing a new kind of sandal. They expressly included outliers in their sample, like podiatrists and foot fetishists, to see what they could learn. This is what I mean by understanding the boundaries of the research domain.
How to stop a start-up
If you work in a large organisation, there will be established ways of working that may pose a problem for this approach:
- Perhaps you’re already struggling to get senior managers to move from a waterfall-based development methodology to a more iterative, agile approach. In this case, you may find you are neither innovative nor iterative.
- And if you are already using an agile approach, like Scrum, you may have another kind of problem: the team may be so fixated on iteration that development starts on day 1, before suitable time has been spent in Discovery.
But there’s a start-up snapping at your heels who is trying to eat your lunch. No amount of iterative design will stop them. Iteration is not enough: you need ideation too. So don’t just create the best possible thing with iterative design. Create the best thing possible by uncovering what users actually need.
David Travis, March 2017