Too much user research can be just as harmful as too little.
User research is a vital tool for validating and justifying your digital product roadmap. But it can also be slow, resource intensive, and difficult to get right. All of which present real problems for companies that need to move at pace.
In this 30m webinar, we’re looking at user insight sprints. It’s a framework we’ve developed to uncover “just enough” research, based on the principles of the design sprint.
This session covers:
- How to go from zero to a reasonable set of user insights in just five days
- How an insight sprint can build solid, educated foundations for product teams to build on
- A five step process to identify pain points, themes, patterns and opportunities in your customer journey
This webinar will be especially relevant for strategy, design and product teams who:
- Have a specific audience segment or sector they need to know more about
- Want to drive innovation and product development, but aren’t sure where to start
- Need to provide validated support for their product roadmap to the wider business
Video transcript
Hey, welcome to the webinar. Thanks for joining me. I'm Nick, I'm a strategist here at 383 Project. Today, I'd like to talk you through one of our favourite research methods; what we call an insight sprint.
When it comes to innovation and product development, the key is to really make educated guesses and really place informed bets to get your product off the line. Uncovering insights about your customers and their lives is definitely the best way to do that.
But user research can be a slow and lengthy process. So, how do you marry up gathering all of those invaluable user insights with the need to really develop products at pace, which a lot of us have to do these days to stay competitive? Well, at 383 we use insight sprints, and today I'm going to show you how we do it.
So, what is an insight sprint? Well, in a nutshell, it's a blend of traditional user-centred design thinking and the sorts of ultra-fast development that we see in Google design sprints.
The great thing about insight sprints is they give you just enough research to help you place an informed bet on a product without getting too bogged down in gathering all that research and synthesising it.
In fact, this is actually something that the guys at Google pretty much do anyway before a design sprint; they just don't really talk about it in the book. So, this is actually a legitimate part of the design sprint process.
But before we expand on what an insight sprint is and how you run one, let's just take a moment to look at what a design sprint is and what design thinking is, and what the difference is between those two - how this fits into the sweet spot in the middle.
With design thinking, you have a really deep, human-centred approach and a lot of time is spent really getting to know the needs and requirements of the users. All sorts of things can go into this; stakeholder research, field research, competitor research, building personas, doing empathy mapping, doing analytics. And you get a huge depth of insight and all this can be really, really valuable.
But the flip side of that is that it can take a long time, and sometimes it can take months and months to gather all that stuff. Now, that really deep approach sometimes can 100% be the right thing to do, particularly when you don't know much about your users or where they're struggling, or you don't really know where to start.
In fact, at 383, we do use that approach a lot, and we've actually got a brilliant process for this called friction mapping. And you can learn about friction mapping through another one of our webinars presented by our Head of Design, Karl, where he talks you through the process of doing this kind of approach and where that deep level of insights can really pay off. So definitely check that one out!
On the other side, you have design sprints. So design sprints are an ultra fast, super practical approach that really accelerates products into the hands of real customers to learn what works in the real world.
And when we say fast, we really mean fast. You can go from concept to fully validated low fidelity prototype in as little as four or five days. You can actually dream something up, sketch it out, create a very low fidelity version of that, and actually have that into the hands of real customers to give their feedback in less than a week.
We're huge fans of sprints at 383. They're a great way of chopping out all of that procrastination and really focusing on the core benefits of that product for your user, figuring out what will work, what won't work.
We've actually built up a whole rapid prototyping approach based on that sprint approach, which takes you through a very, very accelerated timeline from concept to validated prototype.
But sometimes neither of those tick the box for us. Sometimes we just don't have the luxury of investing all that time and effort to do the deep, human-centred design thinking for a client. And then we might also not be certain enough about the customer's needs to kick off a design sprint. We're kind of caught between the two.
And this is where insight sprints really come into their own. They provide a really quick hit of research before we can start diving into that rapid prototyping flow. In that way, they're the perfect companion to a design sprint. Again, they provide just enough insight to let you hit the ground running without getting bogged down in doing loads and loads and loads of research up front.
And of course, that means that they're also the perfect companion for our 383 rapid prototyping process. You can see here, within that workflow, they drop in really nicely at the start.
Having that level of research and insight up front means that we can very quickly start ideation and development of those products on a fast track sprint, but with a really strong foundation on which to build.
So what are the advantages of an insight sprint, and how do they stack up against other methods of getting insight about your users? For instance, how might they be better than just doing a survey?
Well, with a survey, you're only going to get back the insights from the questions you ask. And that means if you get those questions wrong, you've either got to do it all over again, or even worse, you might end up with some bad data without realising it.
And more importantly, with a survey, you don't know what you don't know. You're only going to get the answers back to the questions that you ask. So, if there's a gap there in your knowledge or your assumptions, your surveys aren't going to show those up only by asking questions related to the problems and patterns that you already know about.
If you do that, you're going to miss out on some big opportunities or some unknown customer frictions that could be really holding your product or service back.
In this respect, surveys are kind of like text messages. They're a one way method of communication where it can take a long time to really get to the truth. And really, what you should be going for is something that feels a little bit more like a phone call, where you have a flowing conversation and you can really get into more depth a lot more quickly about the things that your user wants in a way that you might not otherwise have uncovered.
What about analytics? Well, obviously data is hugely powerful and it should absolutely be one of the weapons in your arsenal. But again, it's limited. Data could only really tell you the 'what' of what you're seeing and not the 'why' behind it. And that 'why' is really, really important if you're going to design truly effective products and services.
We've talked about what an insight sprint is and what the advantages are. How do you actually run one of these things?
Unlike a fast track sprint, where we're looking for validation of a specific assumption, the insight sprint week is all about getting rapid insights about a key audience or subject that we need to know more about.
When we look at this in the context of a Google five day design sprint that we mentioned before, how does this fit in with that? Well, design sprints are awesome. We love them. We use them loads. But the problem is that if you go into it with a very poorly defined challenge or a misunderstanding about your audience needs, the thing that you end up testing on day five might not be as good as it can be, particularly if you're relying on gut feelings.
They kind of have to be backed up by gut feelings coming from somebody that has the experience or insights that you need to understand the problem or the audience. And if you don't have that, it can limit the effectiveness of the design sprint.
This actually gets past that problem by giving you a more solid foundation to build a sprint on.
Let's have a look at three of the things that we might typically do. We usually kick off a project like this with an immersion session. An immersion session is where we, as an agency, sit down with a client or stakeholders and we fresh out the problem. We find out what the brief is and understand the context behind it.
Some insights will come out that immersion session, but that usually gives us the 'what' of what we're looking at. This is the problem, these are the patterns in the data, this is the thing that we're trying to solve.
The insight sprint then gives us a week to go and delve into the 'why' about why we're seeing those patterns. Why are we seeing those things in the analytics? Why are we seeing this product fail? Why are we getting these responses from our users? We get that luxury, then, to figure out the underlying root cause behind the patterns that we're seeing.
The design sprint then let's us play around with the 'how'. We've spotted the patterns and the problems, we now understand why they're happening, now let's figure out how we can make those user pains go away or deliver on the goals that they're trying to do.
Getting into that rapid prototyping flow through design sprint and everything that comes out afterwards, we could then begin to figure out the problems that we've seen.
At the end of an insight sprint week, we should have a whole bunch of insights that we can go and do something about, then. Hopefully we can see the user pains and goals on a high level. What are our users trying to achieve? What have they told us that they're trying to get done, or what are they struggling with?
We've then got themes and patterns. Hopefully, once we've done our homework a bit and we've talked to multiple users, we can then see what are the common things that crop up between them and see where these areas cluster together, where we might be able to kind of come up with a solution that solves multiple things at the same time.
We've then got some background insights. As part of the research process, we're going to get perspectives from outside of the company, we can do some desk research, we can look at some competitor activity, we can look at white papers or academic insights, and we can build a good base of broader, general insights into this problem we're trying to solve.
We've also hopefully got some expert insights. Throughout the course of the week, as well as talking to users, we're also talking to subject matter experts either from inside of the company or outside, to get that lens on their expertise and what they think, as experts in their fields, that we should be doing.
By the end of it, hopefully, we'll be able to tee up some next steps and identify some real opportunities to take some action on, as we go into rapid prototyping later on.
What is the insight sprint and what process do we follow, then? It's actually based on a modified Google design sprint. We take that same four or five day structure and we have similar steps in there, but actually the purpose of those steps are different.
With a design sprint, what we're trying to do is, we've got an idea and we're trying to find a way to test it. With an insight sprint, actually, what we're trying to do is actually figure out more about what this problem is that we will later test out in the Google sprint, and who these people are that we're designing the products and services for.
There's five rough steps that we're going to take. The first is, on day one, we'll review the assumptions we have about that audience or that problem that we're trying to solve and we'll ask some experts about those opinions. Here, we are going to sit down with our project stakeholders and really make sure we understand the problem.
And then we're going to bring in some of those outside experts. This might be experts within the company - this might be people that deal with customers on the front line, customer service managers, or call centre operatives, or people that look at the data and analytics a bit more, who can tell us more that we need to know about this particular audience set.
The other thing I should say as well, with an insight sprint, it's always best to really narrow down the audience that we're trying to understand. We're looking for a particular audience segment. So, if we were doing this around people buying a new car on finance, we wouldn't want to look at everybody, we might just look at new customers on a particular product, or returning customers, or something like that. We want to be as narrow as possible, otherwise we're going to be too broad and not find the patterns that we want.
The next stage is field research and desk research. This is usually a day reviewing any information that our clients or stakeholders have provided for us to look through. It could be also doing a bit of competitor analysis or reading around on white papers as well. Depending on how big your team is and what the problem is you're trying to solve, it can be good to get a couple of you out of the office to actually go and do some field research and see how customers or the audience types that you're looking at are actually living their lives or trying to solve a particular problem.
Next, we have the user jobs to be done interviews, and these are the real crux of the week. We will do five user interviews and we will have developed a user interview script throughout the week that we've done so far to elicit some questions and insights about their lives or the particular problem that we're trying to explore through it.
Once we've done those interviews, we'll then synthesise what we've found and codify what we've learned. And then once we've got those insights, we will then play that back to the stakeholder.
We can actually vary the sprint up a little bit, depending on the problem that we're trying to solve. It's always a bit more of a starter for ten rather than something that's set in stone.
For instance, if we're using the sprint to actually find out more about our competitors, what we might do is actually have the user interviews on the second day, and then depending on the other products and services that they've mentioned that they use to try and solve the particular goals that they've got as our customers, we might then feed the things they tell us into our competitor research and make that happen on day three.
Let's talk a little bit more about the ideal team for doing an insight sprint. At 383, we will typically use a three person core team on this. We will have a strategist or a researcher, we'll then have a designer, and then we will have a project manager on there. We pick these three because when we get into the rapid prototyping flow afterwards, these will be the people that go into that rapid prototyping process and they'll all bring their own particular strengths and insights and skills to the table there. Actually getting them involved in the research at this stage can be really useful.
We'll also have members of the client team involved as well. If we are working for a client or stakeholder, we'll have some insight, particularly one person who might be owning this from the client side as well. We'll also bringing some subject matter experts who can give us the insights that we need, typically two or three experts that we can talk to for half an hour and just pick their brains on stuff. Then we've got the five users that we're going to interview as well.
Of course, if you're doing your own insight sprint and you're not going to use us or an agency, then you can bring whoever you want into this. We recommend having three people as part of the core team just because it just means you can cover all the basics a bit more.
And again, you're probably going to have your own internal clients or stakeholders, you're going to have your own internal subject matters you can draw on, and you'll probably recruit your own users and those might even be internal users. This isn't always about paying customers. The customers could be the people within your organisation who are going to be the benefactors of a new tool or process that you might bring in.
Quick note on recruitment here. If you've never really done anything like this, it's worth noting that recruitment is always a far bigger pain than you think it's going to be. For this particular type of sprint, it's worth thinking about it in advance, because you don't really have much time to play around in the week because you're actually recruiting for user interviews that happen on day two or three rather than day five. It's worth teeing this up in advance, knowing who you want to talk about before you start the sprint week, who you want to talk to, who your users are and what you want to ask them a little bit more.
Let's go through the days and the steps in a bit more detail then.
Step one; review those assumptions and ask the experts. On this day we're mapping out the challenge and we're doing those expert interviews. This is where we're just trying to really make sure that we're coming about this challenge in the right way. This is where the core team will really sit down with client-side people to figure that out a bit more. At the end of the day, we should have our stakeholder insights mapped out in rough notes and we should also have the subject matter expert insights mapped out as well.
This could be as simple as just sticking some post-it notes up on a wall. At 383, we use tools like Miro, which is a digital whiteboard, and we also use things like Dovetail, which helps us to keep on top of our research notes as well. But if you want to use Google Docs or just scribble it out on a piece of paper, whatever works for you.
The next step, field research and desk research. The field research would typically see us go out on the front line, just observing either people within our company interacting with customers or maybe going out and seeing what the customers are doing in their day to day lives. Usually we'll take a couple of people out to go and do this who can then compare notes or ask questions and write observations down, or divide and conquer and see different parts of the process.
We've then got our desk research. We'll either have one or two people doing this and, like we said before, we'll be reviewing business data or going and seeing what's happening out there in the wider marketplace.
By the end of the day we'll have our research highlights from the field research and desk research, and already we'll also be trying to piece together our user testing scrip. We'll be doing this all the way throughout the week but certainly by this point we need to have that finalised by the end of the day as well.
Then, we've got the user interview days. We do our five interviews. These are all typically 45 minutes long, maybe a little bit longer. They're very intensive, back-to-back, all on one day. We'll video these and audio record these as well so we can come back and use those in the future, or maybe give those assets to our clients, as well.
Because of the pace that we do these at, we do a live synthesis exercise. While one person is interviewing, two of the other core team will actually be capturing the insights that come from those interviews in post-it note fashion, capturing those down under each user that we've got.
Then we've got synthesis and codification. Here we spend a day taking the things that we've learned throughout all the other bits of research and doing pattern recognition on it, finding the clusters and themes, and then documenting those in a way that we can then codify them. We always like to, on the end of day four, have a bit of an internal review. We'll get some people around 383 to come and we'll play back our findings to them and just see how clear they are or see if there's anything that needs to change within those before we finalise it.
Then on the final day, we've got the final amends on the insights that we've got. Once we're happy that they're polished up, we will then play those back to the client and share any documentation after the playback that they might need as well.
Sometimes, as well, we also create a visual artefact for our clients and this is an example of what one of those might look like. Once we've looked at the patterns and frictions that have come out, we could then put them on a little diagram like this.
What we've got here is, we've got two axes, we've got low anxiety to high anxiety, and low frequency to high frequency. What we can do, as we do our user interviews, is we can figure out as we talk to our users what are the problems that they're encountering, or the needs that they are identifying, and how important are those needs. We can also look at how often those needs crop up, as well. Between the severity of the pain or the opportunity and the frequency at which it comes up, we can actually plot them on a diagram like this.
Then what we've got here is three bands of action. The low anxiety or low frequency problems, we tend to ignore. The medium frequency or medium severity problems, we can add to a backlog and maybe come back to later on. The frictions that are particularly high severity or high frequency, or both, we can turn into priority actions to try and do something about in a later phase of our rapid development. This is where putting something into ideation sessions or a sprint really comes into its own.
How do we actually put those insights to work? What comes next?
Like we said before, the design sprint is the perfect companion to this. This is our work up to the insight sprint, if you will. The good thing about actually doing the insight sprint first is that having stronger insights coming into a sprint means that we're going to have better ideas to test on day five and we've got a good, solid foundation to build upon.
The other good thing as well is that you don't always have to do an insight sprint for every fast track sprint. Actually, if you were trying to come up with a whole bunch of ideas or solutions for a particular audience, doing that homework upfront and then going into some sort of ideation workshop to come up with ideas could then tee up lots of fodder for fast track sprints and lots of parallel tracks that we can then follow into validating those and turning them into actual products and services later on as well.
There we go. That's insight sprints 101, done and dusted. Hopefully that's given you some food for thought about how you can quickly and effectively kickstart your next development project with just enough research to get you going.
If you want any more advice on insight sprints, or if you'd like to find out more about some of the other research, design and rapid prototyping tools we use here at 383, just check out the website, drop us a line, and we'd love to explore this with you as well.
Thanks for joining me, and good luck on your insight sprints. I'd love to hear what you think about the process and whether you think they work or how we can improve it, or if you've got any great examples about how you've used these in your own business. I'll be back with more webinars in the future, but until then, good luck with your products and services, and good luck with your next insight sprint.
