Planning out research

For research to flow smoothly and explore the three components of the user journey, I dispersed our subteams to each target one component and focus on the research questions put forth in the initial proposal. Many research methods were available with the resources and network provided to contact users. I gave the team discretion in selecting methods, and we pursued three key methods that were key to gathering as much information as possible.

• Surveys conducted on 96 residents - Surveys were separated into pre-reporting, reporting, tracking questions distributed across a user-consented email list. I provided oversight on surveys for mitigating bias and redundancy before approving send-off.
  
• Usability tests conducted on 11 participants - Tests targeted on task success and completed time in pre-reporting & reporting process. I worked with project managers to setup and provide testing protocols, resources, and participant incentives.
  
• Codesign session with 3 residents - In-person sessions tasked participants with noting problems in tracking issues and guided them in creating new tracking features that would work toward their needs. I facilitated setup, questions to ask, and setup interviews for our team to explore with users.
  
• IA mapping and card sorting - Reporting process and types of issues to report divided into categories and served as part of a larger expert review. I showed my team this practice through a workshop to understand how to maximize insight from sorting together insight and setup interview slots for research.
  

Planning out research requires creating a pool of participants evenly distributed among all user demographics. I directed our team to recruit for research across multiple user groups to get an even distribution of age, usage frequency, and residing council district in San Diego.

Interpreting findings

With rows of Excel data and over a dozen transcripts, I took our numbers and words and worked with the team to find the strongest insights from the research data. With these insights, we were able to highlight key datapoints and then determine trends within those points that answered our initial questions.

Data was divided into categories of the user journey: pre-reporting, reporting, and tracking, which are all described and interpreted in detail below.

Pre-reporting

The GID platform provides a collection of reports that can be accessed by the user in list or map view. As a feature, it is intended for the user to review previous reports within their relevant vicinity.

We took a look at our survey data and usability test sessions to gather insights:

• 71.9% of participants who had used the platform before said they never check to see if their report had already been made before making their own report on the same issue.
  
• 80% of participants either didn’t know there was a way to look at existing reports or said it never occurred to them to look at existing reports.
  
• Usability testing performed on users who were tasked with reporting a pothole, observed that none of the users checked existing reports for a duplicate issue before making their report.
  

Overall, we found three major trends.

1) The biggest priority for users is reporting an issue, and it’s important for users to have better awareness of the status of reported issues. Users expressed inconsistency in how certain issues are responded to; they don’t understand the reasoning for why some issues are closed or not, and why some issues remain open, and why they are only sometimes informed about these status changes.

2) The existing reports tool is difficult to use, but more importantly, it exists as a tool separated from the reporting process. The task to look for an existing report simply does not fit into the user’s timeframe and workflow of wanting to report on issues they see. Only 19% of users were actively using existing reports to determine if an issue had already been resolved.

3) Recent reports has a lack of value in which it does not allow users to easily build off existing reports. If a user sees a report that is missing details, or wants to express that they have also encountered that issue to potentially make it seem like a higher priority, there is no way to build off an existing report. Instead users must simply make a new report.

Reporting

Reporting an issue serves as the primary feature for the majority of GID users. While providing a
useful service as convenience to users, the reporting process is still open to suffering in points of
usability, efficiency, and reliability.

Performing an analysis on the information architecture and structure of the reporting process were motivated by pinpointing the roadblocks in the reporting process.

1) In usability testing, we discovered a source of error where GID app users have to enter all of their information in a single step and after clicking submit, try to edit the report when submitted but cannot. Meanwhile, web browser users on the GID website have a different reporting process, allowing them to review details before submission and also revisit their initial report to edit details or delete the report if misplaced. This still leaves users on the app more prone to unfixable errors, unable to edit or delete their report after it’s been made.

2) There are stark contrasts in the variations of issue categorizations on web and mobile platforms of GID. After breaking down each category using a card sorting exercise with users, we isolated the issues that could potentially cause confusion and make the reporting process harder, as shown in the table below.

Blue represents options not present on the other platform.
Red represents options that are the same report filed under different categories on either platform.
Orange represents options that are the same report but labelled differently across platforms.
Purple represents options that are different reports with the same label, such as a broken streetlight vs. a broken traffic light both having the label of Light Out.

In general, this research illuminated how picking the right issue can be confusing for a user and called out how the confusing labels and names of other features throughout the app could also disrupt the efficiency reporting process.

3) The client group highlighted an issue of incentivizing users to input their contact information for report follow-up. While a feature exists for users to input their contact, participants in surveying and usability testing expressed concern in maintaining anonymity for safety and privacy issues. This is not only to anonymize themselves from city records, but from potential violating parties who are the reasons for certain issues (such as graffiti, dumping, or other vandalism).

