Lessons from my First Design Sprint
I sat there in silence, not knowing what to say. 😶
My friend was telling me about the everyday challenges of a cancer diagnosis. I was shocked by all the stories that don’t make it to the news. Simply getting from the parking lot to the hospital could now be a hurdle.
For the last month, I’ve been researching the non-medical challenges that cancer patients face. It’s an eye-opening experience in itself. 😤 But I was extra lucky. At the same time, I got to practice my first design sprint — a process for designers to understand the people they help.
That’s why I’m writing to explain the design sprint process + the real-life lessons I learned from it.
1. Wait, What’s a Design Sprint?
- UX (User Experience) Design: the process of meeting people’s needs/wants by better understanding them.
- Users: the people you’re trying to understand. 🔎👨
- User Persona: A hypothetical person that represents your users. You decide your persona’s demographics, goals, preferences, challenges, etc.
Design Sprint: a ‘5-step guide’ to meeting your users’ needs/wants.
- Empathise: we try to understand people’s needs, constraints, attempted solutions, etc. with interviews, surveys, and more.
- Define: we choose to help a specific group of people with a specific problem (ex: provide childcare during cancer treatments for mothers)
- Ideate: we find LOTS of ideas to solve the chosen problem.
- Prototype: we choose one of the ideas we found to make a ‘first draft’ of.
- Test: we show the ‘first draft’ to the people we’re trying to help. Get feedback on upsides/downsides. And improve the solution. 💪
2. How Did You Learn About Cancer Patients?
I’d never known a cancer patient before, so I started from scratch. I luckily found plenty of online interviews, a cancer survivor, and two caregivers who kindly shared their experiences with me 🙏
While interviewing patients, I asked lots of open-ended followup questions: “How did you approach that problem? What did you try next? Could you give me an example? What were your priorities at the time?” Etc.
- Also, I started with easier questions to make the other person feel comfortable. Ex: “Could you tell me when you were diagnosed?”
Alongside my own interviews, interviews I found online were very helpful!
- First, it was hard to find enough people to interview. Even after I had an extra week to contact people, I only 2 interviews in 2 weeks.
- Also, I only knew nonprofits/survivors in developed countries. But online, I found an interview of a cancer patient in Nigeria. Her stories of cultural taboos and financial barriers were shocking. 😮 But since 85% of the world lives in low and middle income countries — they’re all too ignored.
- Ie. Online interviews helped me understand the needs of a more diverse group of patients.
- Still, there was one issue: a lot of online interviews were blogs/written articles. Written transcripts of interviews just don’t express the same level of emotion as video/audio notes. 😕
- You can still identify user problems, but it’s hard to prioritise their most important problem. See for yourself (written interview, video interview)
One last tip that really helped was to review the benefits/limitations of existing solutions. This is called a ‘competitive audit’
The competitive audit made sure I didn’t recreate what’s already been done. More on this at the end.
3. Which Problems Did You Find?
With all that research, I was able to make a user persona for my target group: mothers that had been newly diagnosed with cancer.
This was an INSANELY useful document for the rest of the process! Whenever deciding between multiple options, I went back to the user persona. Ex: Which solution best meets her needs? Which needs are her first priority? Etc.
The big issue, though, came with choosing ONE problem to work on specifically. Is it more important to meet mental health needs for my chosen user persona or offer them childcare support? It’s a hard question. 😕
What I realised was that I didn’t have enough secondary research to prioritise different problems. User research identified a list of problems. But I needed secondary research like root cause analysis to filter through them.
In the end, I started the ideate stage with three clusters of problems: finding resources after diagnosis, finding childcare during cancer treatments, and finding mental health/emotional supports.
4. Which Solutions Did You Think Of?
So now, the fun part! 🎉 Finding solutions to help the mothers with cancer!
While ideating, I didn’t want to be stuck with my own perspective. So I invited my friend, Sasha, to brainstorm solutions with me.
Sasha lives in a non-Western country, so I thought she might see the problem differently than me. That turned out correct!
Ex: In Sasha’s home country, volunteers gave most cancer support. Whereas, I assumed that formal hospitals were most helpful. So team-mates of different backgrounds challenged my assumptions about what’s possible. 🙏
Still, because Sasha hadn’t taken part in the previous steps with me, it took us more work to get on the same page.
- Specifically, it helped to explain the main needs of our user persona + the main limitations of existing solutions in our own words. Then we tried to say back to the other person what they said to us.
- Still, I think I should‘ve reminded Sasha to focus on quantity of ideas over quality. I noticed she was often filtering ideas before writing them down. But this is for later in the process, not now!
- I could even start by intentionally asking my team-mates to come up with stupid ideas. 😁
When we started brainstorming, we used how-might-statements. Ie. we asked: “How might we…?” and brainstormed solutions to that. In our case:
“How might we make the support of occupational therapists and/or social workers more scalable, more widespread, and easier to get?”
Our how might we statement was too broad, making it hard to focus on one kind of solution. This is where the challenges in defining one specific problem (from the previous step) got in the way again. With just the how-might-we statement in general, we had no idea where to start! 😭
What helped was brainstorming with constraints. Ex: “What if the solution had to be ready tomorrow? What if it had to cost less than $1/person? What if it had to reach 100,000 people?”
In the end, we had brainstormed all these ideas:
And then, we clustered them into categories based on the type of solution. And filtered ideas by asking: “What’s neglected? What has high impact? What’s feasible? What are we uniquely able to work on?”
This was a great set of filtering questions to ensure that we removed work that would just repeat the old or wouldn’t solve the problem!
5. Which ‘Rough Drafts’ Did You Make?
Now that I had 3 types of solution to pursue, which one to go deeper into? As before, I needed more secondary research to prioritise! This is an example of how issues in earlier parts of the process cause problems down the line.
Still, one thing that helped was to have analysed existing solutions. I noticed that I already had a perfect example of one type of solution — making it easy to get information about cancer for newly diagnosed mothers.
- Specifically, the solution I found was the Cancer Support Community website. It had calming design, great branding, personalised resources, credible information, and lots of ‘kinds’ of support! 🙌
But the problem is that it isn’t accessible in developing countries. Ex: For someone with limited mobile data and no Internet.
- It’s also hard to find. There’s so many cancer nonprofits who publish information on the web, the poor-quality resources drown out the high-quality ones. 😕
Still, I didn’t want to reinvent the wheel. So I realised that I could better help cancer patients by working WITH Cancer Support Community instead of designing a new solution.
- The key would be to make their existing content accessible via SMS or Whatsapp. Because only 35% of the developing world has access to the Internet, but 85% have access to low-bandwidth mobile.
- So far, I’ve created some quick ‘mockups’ of how a solution could look.
Now, I’m going to get in touch with Cancer Support Community to try to make this happen 😊
6. Key Lessons
So that’s the overview of my process! I’m grateful to have explored such a ‘human’/vulnerable problem while also learning about design sprints.
Next, I’m excited to get these ideas in front of the Cancer Support Community so they can make their resources even more accessible!
And finally, here’s a summary of what I learned in this journey 💪
What Went Well
- Looked for people to interview early
- Found existing interviews online to get more diverse perspectives
- Did a competitor analysis to understand what’s been tried
- Made a user persona to refer to several times
- Had team-mates ‘say back’ their understanding of the user persona’s problems and existing solutions’ limitations before brainstorming
- Used constraints to make the problem more approachable 😤
- Got diverse team-mates to challenge assumptions on how to solve the problem.
- Filtered ideas by what’s neglected, feasible, and impactful.
What to do Differently
- Don’t save learnings from interviews in just written transcripts. Too little emotion.
- Do secondary research to prioritise one user group, the user group’s problems (and thus, which solutions to work on)
- Remind team-mates to aim for quantity > quality when brainstorming. Or even ask them to come up with stupid ideas. 😅
If you have any questions about my work, I did my best to link everything publicly above! Feel free to get in touch with any questions here 😊
