Problem

From our interviews with SFRPD call center staff and analysis of 4900 emails between staff and customers, we discovered that staff spend a lot of time manually drafting and sending follow up emails to customers as part of the picnic permit approval process.

Whenever a customer submits a picnic permit application that requires further approval (e.g. the customer indicates that they want a bouncy house at their event), staff must send an email explaining the policies and requirements for the desired amenity, informing them that the desired amenity is not allowed, or asking them to provide further clarification for their request.

These follow up emails are drafted manually each time by the individual staff member, which is time consuming, tedious, and inconsistent. Knowing that the email responses repeat the same content, we discovered an opportunity to streamline this process.

How Might We

Ideation

We conducted a brainstorming session where we came up with ideas to reduce the manual back and forth between staff and customers. One idea we explored revolved around immediately prompting the customer to send information that will be required by staff, either directly through ActiveNet or through an automated email.

Another idea was about improving the form validation so that customers wouldn't be able to submit if they selected the wrong answers and staff wouldn't have to manually verify the answers.

Eventually we pursued the idea of a browser extension that allows staff to draft follow up emails using templates. We chose this idea because it's something our team could develop within the timeline of the project, it doesn't require new third party vendors, and it doesn't require integrating with ActiveNet.

Testing and Iterations

Through our own iteration and over the course of several rounds of testing, we made a number of notable decisions and considerations while designing our Email Helper. These include but are not limited to the following:

• Adding draft creation with adaptations: Our initial intention was for users to copy their completed template from the extension and paste the content into a draft email they created on their own. Both our mentors and a tester suggested the ability to send the templated email directly from the extension would be helpful. However, further exploration yielded that (1) sending emails from browser extensions is not possible, and (2) though drafts could be created with mailto:, this would not preserve formatting. As a compromise, we’ve provided users with the option to either use the template to create an unformatted draft in their default mail application, or manually copy and paste the completed template with formatting.
• Reusing Inputs: We recognized that making the user recreate certain custom inputs would be inefficient; for example, most templates would include “Park Name” and “Date of Reservation.” The custom input node has been designed to display a list of previous and/or hardcoded input names for the user to select from if desired.
• Optimizing Layout: Our first renditions included clearly separated steps for completing inputs and previewing the completed template. Testers recommended combining these actions into a single window, which is where the final design stands.
  
  
  

  Original design, with field completion (left) and template previewing (right) in separate windows.

  

  Final design, with field completion and template previewing in the same window.

  
  
• Finding a Centralization Alternative: Though an ideal flow for a tool like this would be one in which an administrative user could maintain templates and push updates across an organization, we wanted this solution to be free from the costs of hosting and data storage. Even if we couldn’t centralize data at a single source, there needed to be a reasonably low-effort way for multiple users to share templates. As a result, the design now includes an export function that allows user A to generate a file of their current templates that can then be imported to user B’s instance of the tool.

Problem

Through our conversations with SF park goers and SFRPD staff, we learned that most park goers are not aware of the existence of a reservation system, which causes unintentional rule-breaking and conflict between park goers.

Many areas lack visible signage, rules and booking information aren't easily accessible on-site, and park goers don't always receive guidance in person. This situation leaves park goers feeling confused, frustrated, and unsure of how to engage with park facilities. Meanwhile, staff must spend additional time answering repeated questions or enforcing rules that could have been self-explanatory.

How Might We

Ideation

Through early prototyping and concept testing, we explored several ideas for improving awareness of the reservation system for in-person park goers. One idea was to distribute zines that inform people about how to reserve park facilities. Another idea was adding maps to the parks that support wayfinding and inform park goers about the reservation system. Another idea was putting up signs with QR codes or phone numbers that allow users to make reservations on the spot and be informed about the reservation system.

We found out that although park goers do not have a strong desire to make on-the-spot reservations, they do want to know about the rules for using a facility and whether or not the facility has been reserved. This type of information helps them avoid conflict with other park goers and makes them feel more confident using park facilities.

We decided to move forward with using QR codes and NFCs as a touchpoint for delivering information to park goers because it's technically simple to implement and doesn't add additional signage to the parks.