From observing information architecture, we found that users don’t notice this small gray subtext explaining that their contact details wouldn’t be visible to the public. This important detail causes the unnecessary concern for privacy, and drove our expert review to discover more experience touchpoints where text could be misinterpreted or missed altogether.

Tracking

Any user wishing to track issues reported can access the “Recent/Reports” page & the “My Reports” page on mobile. By default, both Reports pages are presented in table-view where reports contain titles, locations, brief descriptions of the problems, an indicator stating whether the report is “New,” “In Process,” or “Closed” and optional images.

1) Information about a report’s status is difficult to find on the platform, and if found, is insufficient. The ability to find updates on the site as previously described is not intuitive for 41.2% of users, rating that there is little to no detail about the progress of a report. The amount of detail provided on a report’s status is confined to the three indicators “New,” “In Process”, and “Closed”. There is no additional detail provided other than what the user inputted in the reporting process. Users verified that the lack of detail in updates often had them taking initiative to check the location of the report in-person (41.5%) to note changes to the issue reported.

2) When reports aren’t addressed or updated, users feel an inconvenience despite the platform’s goals. Users brought up several common issues regarding the inconvenience they felt when waiting on a report for resolution. The most common issue users faced was that reports are not addressed and sit in the report queue for months at a time without any futher update. Other complaints were heard from users being dissatisfied with the lack of update regarding the status of a report.
‍
A significant number of users would not take any attempt to resolve these issues they experience (31%), while some users expressed that they would resubmit the report or call a City department to inquire about the issue (31.2%).
‍
These frustrations for users have potential to exhibit a negative perception of the GID platform’s efficiency versus other methods of infrastructure reporting. It appears imperative that a solution is offered to provide users with more updates in order to maintain an image that GID is the fastest and most convenient method of reporting city-related issues.

3) Users in codesign described pain points aligning with research and provided a new way to indicate better tracking. For a mobile interface, users are faced with a list of issues that becomes confusing with the color coorespondence that is given to the status label of an issue.

Both users suggested that the visual indicators for reports be more accessible for all users. At the time, reports were given a green indicator for an open case, and blue for a closed case. There was an entirely different color scheming on the web platform where any issue status was given an orange tag.

Users suggested green for reports in progress, yellow/orange for new, and red for closed.

Defining solution scope

Independent of a specific solution, I sat down with my fellow project managers to identify domains where modifications would be necessary in order for GID to advance and excel in its purpose. This solution scope translates user needs and operational goals into specific requirements for offering functionality and content to users.

Increasing engagement between City and user.
As the user base for GID grows in the forseeable future, increasing engagement with the end user is a big priority. As users provide the influx of reports regarding City issues, they conditionally expect interaction and feedback regarding the issues that they report themselves. This goes much
beyond communication, involving touchpoints in incentivization, content strategy, visual design, marketing, and continuous user surveying & research.

Resolving interface usability issues.
The usability issues discovered in the reporting process for both mobile & web versions of GID highlight reasons that may lead to a user error, or potentially frustrating them to the point of not submitting a report. Getting the user to their priority of resolving issues requires attention to the details that prevent users from getting there.

Sparking communication amongst users to inform City staff.
There is opportunity to get issues noticed faster, resolved faster, and communicated faster. When users communicate with each other, and have a direct line to City departments responsible for working on issues, they’re more empowered to fill these issues with confidence.

Consider reports that are duplicates: if users are given an architecture that allows them to provide feedback to one report rather than separate multiple reports into parent-child cases, they feel more confident in the prominence of the report and the priority of its resolve.

Creating City staff awareness and actionability.
While user experiences outside of GID platform interactions may not be disclosed to City staff who operate service models, creating opportunity for those staff to observe and emphathize with user behaviors will inspire better solutions to create user satisfaction. Every department has an independent method of interacting with and resolving issues; their own experiences might provide new methods of empowering the GID community.

As part of researching solutions to address the scope of the project, we documented several solutions to features aimed with improving GID user experience.

I directed one subteam to observe direct and indirect competing apps in order to discover potential features that could prove useful to the GID app. I also had a second larger subteam work with City staff to perform an expert review on the platform and identify usability issues that could easily be fixed.

• Improving ability to filter reports.
  ‍Creating filtered views would allow users to sort through addresses, search within distance, dates of reports, types of issues, and city council districts. This would be a useful component to implement into GID, as users are currently forced to sift through “Recent” reports manually.
  
  NYC311 is similar to GID in the nature of a civic maintenance app, and their inclusion of a filter helps users find a corresponding issue much more quickly and efficiently. Zillow, a house-hunting app, provides an overview of potential listings on a map with detailed content in a collection view at the bottom of the screen; there are additional filters on their map screen that change the content dynamically.
  

