“Dear friend,

First of all, hold your horses & cool your jets: Yes, I know you might not like the headline of this article - but please chill, keep reading and try not to take it as a personal attack. I love you from the bottom of my heart.

Aviel”

This article showcases how Kadabra UX approaches User Research when working with clients on our Design Sprints. Just for some context, when we talk about User Research, we’re generally talking about it from a User Experience Design (UX) perspective.

I’ll give you an overview of the process, and then takes a deeper dive into how we approach User Research and apply it within a UX Design environment.

Up-front User Research is a form of Product Procrastination. It’s busy-work, it’s a way to avoid making hard decisions. It delays the need to make something tangible.

Some people will kill me, because I know a lot of agencies still makes loads of cash selling a user research phase to companies who don’t know better. Trust me, I know this because we used to do it at Kadabra UX right at the beginning.

It was part of our UX/Product Design package: 2–4 weeks of up-front user research. We interviewed people, we created personas, we made empathy maps… Believe me It’s not that we were trying to milk our clients of as much money as possible, we just didn’t know better, this was the design process! I mean look at every design process diagram ever…

It took a while, but eventually we started to notice a worrying pattern: We would do the pre-research for a specific product or service, do the interviews, create the personas, create the documentation then as soon as we got down designing and testing the actual product, we figured out that even though it was nice to “have the user in mind” when designing, the useful data came from the first user tests, not the research. In fact, more often than not, the personas and other documentation just started gathering dust while the rest of the process continued.

“Oh boy! personas, that’s one way to burn your design budget!”

At about the same time that we were mounting concerns about this wasteful process, Jake Knapp, started writing about’s Design Sprint process. The focus is on getting to a tangible result ridiculously fast (4–5 days) and skips intensive up-front research in favour of immediately testing a high-fidelity (realistic) prototype. The idea really resonated with me as it matched the kind of real-life, practical results we were seeing, but I didn’t believe it until we actually ran through the process with a new client. We sold them 1 week instead of our typical 6–8 week package and started it completely cold. No research, no benchmarking, no brief. 5 days later, we were further along with this client’s product than we’d ever been in our 6–8 week package. The Design Sprint process exposed that our own design process was mostly filler!

It turns out that being able to put something tangible in the hands of your potential (or assumed) customer gives you infinitely more valuable data than just researching and documenting, then trying to build assumptions from that. Let me be clear: in both cases we are just making assumptions. We do not really know what our potential users will really respond to, what they will understand or what they’ll hate until we really see them using it. So whether we spend the first 4 weeks trying to learn what they like, how they behave and whether they’re a “mobile native” or not, OR just make assumptions then test them 4 days later, we’re still only seeing the really valuable, usable data once they use the product (or the very realistic prototype of it).

And yes, there are cases where up-front research makes a lot of sense, especially if it’s not clear what sort of problem exactly needs to be solved (i’m thinking here of improving the Emergency Room of a hospital for example). For the most part, though, I recommend ditching the time consuming, wasteful up-front research in favour of tangible results.

I would like share with you my user research approach that I’m offering our clients before a design sprint.

First step is preparing a form for everyone that will be joining us from the client side to fill out. I’ll show you what it looks like….

The goal of the form is to collect inputs from all the team and make sure everyone is aligned.

We’re asking the client about the next step in the project in order to tailor the report at the end of the sprint. The sprint is great in giving you momentum. We would like to carry the momentum throughout their work on the product.

We ask them what is the best format, assets, or what are the most important things that you need to get out of the sprint and plug right into the next step, so the client can continue moving fast and iterating.

Also, we ask our clients:

1. What is the challenge you wish to solve in this sprint?

2. How will solving this challenge benefit the business?

3. Why is it important to solve this challenge?

4. How will you measure the success of solution?

5. Who is the target customer for this challenge?

6. Who are your biggest competitors with regards to this challenge? etc…

And then we collect all the inputs and organise the inputs.

After that we will conduct 1:1 sessions with the team in order to get more details about the business challenges, what they would like to achieve, and users pain points (customer support, marketing sales people, etc…)

Also, we will start to look for other products that solves the problem that we would like to solve that might be relevant in terms of interactions.

On the alignment workshop on Friday, we will choose the problem that we would like to solve and vote.

Also we will draw the product journey and decide which area of the product we would like to focus on.

Now I would like to fast forward to the end of the sprint and to show you how we’re conducting user testing. So we are using a real time board to collect all the feedbacks.

This is the wall of justice which is explained in the sprint book, but we have it in a digital form so you can share it with the client.

At the beginning of the testing we are having some priming questions in order to make the user feel comfortable, and then we are showing the user the prototype and recording his feedback per screen.

At the end we’re having some questions about the experience, so make sure we capture this information too.

Thanks for reading! Give it a ❤ if you liked it 🐠

Come say Hi 👋 and learn more about Design Sprints, product design and product strategy on my super cool Youtube channel Instagram, and Behance