The biggest priority for users is to get their issues resolved, so they need to have a better awareness of the status of the issues they report.

Looking at recent reports and making a new report are completely seperate processes, which explains why 71.9% of users don’t check recent reports before creating new reports.

There is no way for community members to solve issues together - if a user sees an existing report that is missing details, their only option is to make a new one.

Discovery Research

Our research was divided into 3 different teams looking at 3 different parts of the app experience. I was assigned to the pre-reporting team, the experience users had before reporting an issue. 

The platform’s “recent reports” feature allowed users to see reports that had been recently created by other residents. The main thing we wanted to look into:

How do users know if an issue has already been reported? Do users check recent reports before making a new one, and why or why not?

The "Recent" reports feature in the current app experience.

To gain insight into the demographics and general usage patterns of the users of GID, we created and sent out a survey. In total, we got responses from 32 users. We also conducted 3 usability tests, and I managed all the participant recruitment. Our goal was to move past our quantitative survey responses and instead observe how users actually interacted with the app. 

With the survey and usability testing results together, we converged on three main takeaways:

At a Glance

Project Context

In January 2020, I had the pleasure of being selected as one of 11 students for Fi @ UCSD, a student-run UX agency that partners with local clients to help them improve the quality of the services they provide. My task would be the work on improving Get It Done (GID), an app run by the City of San Diego’s Performance and Analytics department. I took the initiative to lead all project groups and bring it to completion during the transition to working from home caused by the COVID-19 pandemic.

The GID platform, available as a phone app and desktop website, allows San Diego residents to report issues (such as potholes, graffiti, etc) to the city, which in turn tries to resolve these issues. Users can also view the existing reports that other residents have made.

THE PROBLEM

Business pain point: Our client had reached out to Fi because many users were making reports on the same issues. This led to a high volume of new reports created. Our research showed that the majority of users don't look at existing reports before making a new one.

User pain point: Through our extensive research, we learned that users are unhappy with the lack of transparency on the issues they report. The issue may just sit in the system without any knowledge of when it would be resolved, or why it hasn't been.  

THE Solution

In order to address these pain points simultaneously, our solution was a redesign of the mobile app experience that helped solve issues with duplicate reporting, allowed for more detailed communication between the city and its residents, and addressed other usability issues to create a more efficient and intuitive experience. 

Prompting similar reports

Similar reports made by other users are integrated into the process of making a new report, so that users won't have to make a new report if one was already present.

Filtering & Searching

Users can filter or search through new reports to make it easier to find the reports they cared about. 

Updated progress

Users can stay up-to-date with the reports they make through a new timeline feature.

ImPAct

Because of our changes and the feedback received in user testing, we can assume that our solution:

  • Decreases the volume of duplicate reports made by encouraging users to build of similar reports already made by other users

  • Increases user satisfaction, because there is increased transparency in the progress of the issues they report

  • Makes users more likely to look at recent reports before they make a new report, due to the useful filtering and search features

We presented our solution to the City of San Diego, and they were excited to see how they could use our recommendations to make changes to the current app!

Roles & Responsibilities

UX research (discovery + validation)

Participant recruitment

Wireframing

UI design (iOS)

Leadership

Tools

Pen and paper

Figma 

Zoom (remote usability testing)

Asana

Timeline: 14 weeks

Timeline: 14 weeks

Discovery user research (3 weeks)

Expert review (2 weeks)

Paper prototyping and testing (2 weeks)

Hi-fidelity designing (3 weeks)

Remote usability testing (2 weeks)

Client presentation (2 weeks)

Auditing the platform

I then worked with 2 other consultants to audit the current app, which allowed us to understand how specific design problems had contributed to the use patterns we had discovered in our research.

Below are some of the findings related to the experience of looking at recent reports, with the usability issues we had identified and our suggested solutions. The full report with all the findings can be found here.

Generating Solutions

Converging onto the Problem

We the data from all the sub-teams' research, we had a lot of insights. But what exactly was the core problem we wanted to address? As a whole team, we met back together to try and position ourselves around this problem by looking at the original user flow of the app.

The app's current user flow allows the user to go down two seperate pathways.

It was now easy to see how the segregation of creating a new report from viewing existing reports led to users not looking at existing reports first. We could also see the "dead end" that happens after a user makes a new report but doesn't get any sort of update, which leads to user frustration over not hearing back on reports they created. 

We this bigger-picture understanding, we then discussed a new user flow for the app.

In this optimal high-level user flow, users would now be prompted to see similar reports to the report that they were making, if the system was able to determine that one existed.

The key change that was being explored was creating a way to show similar existing reports to users at the time of making a new report. By integrating these existing reports, we would be able to remove the segregation between “recent reports” and “new reports” as two distinct workflows. We also knew that showing users an update, whether they made their own report or added to a new report, would be key to improving satisfaction with the app.

With that, we converged onto the core problem statement we wanted to address in our redesign:

How might we integrate the process of looking at existing reports with the process of making a new report, as well as improve communication between community members and the city?
Ideation & Concept feedback

Sketches from our Crazy 8's fun.

As we ideated on different solutions, we agreed that it would make sense to bring in existing reports similar to the one a user is reporting, after they enter the address and category of their report. This way, if an already existing report with the same category and nearby address was detected, the user would be prompted to see that report and nudged to see if it was what they intended on reporting.

 

