An app the foster parent system really needs: What an agile rapid prototyping exercise taught us

A Product Owner, engineer, and volunteer foster parent share their learnings.

Background

– Robert, Product Owner

In June of 2015, Chris Cairns and other leaders of 18F within the GSA created a seminal Request For Queries (RFQ) in order to qualify some cutting-edge firms to do Agile work for the Federal government. Unlike most previous bidding processes, it demanded that firms prove their readiness by actually coding a working prototype in a short period of time (about three weeks.) It demanded user research, modern design thinking, and — above all else — openness and Agile methodology.

The State of California copied that approach in 2016 when it released Solicitation RFI-75001, entitled “Agile Development Pre-Qualified (ADPQ) Vendor Pool”. The California Health and Human Services Agency made slight improvements to the original challenge, but basically demanded that firms such as ours prove their mettle by quickly building a functional prototype. They provided some rules and specifications, but their most important requirement was that we listen to real users, which is the heart of user-centered design.

We did. And we learned. A lot.

One of the beautiful things about this approach — and the government’s insistence that everything be publicly licensed, visible and documented — is that the State, or anyone else, can share in our discoveries to make improvements to the foster system that cares for our distressed children. This article is about what we learned.

The Learning Process

– Heather, Engineer/UX Developer

From Day One, we realized that the success or failure of our project would be determined by our ability to understand our audience and their needs. Since we had previously done some work for the stellar organization FosterClub, we immediately reached out to them and asked if they could get us in touch with some foster parents and/or case workers who would be willing to work with us. Their response was overwhelming! We had more foster parents eager to participate than we could accommodate; we even offered to donate some of our volunteers to competing firms.

After settling on a small group of participants, we dove into user interviews and quickly found that — as often happens — what mattered most to users didn’t completely align with the RFP’s requirements. A decent portion of the RFP called for an API integration so that residential facilities such as drop off locations and respite centers (places where foster parents can drop their children off in case they are ill, or just need a break) would be easily accessible. However, what really mattered most to everyone we talked to was the facilitation of better communication between foster parents and caseworkers and the arrangement of visitation.

Once we talked to a variety of parents and caseworkers, we started developing user personas and empathy maps that would give us further insight into their needs, frame of mind, and the conditions under which they’d be using the system. The user research activities were a valuable tool to guide the creation of user stories, which are statements that represent desired functionality to be built. We then assembled all of these stories into a user story map, which provided a high level overview of what we would build in order to satisfy the Minimum Viable Product (the leanest collection of features we could build to satisfy both user needs and the RFP requirements). That user story map eventually turned into our backlog, or the “tickets” we used to track progress towards the final product.

Our primary focus throughout our process — from our collaborative sketching to wireframing and prototyping — was how to ensure that both parents and caseworkers could have a definitive, central location to coordinate communication and that we could allow parents to prioritize urgent messaging. By focusing on this particular functionality, we hoped to solve the biggest pain point of parents, which one of our foster parents, Amy, will detail below.

The Takeaway

– Amy, Foster Parent

Being a foster parent has its positives and its negatives. Positives like loving on sweet, innocent, newborn babies and the feeling that you are doing something for the greater good. But, like any journey we go through, there are negatives, some of which can be quite heavy. Most can be fixed.

Having the support of the county social worker is how anything gets done officially. Here’s the kicker: county social workers can have anywhere from 30 to 50 cases they have to support. Their responsibilities include keeping in contact with the foster family, the foster child, the biological parents, the service providers for the child, the service providers for the bio-parents, and their own superiors — as well as going to court when changes to the case are needed. Every contact with every detail of every action needs to be documented.

A county social worker is busy — plain and simple. When people are as busy as this, something has to give. Often what gives is foster parents such as myself. We seem to be the last person on the list of calls to return in non-emergency situations. Sometimes those non-emergency situations are a big deal to us and we need our questions and concerns answered in order to do the best job we can for these children. Also, simply receiving a response to a call or an email makes us parents feel appreciated. It makes us feel heard. It really goes a long way. On the other hand, how can social workers return hundreds of emails and phone calls a day while doing all the other work expected of them?

Learning that a contact system was in the works that would be confidential, easy to use, and reliable — one that covers all the things we need from our workers on a daily basis — made my heart go pitter-patter. The idea of sending a message and getting an answer back the same day seemed too good to be true. I was definitely on board to help in any way I could to make this a reality. Foster parents long to be to be heard without feeling like we hindering the process by taking up precious resource time from the worker. In the end, an app that saves time for social workers will help foster parents and ultimately the kids. Being a part of this process was immeasurable. I hope it helps to set a new standard for how the child welfare system and those caring for the child can work together.

Conclusion

This valuable two-week exercise helped us understand what parents and caseworkers need. As is (thankfully) required by the State, all of our research and our prototype is documented. In the interest of guiding any future efforts, whether by government contractors, a for-profit firm, or coders working in the public interest, we summarize our learnings here:

• Foster parents, biological parents, and caseworkers need a dedicated app that streamlines communication about a particular child.
• The fact that some communication is urgent must be supported by the app.
• Medical issues and visitation represent special situations that should be supported by the app.
• Arranging safe visitation appointments is a major problem that is not directly mentioned in the Solicitation, but is hinted at. A modern map-based approach to negotiating visitation could be helpful.
• Since biological parents often don’t have cars, a map that showed public transportation facilities could be helpful. Even if only the foster parent has a mobile device to use it, they could communicate the information to the biological parent via voice over telephone.
• A means for court-ordered changes in visitation rights to be communicated to all parties should be developed to cut down on time wasted by caseworkers answering questions about this.