I collaborated with the City of San Diego, a municipality on the forefront of delivering better experiences to users.
I led a team to determine how the City's 311 reporting app could provide users with better ways to input and interact with reports, and in turn, be satisfied with the outcome of their experiences.
A central theme in our insights revolved around engaging users with pertinent information that would help guide their journey as they report and track city-related issues. We produced prototype designs that focused on engagement while mitigating usability issues and user error.
Designers often focus their skillset and attention to the next hot product to hit the App Store or to a team with seemingly unlimited resources. When that same energy is provided to the products of agencies that are sworn to serve us, those products are bumped to a standard that can contend in satisfaction with any privately-funded product.
When we started working on this project, we had a limited budget, limited resources, and limited timeline to determine how to provide a better overall experience and better completion rate for reports. When we finished, we felt that we had informed and motivated our client group to house a better product that not only satisfies users but empowers them to continue engaging with community to collect better outcomes.
I had the chance to get in touch with the Performance & Analytics Department at San Diego City Hall, who work on bringing unique solutions to city problems as they're highlighted by analytics. Their most rising product, the Get It Done (GID) app, provides users with an alternative solution to calling 311 for infrastructure-related issues. City residents can report anything that's wrong or funky with city property, such as graffiti on a highway wall, pothole in the road, or scheduling a unique trash collection appointment.
There are three main journeys that users encounter when using the 311 app: checking for reports in the user's local area, reporting an issue, or tracking an issue. The folks at the P&A department were most concerned with engagement on reports: how might we retain users to engage through all three journeys as they report issues in their respective communities?
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.
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.
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.
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:
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 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.
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.
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.
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.
☐ Create a new and more efficient filtering system for existing reports.
☐ Crowdsource data on an issue that could potentially be duplicate-reported.
☐ Integrate existing reports within the reporting process, so users know if there is an existing identical report.
☐ Allow users to save report as a draft when quickly moving away from location of issue.
☐ Provide live and tracked status updates on a created report.
☐ Allow users to edit or delete reports to avoid confusion.
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.
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.
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.
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.
As part of our deliverable package, we attached all raw data, design proposals, and formatted insights in a UX audit. We also added on feature documentation with a few designers to serve as contact points for the client group's development team.
Moving forward, I recommended to our client group that security & privacy, consistent cross-functionality, and onboarding new users to GID are critical to moving the product further along its goals of engaging with the local community and inspiring great results.
I've been in contact with the City GID team, who as of 2021 are testing implemented designs for a new production build of the app. Now I'm optimistic in the future: creating and completing design projects like this one is an impact I wish to have on as many groups and organizations as possible.
Stay tuned and don't forget to subscribe to my mailing list if you'd like to hear about more interesting projects like this. Cheers!