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)

Project Context

OVERVIEW

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, an app run by the City of San Diego’s Performance and Analytics department that allows city residents to report issues in their communities. 

The project was divided into 3 main stages: user research, solution research, and design + client presentation. But because of the onset of COVID-19 and abrupt shift to working from home, the project completely stalemated during the designing phase (the last 5 weeks of the project). This is when I took the initiative to lead all project groups and bring the project to completion.

THE PROBLEM

The Get It Done (GID) platform is a phone app and desktop website that allows San Diego residents to create reports on issues (such as potholes, graffiti, etc) to the city, which in turn tries to resolve these issues. The city had noticed that many residents tend to make reports on the same issues, and had received complaints from users over not hearing back about the issues that they had reported. They had reached out to Fi to do a deeper dive into the app to discover the extent of these problems.

THE Solution

Our solution was a complete redesign of the 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. 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.

Designing for Community-Based Reporting

Timeline

Discovery Research

Our research was divided into 3 different teams looking at 3 different parts of the app experience: pre-reporting (the experience before reporting an issue), reporting, and tracking (the experience after a report has been submitted). I was assigned to the pre-reporting team, and since I had the most experience on my team in creating research studies and plans in past projects, I guided the team as to what research methodologies to use and why.  

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:

Problem

A lack of clear information hierarchy in the information shown on a report page makes it seem cluttered and prevents users from being able to efficiently scan through details.

Suggested Solution

Typography improvements to reduce the amount of time it takes users to understand the specific details, thus creating more scannable content. This is essential so that users can quickly see an existing report and determine whether or not their issue had already been reported.

An example of an illegal dumping report.

Problem

A lack of user control prevents users from being able to search or filter through reports to see the categories of reports they care about (ex. potholes). 

Suggested Solution

A filter or search bar that allows users to filter all reports by the categories that users already use when making a new report (which creates a consistent mental model). A search bar can also be valuable by giving users flexibility in terms of how they view existing reports.

While the app doesn't have a filter, the "view reports" feature on the website allows users to select specific categories of issues

The “Recent” reports feature wasn’t designed in a way that would allow users to see already-made reports efficiently or intuitively, and this played a role in why users didn’t use it before making a report.

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

Recent reports are completely segregated from the process of making a new report. They simply don’t fit into the user’s workflow of making a report on an issue once they see it. This would explain 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 through Get It Done. Users cannot build off an existing report, but rather must make a new report altogether.

DEsign Proposals

After 3 weeks of designing, followed by 2 weeks of user testing, we came up with the following design proposals for the different core functionalities of the GID experience. I managed the different teams as we all worked on designing different parts of the experience, and helped our primary visual designer Katie in creating the design system. 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.

We kept the existing visual language in terms of color and font usage (SF Pro Display), but tried ensuring more consistency in how and when the different design elements were used. 

reporting together

One of the most important changes our redesign was introducing was allowing users to see similar reports at the time of making a new report, so that users could be informed of these reports without having to check the Recent reports tab. 

In the current experience, the user selects a category for their issue, and then enters details to submit their report.

Now once the user has entered the address and picture of the issue they are reporting, as well as selected the category, they will be prompted with similar issues (in the case that any exist).

A full modal sheet with an alert was used to direct the user’s attention to determine if the existing report(s) was on the same issue that the user had encountered. We chose to keep both a list and map view, which was consistent with the model the app currently uses in its Recent reports, and allowed users to visualize where their report was made in contrast to the existing report.

If the user can click on one of the report cards, they can see the report in more detail. One of the biggest changes our redesign introduced was the ability for users to work together and add additional details to a report, once they indicated that they had also encountered that issue. This solves the pain point we discovered of users having to make a whole new report if they find one that is missing details or not up-to-date.

The blue label on the right side shows users how many people had indicated that they’ve encountered this issue, and this concept was something that mostly made sense to users in user testing. Once clicking the CTA, the user can add additional details. We added the “OPTIONAL” label in all caps, because in our original iteration most of the participants in testing felt like adding more details was required.

Staying updated with report progress

Improving communication between the City of SD and residents on reports they had created was a key priority for our team. Reports can sit for a long-time without any update or indication of next steps, and may also be closed without any indication. To address these pain points, we proposed using a system of updates and a timeline to help bridge the gap in communication within the “My Reports” tab.

When a user’s report changes status, the user will be notified in the updates section of My Reports. When the user clicks on the report, they will be able to see the city’s timeline for that issue, with the update highlighted in yellow.

The information hierarchy of the report description was also improved by utilizing different font weights and spacing, which resulted in easier scannability of the details.

Details for an illegal dumping report in the current app.

Details for an illegal dumping report in our redesign.

Browsing through existing reports

Even though we wanted to bring in similar existing reports at the time of making a new report, the client still wanted to allow users to see all the past reports in one place. With the findings from the expert review I had conducted, we worked to improve the efficiency of the feature by allowing for more user control in how they could navigate through past reports.