I then reached out to and conducted user testing on a paper prototype with 2 users. This allowed us to quickly test the new flow to see if it made sense. Both users liked showing similar exciting reports as they were making a new report, so that they wouldn’t have to make their own entire report.

A picture of myself conducting user testing on our paper prototypes.

Proto-typing & Testing

Our design decisions focused on what stages of the new reporting journey do users go through before they are prompted with similar reports.

I managed the different teams as we all worked on designing different parts of the experience. Once we had created our initial prototype, I scheduled and led 4 remote usability testing sessions, which helped us validate our designs and iterate further. 

Consultant Irene and I conducting a remote usability test with one of our participants.

Below are brief explanations for the core aspects of the experience we tried to redesign, as well as some of the design decisions we made after user testing.

Creating a new report

Crafting a new flow for prompting similar reports

In the original "new reports" experience, the user selects a category for their issue, and then enters details to submit their report. There is no prompting of any similar reports that are already made. Our redesign efforts focused on prompting the user with similar reports in the new report creation process

Iterations: When to Show Similar Reports

Our design decisions focused on what part of the new reporting journey does the user go through before we prompt them with similar reports.

In user testing, we learned that users' first response when making a report is to upload a photo, and that the address is often pre-filled using their current location. We should have users upload the photo first then, and only need to change the address in case it is incorrect or not already filled in.

Viewing existing reports

In the original "recent" reports experience, all of the recently-made reports are just clumped together without any way to find particular kinds of issues. Although we were incorporating similar reports into the new reporting feature, the client still wanted us to allow users to search through all recent reports. We added a filter and searching system to give users more control over how they see the issues. 

Iterations: Information Hierarchy & Layout of Filters

Our design decisions focused on how to design the filters in accordance with what users care about the most when scanning through reports.

In user testing, we learned that most users' eyes were drawn to filtering by status due to the large radio buttons. However, users cared most about filtering by the type of issue, so we decided to use dropdowns for both of them. Now the issue category filter has more prominence than the status one.

Keeping track of reports

Adding a Timeline of Report Progress

In the original my reports experience, there is often no communication between users and the city after the user uploads a report. Our solution was a timeline that would keep users up-to-date with the progress of their report.

Iterations: Integration of Two Types of Reports

In the original my reports experience, there is often no communication between users and the city after the user uploads a report. Our solution was a timeline that would keep users up-to-date with the progress of their report.

In user testing, we learned that users missed the toggle bar button when asked to switch between the two categories, so we opted to use a tab menu instead. They also didn't understand what "Shared Reports" were, so we changed the label to "Also Encountered" to reflect the language used in the new reporting process.

Adding a Searching and Filtering System

Style Guide

One of the constraints we had to work under was that we had to stay consistent with the existing branding of the current app. Even within the existing branding, however, we had noticed some examples of inconsistencies in how certain fonts or colors were used, so we knew we had to optimize this in our redesign

After taking a design systems course on LinkedIn, I helped create and organize all the different components as swappable instances. I also took the initiative to understand the iOS Human-Interface Guidelines to make sure we were sticking with best practices for iOS app design, such as when to use modality.

The final version of the style guide used in our redesign.

Final DesignS

Prompting Similar Reports

The address and category of a new report are used to match it with any potentially similar existing reports.

Adding Details to Existing Reports

Users will be able to work together with other residents and add additional details to a report for an issue they have also encountered. 

Filtering & Searching

Users can search or filter by certain categories of reports, status, or address. A date feature allows them to look at reports within a certain time period that they are interested in.

Integrating Reports within my Reports

Users can find the reports they made as well as the ones they added on to. A timeline allows them to stay on track with both kinds of reports.

Updating Reports

Users can add updates to their own reports in case anything about their issue has changed.

The Deeper Dive

Impact

We presented our solution to key stakeholders from the city in a Zoom meeting, and they liked that a lot of ur ideas helped solve the issues they had approached us with.

They stated that they could use our timeline idea as a framework for integrating a more step-by-step method of communication with residents. They also thought the report matchmaking solution was an innovative way of addressing the duplicate reporting problem.

Based on our initial positive user and client feedback, we could expect the following metrics of success if our solution was implemented:

 

  • Reduced number of duplicate reports made on the same issue, since users are more likely to build onto a similar report

  • Increased use of the recent reports feature, since the added filtering and searching abilities now make it much easier to use

  • Greater user satisfaction due to increased transparency on the reports they make, which in turn creates more trust in app and leads to continued usage

Some screenshots from the final presentation. Check it out here.

Reflection

Overall, I really enjoyed working on this project as a UX consultant. Working with a client poses a new set of limitations that must be considered, and has much greater implications than just doing an unsolicited redesign. In addition, the challenges with COVID were immense, and it required hours on my part to rally everyone together, allocate tasks, and wear all the hats to get this project into the hands of our client.

If I were to do this project again...

If I were to do this project again, I would talk to the client earlier to better understand constraints upfront, and speak with them more often throughout the process. For a lot of this project, it felt like we were doing “blue-sky designing”. Apart from keeping all the main features of the app and working within the existing style guide, we were essentially given the ability to explore and propose any feature we wanted.

 

Although the client did like all our feature proposals and we did discuss how they could be implemented, we can only expect them to prioritize the ones they think have the most potential. It would have been better to discuss our feature ideas with the City before we fully committed to designing them, so that we could understand what these priorities were and any additional constraints that we needed to work within.

2020 Anmol Arora - "Can't wait for it to be 2021"

  • linkedin-icon_red
  • email-icon_red