How a One-Day Design Sprint Helped to Serve Bay Area Foster Families

A look back at what happened when technical creatives volunteered for a single day to prototype new digital product solutions for FosterTheBay.org.

The past several years I have hosted a fall hackathon that engages Christian developers, designers and technologists to volunteer their skills and talents to serve non-profit organizations and social benefit causes.

While the weekend event is always a ton of fun and we come away with great new technology developed, the projects frequently don’t hit that sweet-spot of usefulness for organizations, and therefore is an extremely steep drop-off rate from projects maturing to anything truly functional after the event.

Such amazing talent comes to volunteer, and I have always felt that we could do more to create something more beneficial from these events. So I thought there must be a better way and wondered how we might better maximize our concentrated efforts to be more meaningful partners.

So this year in addition to the hackathon, I gathered a small group of participants into a separate room to run a compacted single-day version of Google’s Design Sprint that I’ve been collaborating with FaithTech and OpenDigerati to discover how we might better serve these partners.

This post outlines the process and what we were able to achieve for Foster the Bay at the end of the sprint.

Google has a ton of great resources for the various types of exercises that might be used in a design sprint that you can see HERE. Essentially, I selected the handful that I felt would be most meaningful for our short time together, then ran them in successive 90 minute focus blocks with 30 minute mental breaks in-between.

1. UNDERSTAND

Coming into the day, most all of us knew very little about foster care and how that system works, so we needed to first understand what drives the organization and the problems they face.

Lightning Talks

Philip Pattison is the Executive Director of Foster the Bay and he spent about 30 minutes presenting “lightning talks” around the following topics:

1. History — Why does this organization exist? How long has it been around and what is the size/scope of the work they do?
2. Personas — An overview summary of each of the types of people that interact with the organization: the children, host family, church/advocate, and the support families.
3. Alternative Solutions — What does the world look like for these people if this organization doesn’t exist?

How Might We

In an effort to encourage active listening throughout the presentations, before we began the talks I gave each participant a stack of sticky notes and taught them how to capture any/all “how might we” ideas that crossed their mind.

This was a great way to allow creative ideas from each member to flow freely without any influence from others in the room. We continued capturing these ideas through the next exercise as well.

2. DEFINE

We needed to dive a bit deeper into the workflow of the Foster the Bay program, so we had Philip outline the “golden path” that each stakeholder follows throughout the entire lifecycle of their engagement.

Success Metrics

Google uses a “HEART” method to help capture the “success metrics” of a project. My experience is with a slightly different (but similar) model where we identify the primary categories of goals using the “GREAT” framework:

• Growth — Increasing awareness and engagement to expand the program.
• Retention — Ensure the people engaged do not churn out.
• Efficiency — Maximizing the effectiveness of the program.
• Analytics — Gaining a better understanding of core operational metrics.
• Training — Teaching others how to better utilize the organization.

Affinity Mapping

After drilling down into this understanding, we went ahead and each shared our ‘how might we’ sticky notes and grouped them together on the whiteboard in an “affinity map” so we could see the the patterns of need that we might want to consider addressing.

Problem Areas Identified

What emerged from this exercise were the following high-level categories of opportunities that we could potentially pursue:

1. Community support
2. Foster family recruitment
3. Support family recruitment
4. Quality matching
5. Legal requirements
6. Program optimization
7. Measurement/stats
8. Resourcing

3. SKETCH

I was very intentional at this point not to suggest any type of specific solution (a mobile app, web form, marketing program, etc.), but instead wanted to allow any and all creative ideas to flow freely.

Crazy 8's

Next we used a rapid prototyping technique called “Crazy 8's” where participants are given 8 minutes to come up with 8 completely different solution proposals. I set an alarm for one-minute intervals so we could better keep track of the time.

It created tension keeping people moving this quickly, but this was a healthy tension that forces you not to obsess over any single prospective solution. I also highly recommended to use a large marker for this exercise, as not to inadvertently apply higher fidelity to this phase than is useful.

Solution Proposals

After the eight minutes, everyone shared their proposals and we again mapped these into related categories. The team collectively identified the following areas for potential solutions:

1. Matchmaking tools between foster and support families
2. Support family training and pre-approval tool
3. Location-based resource mapping app
4. Applications to serve various support needs
5. Data/prediction models for clearer indicators of opportunities/gaps
6. Marketing & growth programs (social media, webinars, etc.)
7. Gamification mechanisms to drive support family engagement
8. Uber/Lyft partnership to provide free rides for foster children

4. DECIDE

We now had lots of ideas out for consideration and it was time to narrow the options down into a single solution we could tackle during a single day.

Success Metric Refresher

