Discovery Sprints Do Work (Even in Government)

There are certain realities that come with living in a city. Issues like graffiti, potholes, illegal dumping, and broken street lights can all be commonplace. For many years, the process of requesting city services to address these problems could feel like screaming into the void. But today, there are cities that are working to bring these reporting processes into the digital age.

We are Code for America Community Fellows working within San Jose’s Office of Civic Innovation . We are part of the budding product team for the My San Jose app, a web and mobile app that enables residents to conveniently report issues throughout the city. We are working to ensure that the service is equitable and inclusive in its implementation to low-income and non-English speaking residents. Working with this population is personal: as daughters of immigrants, we each have parents or grandparents who couldn’t speak English when they migrated to the US and Canada. We know what linguistic isolation can feel like. So we hope to better understand what barriers non-English speaking residents in San Jose encounter when accessing government services online. We work closely with the core team, which includes government staff like Michelle Thong, service innovation lead and product owner, and Charles Amith, product manager.

The “My San Jose” app flyer distributed to the public
 

We also joined at an exciting time, as the team is exploring new ways to improve the app by engaging City staff and residents. To help think through this critical discovery phase of the project, our team collaborated with Ad Hoc , a digital service agency specializing in U.S. government, to orchestrate a discovery sprint . It focused on improving one user flow for the My San Jose app. As UX researchers working within local government, we picked up a few lessons of what works (and what doesn’t) during sprints in general, as well as for our project.

You can recruit 20 users in 1 week with no budget

Amazingly, we were able to recruit 20 users (with only 1 no-show) within a week of the discovery sprint. We didn’t have any incentives like gift cards to offer; instead, we focused on finding users who were already invested in the product and likely more keen to help out. So we reached out to our highly-engaged “super users.”

We also sent mass emails to about 150 registered users who had recently reported illegal dumping, and even reached out to our own network of users who were part of our Fellowship research. Relying on our own established relationships with many of these users likely helped decrease the ‘no-show’ rate (and friendly follow-up emails, with Google Calendar invites probably didn’t hurt).

Focus on the sum (not just the parts)

We spent most of our fellowship identifying the pain points of our target user — low-income residents of San Jose with limited proficiency in English — but Day 1 of the discovery sprint honed in on the internal experience of City staff. It was our entry into the complex My San Jose app ecosystem — My San Jose was clearly much more than an app. We realized that we now needed to consider the needs and pain points of another set of users on the backend: City staff.

All the staff members involved with running the My San Jose app. We might even be missing a few people!
 

It was powerful to hear firsthand the operational challenges staff faced while having to handle an unprecedented volume of requests from residents. My San Jose made filing reports easier and more convenient for many residents but how was it affecting the behind-the-scenes operations? Staff was clearly struggling.

Your ideas aren’t precious

Rapid prototyping sessions are where ideas spring up and die within hours. In one instance, one interviewee (a “super-user” of My San Jose) suggested we offer an image-based form that would help the city distinguish a homeless encampment from ordinary illegal dumping. All of us in the room (internal operations staff, developers, designers) agreed this was an idea worth exploring. But after we built it, users reacted poorly so we quickly abandoned the idea — all in a span of a few hours.

Works in progress: Version 1, text-based question (left), Version 2, image-based question (right).
 

Be proactive

As Fellows, we offered our own areas of speciality — specifically in UX research, UX design, content strategy and unique insight into San Jose’s underserved communities. It was fun being able to contribute even if the idea fell flat.

 

Keep the momentum going

The next chapter of our work will likely focus on finding the “sweet spot,” or striking the right balance between the resident’s needs and the staff needs. The sprint gave us a lot of ideas on what to prototype next. We prioritized based on how well it addressed the pain points of the user and staff, while also leveraging the work we already started during the sprint. Some ideas we plan to explore further:

Reporting homelessness user flow. Often, residents use the app to report concerns that are linked to a much more complex issue — homelessness. It’s a problem that won’t be solved by an app alone. The city has a homeless outreach program staffed with folks who are trained to provide support and services. We plan to continue to explore how better messaging can provide more transparency around the issue.

Defining what “closed” means for the user. During our Day 2 interviews, users shared that they feel like they’re left hanging, or as one registered user described: “I get an email saying my request is closed, and there is no context. It just doesn’t feel personal.” So we plan on prototyping ways to weave in friendlier, plain language copy to create a warmer experience.

 

The discovery sprint is just the beginning. We’re now focusing on concepts that are scalable, so potentially successful learnings can be applied across the app. We’re excited to move to the next phase of prototyping workshops and subsequent usability tests. and we look forward to sharing our learnings in future posts. And since there is strong interest in understanding the translation needs of the app, we’re exploring different ways to engage residents with low-proficiency in English. What provides a better experience for these residents: a direct translation of the existing app in their primary language or a simplified English version of the app? We’ll build on what we learn from our users, iterate, and test again — in true agile fashion. We’re hoping the outcomes of our user-driven approach will help influence the multilingual strategy of My San Jose and other City services.

Related stories