How might civic tech volunteers make everyday citizens’ reporting experience easier and more delightful?

In all honesty, the above statement was what we should have started this project with, but that didn’t happen. This lead to a few unfortunate turns of events in this project. But I’ve also learned a few lessons from it, and I will take them to my next projects. Mistakes aside, this project gave me an opportunity to experiment with things I did not have the chance to do much in my regular work, namely mobile design and product design. Here is how it actually went.

First meeting

Ottawa Open 311 API

ServiceOttawa Site

The current ways people can report non-emergency civic issues, like reporting a pothole, are through:

  1. Calling 311, or
  2. Submitting a service request through ServiceOttawa website

The wait time on 311 is on average 17 minutes, while ServiceOttawa’s website requires users type in a short, but less-than-exciting form. Surely we can make this process much faster, easier, and more delightful.

Following suit from other cities providing more open and collaborative digital services, City of Ottawa rolled out its own Open 311 APIs.

Right after their presentation in Ottawa Civic Tech’s hack night, someone had the idea of making a ‘one-click’ app to report small issues like potholes. The objective was to keep the service simple, with user doing very little while the software sorts out most information. In the following weeks, we brainstormed ideas, discussed technology implementation details, while I started working on mocking up a mobile experience.

Open 311 API

Design Iteration 1: Quick mobile UI proof-of-concept with Material Design

Ottawa311 app flow

The developers on this project were all talking about how to build this ‘one-click’ experience and ready to start coding right away, so I thought I’d give them a very quick first version design first using a design system I’m already very familiar with. My plan was to keep them occupied while I work on the user research to improve the product design. I could do UIs faster and better than I could do user research at the time, so in 1 week’s time, I put together a rough mobile app design with these 4 main value propositions:

  1. Report
    • Smarter way to report (automate/autofill as much info as possible by innovative technology)
    • Better form design (bridging gaps between citizen’s mental model and government service terminologies and methods)
  2. Track
    • Accountability and transparency of government service
    • Quick find/search/filter different issues to see the current state of things
  3. Explore
    • Check if an issue user sees has been addressed (so as to not duplicate what’s already been reported)
    • Social functions to escalate status (have community input to see the magnitude of impact of an existing issue)
  4. Incentivize
    • Gamification to encourage people using this app rather than call
    • Create opportunities for the app to be monetized

Deep down, I knew it was against my design training to settle on one solution right away, not without exploring much of the context. But I thought, the developers seemed eager and ready to have some fun with the project, so who was I to curb their enthusiasm? That was my first mistake to think that way. The mistake was that I didn’t have to curb their enthusiasm to champion good design practice. I could have been candid with them and explain a little user research and project definition can avoid churn.

The mistake was that I didn’t have to curb their enthusiasm to champion good design practice.

That said, it wasn’t the only reason this project didn’t work out. We had different expectations and philosophies on what this project should be, and everyone couldn't get on the same page as a group. More, we did not have enough people to do all the work for every feature I proposed in the design. This version of the prototype seemed too loaded and complicated, so I went on to make a stripped down version of this app focusing on and MVP product just reporting potholes.

Design Iteration 2: Unintentionally offensive iOS pothole app

Snaphole app flow

Interact with InVision prototype here

I did some work again to make the centre of the workflow about reporting potholes, and gave it a new visual design. We also wanted the content copies to be a little bit ‘edgy’, as a strategy to generate buzz, despite having no marketing research to support this idea. There are good and bad things about this iteration.

Good: Focusing on one precise feature worked, and we actually moved forward with building an iOS app with proper service API. Even gained enough traction to have a marketing site and a release plan for the app store.

Bad: We’ve created this cringy monstrosity. We can’t let it out into the world like this.

Saving grace: the civic tech community

Civic tech support

Good thing about the civic tech community is that there are a lot of people who understand design and supports good design. I only had to ask for help. There were other designer, content strategist, project manager, and everyday people giving us feedback on how to improve the interaction and application. They reminded me that I had to ask the hard questions and think of the user. And think of a better name for the app.

I had abandoned the user at this point, putting the team first and getting the app built. I thought by doing so the team will still be motivated to finish up. This went unspoken, but we were having challenges because we had to keep changing the design based on the feedback, and everyone was feeling the churn. The challenge was also that the developers all write in different languages; hard to keep the project going.

The bitter sweet taste of learning something: the importance of project management and design leadership

Eventually we got there, had a reasonable name: Snap311. We also didn’t have to do too stylized writing for the UI. Although this project took a toll on me and my confidence as a designer. Other people too moved on to their lives. Then this problem popped up again and again, the hard questions I needed to ask keeps popping up. I didn't do enough market or user research. This happened when we were asking the content strategist what to do, then again when we had the person with the business case on.

We've started and stopped this project twice. Maintaining a volunteer project isn't very easy. The project definition was always a little bit muddled; I was also a bit uncareful to let this project be driven by the technology but not by values. I always felt like the ground was not firm enough for me to push for things. I thought the reason was because no one gets paid for doing this, but now I think of it, it was because we didn’t have the

Design Iteration 3: Doing the right thing, starting small

Snap311 wireframe

Learning these lessons, I realized there’s no avoiding the hard questions. I need to work on market and user research, and developing a product strategy. I need more rationales for why we should build this product. In the mean-time, we are trying to revive the project and allowing more developers to contribute to the project.