Learn how the Pivotal Atlanta office approached a design sprint, and how they helped a client rethink her user’s needs.
Jasmine Crowe had worked in the social impact space for 5 years before she decided to create Goodr. “In 2013, I created an event called Sunday Soul where I host top restaurants for members in our homeless community in Atlanta,” she said. At the event, people would dine in a restaurant setting complete with tables, chairs, linens, flowers, and menus. “I wanted to give them a restaurant experience to restore dignity.”
When one of the event’s videos went viral, Jasmine noticed a recurring question in the comments section. “People were asking which restaurants were donating the food, and the answer was none,” she said. “I started thinking about all the times I’d spent grocery shopping, couponing, and, of course, cooking for these populations, and how much easier my life would’ve been if restaurants were donating their food.”
After doing some research, Jasmine discovered that restaurants that donated their food enjoyed a special tax benefit. That’s when she had the idea to create Goodr, a food app that connects donors with surplus food to nonprofits, soup kitchens, shelters, and individuals who are food insecure. As of today, Jasmine has managed to sign up donors like Turner Broadcasting Systems, Red Lobster, and Chipotle.
Currently, Jasmine communicates with donors via phone or email. However, she wants to take Goodr to the next level by creating a better experience for both donors and drivers by developing an app. “Technology is going to allow us to do this on a greater scale.”
Working with Pivotal Atlanta
Jasmine came to Pivotal Atlanta (which just opened its doors a few months ago) through Product Office Hours. Initially, her goal was to figure out how to provide a better experience for drivers, who she believes represent the nucleus of her business. After spending an hour with Jasmine and helping her with some prioritization work, Product Manager Kate Griggs thought Jasmine would benefit from working with us more closely. So Kate enlisted designers Amir Hoagland, Leyda Hughes, and Erin Cobb to help run a design sprint with the Goodr team.
Based on the design sprint by Google, this sprint would have a Pivotal spin to it. “We decided to apply Pivotal practices to the sprint to see if we could retrofit it into our playbook,” said Amir. With that in mind, the team approached the design sprint the same way they would a Discovery and Framing session (the activity that kicks off many Pivotal engagements): They started from the beginning.
Monday: Understand the Ecosystem
The goal of the first day of the sprint was to identify all of the stakeholders involved in Goodr’s ecosystem and figure out what their problems were. That means developing personas, finding challenges, and identifying everyone that’s involved in this loop — from donors to drivers, food handlers to recipients. To do this, they drew an ecosystem map that illustrated the relationship between the different stakeholders.
Tuesday: User Interviews
Once personas were identified, it was time to make assumptions about each one and the challenges they faced. These assumptions were then used to craft non-leading questions for user interviews, which was a new step for Jasmine since she had never talked to her users before. To show her how to lead an interview, our team conducted an in-house interview with a Pivot who was tangentially related to what Goodr is about. “We talked to our Director of Happiness since she orders food all the time for us. It was actually a persona that was kind of analogous to a persona that Goodr had.”
After going through that example, Jasmine was ready to lead a user interview with Goodr’s current (and biggest) donor: Turner Broadcasting Systems. “We all went over to Turner and sat with the executive chef who is responsible for all the food that gets donated to us,” she said, “and even though I had been working with him for almost two months, it was like I was meeting him for the first time. That was eye opening for me.”
Wednesday: Synthesize the Results
Now it was time to validate some assumptions by listening to the user interviews. An assumption Jasmine had was that donors were heavy phone users who preferred mobile apps. “I was wrong,” she said. After talking to her users, Jasmine discovered that donors who sit behind a desk still want to be able to complete orders through their computer. “I definitely was just thinking that, in this day and age, everybody is on their phone.”
Goodr also hadn’t considered some important aspects in the food recipient’s experience. “One of the things they realized was that people who receive the food don’t always have the latest smartphone,” said Amir. “After talking to some of the recipients at these places, they found out that many of them used to be homeless, didn’t have a lot of money or get paid well. So their assumption that everybody would use this app on their smartphone was invalidated.”
Thursday: Designing the Prototype
By Thursday, both teams were ready to frame the opportunity, and start to think about possible solutions that fit their personas’ needs. Even though Goodr already had a prototype, they decided to adopt a beginner’s mindset and assume they didn’t have a technology solution yet.
Writing user stories was a challenging task for Jasmine. “I didn’t think I was going to have to do that. To be honest, I thought I would just tell the developers how I want it to look like and what I want it to do, and they would build it,” she said, “but I felt Kate did a good job of walking me through it.”
In the design studio, user stories were written and used to sketch the end-user’s journey through Goodr’s envisioned app. According to Amir, that’s when a light bulb went off for Jasmine. “When she saw how we took previous exercises, like the user interviews and stories, framed them, and started designing a solution around a person doing a specific task with these constraints we had identified, it all started to make sense.”
“When she saw how we took previous exercises, like the user interviews and stories, framed them, and started designing a solution around a person doing a specific task with these constraints we had identified, it all started to make sense.”
Friday: User Testing
By Friday afternoon, the team had built a web app prototype for end-users to see and respond to. “We had a prototype in a clickable format, that an internal user — Pivotal’s concierge — was tasked to go through. We went through a script we wrote together as a team, and wrote down all the things she had trouble with. This invalidated some more things, and we put those on a list,” said Amir.
After running one whole cycle of prototypes, Jasmine and Goodr were left with a functioning prototype that was ready to be tested with their users. “They showed me how to download Adobe XD on my phone. So now I have the prototype on my phone and I’m actually able to test it with my users right now.”
Conclusion/Takeaways
Aside from her newfound respect for sticky notes, Jasmine learned some important practices from this sprint. Specifically, she now understands the value of talking to users, “By the end of the week, she was saying things like, ‘That’s an assumption.’ So, she realized that she was making all sorts of assumptions that she never thought to validate,” said Hughes.
Would Jasmine recommend a design sprint to others in the social impact space? “Absolutely,” she says, “I think people that are in the social impact space like myself think very differently: we’re constantly thinking about finding ways to serve people. But at Pivotal, you’re looking at ways to solve the user’s problem.”
At Pivotal, we believe design sprints are a good way for startups to de-risk their solutions and ensure they’re building something that people actually want to use. As Amir put it: “A lot of times, startups are trying to — as they always say — ‘Boil the ocean.’ Going through this exercise really helps them focus.”
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
A Design Sprint for Good(r) was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
