How might we make everyday citizens’ reporting experience easier and more delightful?


In all honesty, the above statement was what we should have started this volunteer project with, but that didn’t happen. I and a few Ottawa Civic Tech volunteers, who are eager to create tech solutions for civic problems in their free time, started this project with conviction. But a few unfortunate turns of events left the project half-finished. I did, however, learn a few valuable lessons that I will take to my next projects. Here is how it actually went.

First meeting

Current state: Calls, forms, APIs

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 an Ottawa Civic Tech’s Hack Night in early 2017, a developer had the idea to make a ‘one-click’ app to report small issues like potholes. The objective was to keep the service simple, with users doing very little while the software sorts out most information. In the following weeks, a few more developers with varied front-end/back-end/web skills joined to brainstorm ideas, discuss technology implementation details, while I started 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’ feature, and ready to start coding right away, so I thought I’d give them a very quick first version UI design 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. Less effort to report small civic issues
    • Smarter way to report (automate/autofill as much info as possible by using background data from mobile phones).
    • Better form design (bridging gaps between citizen’s mental model and official language of municipal services)
  2. Keep an eye on your issues and fixes
    • Accountability and transparency of government service
    • Quick find/search/filter different issues to see the current state of your reports
  3. Know what is and isn’t being addressed in the ‘hood
    • Check if an issue 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. Literally rewarding and fun to use the app
    • 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 thinking was my first mistake. 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 explained that a little user research and project definition would 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 in the design.

This version of the prototype seemed too loaded and complicated, so the team and I decided to make a stripped down version of this app focusing on an MVP product only reporting potholes.


Design Iteration 2: Unintentionally offensive iOS pothole app

Snaphole app flow

You can interact with the InVision mock-up 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

When you’ve done something embarrassing, you’d wish people will tell you, so you can fix it, right? Thankfully, that’s what I got from the designers, content strategists, project managers, and everyday people in the civic tech community. They gave me very constructive criticisms and tips to consider the user and the content. I forgot there are a lot of people who understand design and supports good design, and I only had to ask for help. They reminded me that we had to ask the hard questions and empathize with the user. And think of a better name for the app.


Design Iteration 3: Doing the right thing, starting small

Snap311 wireframe

Eventually I realized the contents doesn’t have to be sensational to be successful, and came up with a more reasonable name for the app: Snap311. More, I switched from delivering the design in Sketch and InVision to Google Slides, so that it’s more accessible to everyone who wants to collaborate on the project. The developers also switched to React native, rather than separate Android and iOS apps.

The slides are still a work in progress and are low-fidelity. But it’s the summary of the current iterations, and hard questions I’ve started to ask and found answers for. More work still needs to be done on market research, user research, and product strategy.

Currently I’m not working on this project anymore, because my priority has shifted. But if there ever is time again, I am ready to do things much better.


What I learned from this volunteer experience and what I’d do differently

  • Get everyone aligned on the same vision early on. To keep a volunteer project going is in some ways more challenging than running a startup. There is no time-sheet, no real accountability, and no one really owns anything. You’re often only relying on people’s goodwill, and their own motivation to keep things going. The only thing that can hold people together is working towards a common vision. Not everyone is going to agree on every little thing all the time, and volunteers come and go. Agreeing on the same vision makes some conversations a bit easier. More, it’s when you’ve set a common goal, that you can set smaller milestones leading up to it. So that everyone can celebrate when these milestones are met.
  • There’s no avoiding the hard questions. The same problems popped up again and again in this project: What’s the demographics that will use our app? How will we attract and sustain users? How are the services being done today? What are the pain points? I didn’t do enough market or user research before I drew up the concepts. I forgot that concepts are cheap, and they don’t matter if you don’t have the research to back them up. This is something I’ve known from school, but the feeling hits especially hard in this project.
  • Choose a dev framework most people can work with. Getting the app built was our primary concern, though this ship-first fail-fast strategy didn’t quite work either. The reason was our volunteer developers are all proficient in different frameworks, so it’s hard for them to contribute to the project and accumulate the collective work.
  • Stand up for design, stand up for good design, even when you’re not at work. When you’re the only designer among a bunch of people, it’s often useful to have an elevator pitch ready about why design matters and what is good design. I forget not everyone is trained in design and knows how to articulate what makes things good. You don’t need to be an insufferable stuck-up, and design doesn’t solve all problems, but the world simply needs more good design. I was uncareful to let technology rather than values drive this project, because I always felt like the ground was not firm enough for me to push for it. In retrospect, standing up for design need not be mutually exclusive with compromising relationships.
  • Soft skills, soft skills, soft skills. There are numerous times in the project where things would have gone so much better if we could have a conversation authentically. I don’t claim to have mastered my communication skills, but I’m now seeing all the more values of skills in persuasion, debate, active listening, etc.