How to choose the right sprint problem
Lisa Jansen is service design lead at SMS Management Technology based in Canberra, Australia. With over 10 years experience leading user research and service design, Lisa has accumulated a wealth of expertise and wisdom that she’ll be bringing to our shores for UX New Zealand 2017.
Over a year ago, I made a career change. I didn’t change my role (once a designer, always a designer…) but I changed my industry. I moved from being a Federal government employee, to a private consultant.
After I did this I realized I could adopt new approaches that government never really catered for. So I learnt about the Design Sprint. For me, this five day agile approach was a way I could apply the design fundamentals I’ve been dealing with for over a decade, but in a new way. It allowed me to facilitate rapid processes in the privacy of a team that I could take from a problem to a tested idea. It allowed me to see it through to a success — or if we realized the idea wouldn’t work, that was a win too, because we would fail but fail fast without too much investment made by the client.
And afterwards, even now, I often wonder if I have selected the right sprint problem. I’ve thought about how, over time, I have iterated the sprint process I use. I’ve done this to make it suit my style of designing and facilitating. And now…aha…I have developed a ‘problem checklist’.
“Not another checklist!” I hear you say? Unfortunately yes (sort of). But it’s really just a couple of questions you may find useful. I use it to figure out what problems I should or shouldn’t tackle in a design sprint. And to be honest, I’ve developed this from design sprints that have both failed and succeeded based on the problem.
My journey to discover how to pick a design sprint problem
At first, I was too ambitious about my topics. I was trying to achieve too much and solve too wide a scope. This meant I was unable to lead the team to achieve an outcome in five days. The solutions were too broad. The team and I struggled to address the real issue: something achievable. Now I’ve learnt to strive to achieve one solid idea, rather than a bunch of ideas that may or may not mesh together to solve the broad issue as a whole.
Other times I have narrowed the problem too much, and the solutions have been too specific. The design developed in the sprint didn’t actually address the problem. It may have addressed the problem we thought we wanted to solve, but not what we needed to solve.
Thinking about my tried and tested approaches, I have realized that I ask three main questions. These questions generally help me assure that the sprint will:
- address the right problem
- be successful in gaining the necessary people and resources, and
- recommend something that the client actually wants to follow through on.
Question 1: Do the users currently feel pain?
This question can help you piece together the needs of users. It can help you understand the landscape within which the problem exists. It can also help you understand who is negatively affected by the problem, and how. It can help you determine if it is the right problem. Or if there is an underlying problem that is actually the cause of their pain.
For example, a client may engage you to solve a problem they have identified. They tell you the problem is that they are not selling enough of their product to make profit goals. You can ask your client about their users (consumers in this case). You can ask why they think consumers would care about business KPIs. Your client may admit that consumers don’t care about the business’s profit margins. But they might care about not having the product they can use, or not knowing about the product in the first place. These are behaviors that you can address through a design process. These are user needs that you can design for, to improve the internal business profit needs. The nature of pre-sprint planning allows time to be taken to quantify the pain that is being experienced by people. You can gather together data that you can get your hands on. Customer service logs, complaint records, or even social media posts allows you to understand the real pain people are experiencing.
By asking these questions, you can start to uncover the real problem at hand. Perhaps their existing customers keep coming back, but they struggle with new customers. Then the real problem is that this user group (new customers) are not purchasing the product they sell. If you had addressed the client’s original problem, you may have designed for the wrong users. Ensuring current consumers repeat their business, when that wasn’t the actual problem.
Question 2: Does the client care enough to solve the actual problem?
It’s important to address the right client problem. But your client, the decision maker, must advocate it as something they want to solve. They need to be open to discovering what the outcome of the sprint may be (without knowing it beforehand). Let’s say your client asks you to lead a design sprint to develop a new app to promote their product for new consumers.
It is your job as a design sprinter to design a solution that solves a problem based on user needs. It’s not your job to develop a particular solution because someone says so. What is the true business problem that the app (a solution) is trying to solve? Many designers may have experienced needing to ‘get to the root of the problem’. But in most design processes, it’s important to articulate the right problem. During a design sprint, you also want to know if your client will action the solution, regardless of whether it is the solution they suggested or not. Or even better, get them involved so they can question their own assumptions!
Question 3: Is this a priority for the organization to solve?
Why would an organization invest in a problem that they don’t think is a priority? We use design sprints to test the hypothesis of a design solution. But a design isn’t any good if the organization doesn’t actually want to do anything about it.
A design sprint requires commitment. A commitment of people, a commitment of time, and a commitment to the process. That includes making the right people available. You need a commitment from the people that know the most about the problem and its landscape. Involvement from the specialists responsible for implementation. Involvement from decision makers that have the ability to make a change. It requires these people to be 100% committed (i.e. no other work) over the full five days. That’s a pretty decent amount of time for an organization to allow people to solve something that’s not a priority. So how can you find out if the organization will commit and invest?
Does this problem align to the organization’s priorities?
Try to find out if the organization you’re working with is as invested as the person who has engaged you. This will help you work together to conduct a successful sprint, and achieve good design.
Take the example of the client who asked you to help improve business from new customers. What if another area of the organization was about to upgrade that product? Would people invest their time in designing a solution focussing on that product? Do you think the organization would invest money to implementing the design solution? I doubt it.
Has your client already attempted to address the problem?
Clients may have already attempted to address the problem they want to sprint. They may have conducted research. They may have prototyped or even implemented a solution that didn’t work. They may have even tried to scope the problem better in preparation of the design sprint you’re there to lead. It’s helpful to find out if your client has already begun tackling the problem. This is a good sign of commitment from the organization that they care enough to action the final idea.
However, if they haven’t tried to address the problem, this does not mean it’s not a priority. It may be an urgent priority that was only recognized in the organization recently. It may need immediate (first time) action, so the organization wants to start with a design sprint.
It could also be a red flag. Not doing any work around the problem may mean they haven’t recognized or acknowledged the problem yet. This may lead to you having a hard time gaining commitment from the people you need — especially if they don’t know enough about, or value, the issue.
Identifying the right problem is imperative to successful design sprints.
Remember, you’ll need to:
- Get to the root of the problem. What stakeholders may say is the problem might be different to the problem your users are having.
- Confirm the people who are involved care enough. This will help you to ensure commitment to the process.
- Find out what will happen to your idea. Confirm your stakeholder’s intent to action an outcome and actually solve the problem.
Using these questions can assist you to identify the right problem and will help you achieve a successful design sprint. So now you probably want to know how to run the design sprint itself? You’ll need to come to my workshop and presentation at UX New Zealand 2017 to find out!
Want to hear more? Come to UX New Zealand!
If you’d like to hear what Lisa has to say about design sprints, plus a bunch of other cool UX-related talks, head along to UX New Zealand 2017 hosted by Optimal Workshop. The conference runs from 11-13 October including a day of fantastic workshops, and you can get your tickets here. Got a burning question you’d like to ask Lisa before the conference? You can tweet her here: @LisaKJansen
