Municipal Design

'Surrey Request' allows people in the city to report and track city services. The core brief was to reduce duplicate submissions and the number of service categories. A constraint is that its part of a web app suite and runs CityWorks (an enterprise work and asset management solution).

Conducting an app review, I built a hero flow to break down the different stages required to complete the core task.

To compare findings, my partner and I conducted walkthrough usability testing with people in the city and (PM, QA, BA) colleagues. The task was to submit a report for a fallen tree, it could categorize as ‘Parks Issue’ and ‘Tree Issue’. This lead to a key problem where the category selection was not indicative of your report. Holistically the experience leaves a lot to be desired.

I asked for all the available app analytics and discovered that 'Other' had the most amount of hits. Reviewing submitted reports revealed that they were not unique submissions, they could easily belong to the existing categories.

People are choosing to submit to the 'Other' category to save time from scanning for the correct category and to avoid lengthy follow up questions. This is similar to people pressing '0' to skip automatic answering machines for a real representative.

After understanding the product and the people, the key insights were transparency, progress, and being understandable. I reframed the brief from reducing duplicate submissions and categories, to how might we streamline the long extraneous reporting process for more accurate submissions.

Doing quick sketching, my common theme was anticipating the person's needs.

By asking myself questions as I sketched, it lead me to understand context of usage and the idea of utilizing existing smart phone features. Pictures taken capture a geotag stored in metadata, which then can be utilized to automatically input the location when submitting a report.

I compiled a new hero flow, identifying functionalities needed for development to make sense of how the concept would work.

To identify the strongest UI for answering follow up questions we rapidly created interactive prototypes in Axure and ran tests. For best results of testing three patterns per participant, we cycled the arrangement from ABC, to BCA, to CAB.

For the the most valuable responses, I made an effort to make prototype changes to obvious oversights. In version B, it lacked a signifier that the questions were selectable, this was fixed and ready before the next participant.

My initial assumptions was that showing one question at a time can be problematic as it results in additional screens. Through testing, many preferred one question at a time (prototype C) as it had the “Illusion of feeling faster”, and a “sense of satisfaction”. Also favoured was the ability to review your answers (prototype A & B).

While revising prototype C I thought of a new approach by using natural language. I made a paper prototype with myself and saw that it was a more inviting approach to answering follow-up questions. Unfortunately it was not inclusive, Surrey is a diverse city with many non-english speaking people who rely on the Google Translate extension. This would make natural language UI more difficult to understand compared to other UI.

Being able to interface with a design reveals nuances and discussion. I prototyped in Flinto for complex animations, meanwhile a click through prototype with InVision was used to refer to the most up to date screens. Iterating on feedback, the back button discoverability was strengthened and more visual design was included for stronger differentiation between the sections (stroked grey, green, and orange circles are placeholders for icons).

A citizen shouldn’t be concerned of duplicate entries. The government’s service should be smart enough to identify a duplicate in its backend, or utilize that entry as an indicator of urgency. To further the notion of anticipation and being contextually aware, common report types around the area can be prioritized on the homepage. These can be actionable to initiate a submission from the homepage. Testing would be required to validate this concept.