Before we jumped into the “dot voting” process, I first had Philip revisit and summarize his organizations success metrics. There were a few themes that were emerging from the brainstorming (like family matching) that Foster the Bay simply doesn’t provide, so we wanted to ensure that we focused our efforts on the highest value solutions.

Dot Voting

Each participant was then given three red dots to place on what they saw as the most impactful solution to tackle, and Philip was given five blue dots as the ultimate decider who has the strongest point of view. Folks could vote for completely separate solutions, or place all of their dots on a single solution that they felt very strongly about.

What emerged as the winner was under solution category #4 from above:

A mobile application to support the relationship between a support family and a foster family.

5. PROTOTYPE

For the next two phases of the process, I actually diverged a bit from Jake Knapp‘s version of the Design Sprint, and instead followed another Xoogler’s process of rapid prototyping I learned from Tom Chi through his “Prototype Thinking” program.

Rapid Iterations

Our time was extremely limited, so we needed to move very quickly to validate our concepts. In this phase the prototyping and the testing/validation workflows were tightly interwoven together, and not actually two separate processes.

I split the group into four teams and gave them 30 minutes to each come up with their best ideas to address our solution. I then had them test the usability of their prototypes with a member from one of the other teams; without being guided through the concept. More on this process below.

From this exchange we found that two teams were working on similar concepts, so they merged together and then spent another 15 minutes to refine the remaining three prototypes.

6. VALIDATE

While we didn’t have usability testing participants pre-arranged to attend, we instead recruited hackathon participants to take 5–10 minutes away from their projects to test our prototypes and provide candid feedback.

This actually worked out great for this project and our focus, since a core conjecture of Foster the Bay is that literally anyone could be a support friend of a foster family.

None of the participants had ever done user testing before, so I created two roles for them to follow and coached them on the process:

Facilitator

The facilitator’s job was to interface with the research participant and guide them in the following way:

1. Tell them WHO they are. (A support friend of a foster family.)
2. Provide CONTEXT. (This is a mobile app you use to connect with each other.)
3. Explain WHERE they are. (Could be anywhere when using the app.)
4. WHAT they are doing. (Trying to bless others, or receive a blessing.)
5. Had them coach participants to speak every thought in their head out loud, and encourage them that there are no wrong answers and this is not a test.
6. I instructed teams to simply listen, and be conscious as not to guide the user through their concept, but instead ask about their own expectations if they were to ever become stuck.

Scribe

A second team member would catalog what happened when meeting with the participants:

1. What were their emotional reactions? What was their facial expressions at various points of going through the application?
2. What specific comments did they make regarding their experience?
3. What was their physical demeanor? Did they become excited? Were they slouching In their chair or leaning in and getting excited?

WRAPPING UP

Taking the learnings from our user testing sessions, we came back to the room to each share about our findings, and worked together to create one master prototype that encompassed our best collective learnings. We then refined the prototype two more times after I brought in additional research volunteers who hadn’t yet seen what we were working on.

I know that it was stressful for the participants to work under such tight time constraints, but we were able to quickly move to a very meaningful prototype that was tested and validated to serve real tangible needs for foster families.

Being a foster family can be extremely difficult, and Foster the Bay has built an amazing support system in place to assist these families. The application prototype we designed allows support families to send various “blessings” (providing meals, baby sitting, etc.) to the family they are caring after, and the system would track and automate alerts to ensure they are being blessed in the best ways possible.

During the hackathon presentation time, we were able to share what the team accomplished using a clickable prototype displayed on the screen. Foster the Bay now has a validated concept that design and engineering volunteers can continue working on in the future, or if they choose they may engage an outside agency to start development on this solution more quickly than they would have otherwise.

It was a lot of work to get to a single validated solution in one day, which would normally take five, but I’m super proud of the group for being flexible to work with the process.

Get Involved

I was excited to hear a number of people indicating interest in helping with this project moving forward. FaithTech is actively working towards building project-based volunteer groups that meet regularly within churches all over the region. This is really exciting to me because while hackathons and design sprints are a lot of fun, it is the efforts done in a community over a longer period of time that can be most impactful.

If you are interested in volunteering within or starting a FaithTech Lab group in your Bay Area church, please send an email to siliconvalley@faithtech.com.

Thanks!

A huge thank you to all who made this past weekend possible:

• All of the amazing volunteers who gave so much of their time!
• FaithTech who continues to be a leader for technical ministries.
• Indigitous and Neal from WestGate Church for coordinating the hackathon across cities all over the globe.
• Sacred Space Coworking in Palo Alto who provided a wonderful location
• Faith Driven Entrepreneur for your super generous financial support.
• Spaghetti Networks for all of your assistance with our on-site IT needs.