Twenty-nine interviews. 48 pages of notes. Hundreds of hours. Our Harvard student team working with the City of Boston spent the past two months talking to City staff, activists, journalists, and other Bostonians to understand their experiences finding information from the City.
How did all of this research lead us to playing mad-libs on a Saturday evening?
Our team assembled this past weekend to turn the stories we’ve been collecting into problems that we can solve. Playing problem statement mad-libs helped us fill in the blanks and put the core challenges of requesting public information into words. Here’s one example of a problem statement we came up with:
“A custodian [City staff] feels their time is disrupted by clarifying new requests, and needs a clear idea of what to look for, but faces a broadly-worded ask.”
After writing a handful of these problem statements for the various types of people who look for public information, we grouped the statements together into four key challenges:
- Routing: Who could best fulfill this request and how do we make sure it gets to them?
- Scoping: How can requests be more specific so that City staff can effectively fulfill them and requesters get what they need?
- Timing: How can the City set and provide a clear timeline for the progress of responding?
- Accountability and Trust: How can we help requesters trust the process, maintain open lines of communication, and recognize when requests are fulfilled well?
By synthesizing the research we’ve done into these four areas, we were ready to move into the next phase—generating solutions through prototyping.
Finding the Puzzle Pieces
Prototyping is a process of quickly developing ideas and trying them out. The goal is to go through many alternatives—both good and bad—find a few that might work, and then build them out further.
This was not a time to get too attached to any single idea.
Initially, we fell into this trap, thinking that the challenges we identified seemed to suggest only one obvious solution: a tracking system that would help everyone keep tabs on the status of requests. It would address the issues with accountability, offer updates to requesters, and ensure that anyone in the public could benefit from another person’s request. However, as we generated prototypes and researched commercial tracking systems, we discovered that this one solution appeared to be filled.
Rather than attempt to recreate what already existed, the team decided that we could offer value to the City of Boston by building upon and filling in the gaps of commercial products and translating our prototypes to support the City’s procurement process. We developed these tools to gain insights to better allow us to inform the City’s request for proposals and make recommendations about the short, middle, and long-term trajectory of the public records process.
As a team, we generated ten prototypes, and settled on four we want to test—including the idea below, that we called “Tippy.”
Overly-broad public record requests can be disruptive to City officials, and often result in long wait times for requesters. Sometimes a broad request requires a lot of back-and-forth between requesters and City staff, to figure out what the requester needs. Other times, because the requester isn’t able see what the city actually has, they can’t be more specific, and the request takes a long time to fulfill.
Enter Tippy, our version of a smart suggestion tool that helps people narrow down their public record requests with more specificity. As a person types their request, helpful tips appear based on key “trigger” words. For example, when someone types “email,” tips pop up to remind the requester to add a date range or an email address they’re interested in. That way, requesters will be more likely to get what they need while city staff can more easily find the records in question
Alternatively, when a word such as “aggregated” is written in the request box, tips that pertain to machine-readable datasets could appear to guide the individual towards a clearer request.
To help users find the right department for the request, the dropdown menu could make smart suggestions based on the types of words entered in the box. This helps requesters avoid having to look through a list of more than seventy departments to find the one best suited for their inquiry.
As we prepare to test our prototype with the public, we are asking ourselves the following:
- When a user interacts with this prototype, do they make requests clearer and easier to route to the right city official?
- Should we show tips before a user starts typing? If so, which ones?
- Which words should trigger which tips?
Although we have shifted in our process from collecting user stories to designing and testing prototypes, we maintain our focus on the primary challenge--keeping the experiences of the public at the heart and center of our design work.
While we generated many ideas, many of them ultimately ended up on the cutting room floor. Here are some examples of additional prototype ideas we had:
- Shawnbot 3000, the Artificially Intelligent public records custodian
- Simple CC tracker allows you to CC a specific email to track requests in a central location
- Email Review Time Estimator can magically tell requesters how long it will take to review
- Department Suggestor takes the keywords of your request and spits out recommendations of who might have the information
- City Data Organizational Chart that’s engaging and easy to navigate
- 10 Days Later automatically releases unflagged documents 10 days after their creation
- Collaborative Forum (think StackOverflow) for public records that could build a community around requesting and analyzing information from the city
- Domino's Pizza Tracker for the public records delivery process
- Data Map for City information instead of City streets that tells you which department has what information
Jackie Chea, Thad Kerosky, Jim Moffet, Erica Pincus, Jon Truong