• Providing users with more contextual information.
  Although the GetitDone app currently allows users to look up addresses, it only does so when creating a new report. When looking through “Recent” reports, there isn’t a search bar. The implementation of such would make it much easier to sort through “Recent” reports. In order to do this successfully, a user should be able to type in an address, type of issue, zip, or city and locate the reports.
  ‍
  Currently, when a user clicks a pin on GetitDone the address, written description, and the status of the report are the only thing provided. If a more comprehensive, but brief amount of information could be displayed per report, it would provide a better user experience.
  ‍
  The team looked to Zillow for inspiration, noting that the housing app provides the ability to search for address, city, zip, or neighborhood name when searching for rental “items”. Zillow also provides information per item in a view that compresses and composes data into a simple-to-read view.
  

• Creating accessible navigation.
  GID currently misses hierarchal navigation on the mobile app. For instance, if a user wants to check “Recent” reports while they are in the process of creating a report, he/she must repeatedly click the back button. The introduction of the hamburger menu would allow for more maneuverability with less clicks.
  ‍
  Several applications incorporate navigation in the form of a navbar at the bottom, or by including a “hamburger menu”, that can bring up links to other viewports by simply clicking.
  

• Uncovering further usability issues on the platform.
  To examine all usability issues related to the GID user experience, we worked with the City client group to conduct an expert evaluation on both the mobile app and desktop website versions. We identified different issues and determined why they were important to consider. For example, was the issue simply a cosmetic issue, or was it a usability catastrophe that was imperative to address? We also suggested possible solutions to fix the more salient issues, as these solutions would benefit the prototyping phase.
  
  The team created this report by looking through the three components of the user journey (pre-reporting, reporting, tracking) and adhering by heuristics and usability guidelines to determine severity of a usability issue. By comparing the mobile app with the desktop site, the team was also able to evaluate how the two compared and contrasted from one another.
  
  To condense this case study, you can read details from the expert review here.
  

Creating design objectives

With the risks we observed from the collective user study results, as well as the opportunities we discussed within the team, we aimed to provide solutions that approach issues and create an overall better experience for users to report issues, add onto pre-existing issues, and create better issue tracking.

I divided our team again into new teams for each journey component, working toward goals to improve features and usability.
‍

UI component library

I set up with a few members of the team to create a compnent library for the assets we would use for visual layers. This system comprised of the visual design language (colors, typography, imaging) as well as assets and commented guidelines on using those assets within the application.

Our aim was to make integration as seamless as possible for the City's in-house development team to use their already-existing iOS UIKit, so many of our assets resemble what you would find on a boilerplate app.

Iterative prototyping

Our team navigated through setting up a routine of prototypes that could be rapidly created, tested, and iterated upon to get results that we needed.

I facilitated our group's initial ideas using a Crazy 8's practice by Google and working toward solution sketches to be voted on by the team. Our team got to work on creating paper prototypes, which were then tested on with edits made to ensure function and move through ideas.

Wireframes enabled our team to merge changes made to the app through paper prototypes with new user flows, a new IA built upon the reporting + tracking process, and a stronger sense of content to be shared with users. These were also iteratively tested and provided to the user.

With these changes successfully implemented, we could integrate our design system and content with wireframes to propose features to the City team.

Feature proposals

Encountering existing issues in reporting

With the optimal flow in mind, the reporting process was redesigned in a way so that the user’s entered location and selected issue would be used to pair them with similar reports near them.

If the user determines that the one of the similar issues shown to them is their issue, they can indicate that they’ve “also encountered this issue”, and add details.

Save a report as a draft

Some users had expressed how sometimes they found themselves in situations where they were unable to make a whole report, e.g. when driving or biking by.

They would sometimes try reporting this issue later on, and would have to remember where they encountered that issue. Or, they would forget to make that report until later onwards.
‍
With this proposal, users would have the ability to save their reports as drafts stored locally on the user’s device, allowing users to get right back to where they started in reporting the issue they observed.

Filtering recently reported issues

The expert research, as well as initial usability testing, had shown that the Recent Reports feature wasn’t being utilized due to its lack of efficiency and flexibility. There was no way for users to look through reports to find a particular issue that was important to them.

With this in mind, we added filters so that users could select issues that they were interested in seeing reports already made on, filterable by type of issue, status of completion, distance from location, and date range.

Dynamic updates on reports

The tracking research had shown that it was imperative to focus on finding ways to create better communication between the City of SD and users on reports they had created. Reports can sit for a long-time without any update or indication of the next steps the City will take, or they may also be closed without any indication.

With proposed additions, users can track the reports they created alongside other reports they have encountered.

A huge modification created exists on a report status: users can track updates on a report item (updated by City staff through Salesforce) to see what progress has been made on resolving the issue or request. Users also have the ability to modify details of or delete a report, to avoid confusion and mistakes.

Final prototype

On top of all of our feature proposals, we created a full interactive prototype for our client group to share and discuss among their teams on how to implement these changes.

Click here to view