Screenshots of the "recent" reports in the current app, which just clumps all of the recently-made reports together in a list, map, and picture view.

To help users in finding the issues they cared about, we designed a search and filtering system.

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

In the current app, the cards containing report previews were very small and crammed together, which made it harder for users to process the information when scanning through them.  

 

We added a little bit of “breathing room” within and between cards to make it easier for the user to process the information they saw. Padding was also added to the status label, with distinct colors used for the “new” vs “in progress” labels to help separate between the two.

Two report listings in the current app.

Report listings in our redesign.

Converging onto the Problem

While I worked on auditing the app with my group, the second group worked on conducting a competitive analysis with other reporting and listing apps (NYC 311, Zillow), and the third “empathy” group created personas and storyboards using the initial user research insights. 

 

As a whole team, we met back together and discussed a new user flow for the app. 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.

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.

As pointed out in earlier research, users ultimately cared the most about knowing if their issues had been resolved or at least attended to. Much of the user dissatisfaction stemmed from the frustration and ambiguity over not hearing back on reports they created, so we knew this was also a very important area to address as well.

 

With that, we converged on two primary problem statements we wanted to solve in our redesign:

1. How might we integrate the process of looking at existing reports (pre-reporting) with the process of making a new report?
 
2. How might we improve communication between the City of SD and residents in terms of the progress of the reports they have submitted?
Ideation

Sketches from our Crazy 8's fun.

After we used the Crazy 8’s method to brainstorm as many concepts as possible, we created a site map to get a better picture of how all the features of the app could be integrated better in our redesign. This would also give us a tangible artifact that could be communicated with the project managers and the client.

The page hierarchy of our proposed redesign, as shown by this site map.

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. That 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 explore it. If it was the issue the user had meant to report, they could then indicate that to the app without having to finish making the report.


We wanted to quickly test this new flow with users to see if it made sense before we took it to higher-fidelity. I reached out and conducted user testing on a paper prototype with 2 users. Apart from providing minor suggestions, they both liked the idea of showing similar exciting reports when making a new report, so that if they were in the case they wouldn’t have to make their own entire report.

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

Brainstorming Solutions

A Sudden Halt Transitions into Project Leadership

Just as we were about to start working in Figma and create wireframes based on the positive feedback, the COVID-19 pandemic hit in full storm, and the majority of students at UCSD moved back home. For about 2 weeks the project completely stalemated, and there was a lot of uncertainty on whether it would even be completed. 

I knew we had worked hard on our project, and was upset that we had to stop just as we finally started designing. So I decided to take the initiative to ask who was still able to work on the project, and then scheduled a meeting to discuss what we still needed to do. From there I became the unofficial project lead, as I set and planned meetings, delegated tasks, and listened to and worked with the rest of the team members to deliver a solution that would bring value to both users and our client. 

Problem

A lack of clear information hierarchy in the information shown on a report page makes it seem cluttered, and prevents users from being able to efficiently scan through details.

An example of an illegal dumping report.

Suggested Solution

Typography improvements to reduce the amount of time it takes users to understand the specific details, thus creating more scannable content. This is essential so that users can quickly see an existing report and determine whether or not their issue had already been reported.

Problem

A lack of user control prevents users from being able to search or filter through reports to see the categories of reports they care about (ex. potholes). 

While the app doesn't have a filter, the "view reports" feature on the website allows users to select specific categories of issues.

Suggested Solution

A filter or search bar that allows users to filter all reports by the categories that users already use when making a new report (which creates a consistent mental model). A search bar can also be valuable by giving users flexibility in terms of how they view existing reports.

Expert Review

I then worked with 2 other consultants to audit the current app using heuristics to guide us. This allowed us to understand how specific design problems had contributed to the use patterns we had discovered in our research. We mostly looked at the mobile app since we learned that most users used Get It Done on their phones. But, we compared the app with the Get It Done desktop website to see if there was anything one did better than the other. 


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.

Problem

A lack of clear information hierarchy in the information shown on a report page makes it seem cluttered, and prevents users from being able to efficiently scan through details.

An example of an illegal dumping report.

Suggested Solution

Typography improvements to reduce the amount of time it takes users to understand the specific details. This helps create more scannable content and allows users to quickly determine whether their issue has already been reported.

Problem

A lack of user control prevents users from being able to search or filter through reports to see the categories of reports they care about (ex. potholes). 

While the app doesn't have a filter, the "view reports" feature on the website allows users to select specific categories of issues.

Suggested Solution

A filter or search bar that allows users to filter all reports by the categories that users already use when making a new report (which creates a consistent mental model). A search bar can also be valuable by giving users flexibility in terms of how they view existing reports.

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

  • linkedin-icon_red
  • email-icon_red