Our thinking

3 ways to build Civic Tech solutions that succeed

11 October 2016

Civic technology — technology that improves the public good — is a growing space with plenty of room to learn. I was recently invited to speak at three conferences in Europe in the civic technology space, so while reflecting on my personal journey over the past five years in this space, I inferred some strategies for leveraging technology in civic innovation.

First, a bit about how my journey has taken place:

After six-and-a-half years at Yahoo!, I did a year-long public service Fellowship Program at Code for America in 2012, which was the most unique and eye-opening experience of my professional life, working with the people who run cities. After that year, I founded Code for Pakistan in 2013 and discovered myself in the position of doing all of the things that running a civic technology organization entail — community organization, design thinking, open source and open data advocacy, civic engagement, government liaising, product creation and direction, volunteer management, marketing, operations, and anything else to keep the organization going.

Speaking at PDF in Poland

Image: Fundacja ePanstwo

Code for Pakistan’s work is overseas in Pakistan, and it is deeply entrenched in the global civic technology community as one of ten official partners of Code for All. Because of my work at the intersection of civic technology and user experience, both in the US and internationally, I was invited to speak at three illuminating conferences in Europe earlier this year:

  1. Personal Democracy Forum (PDF) – Poland-Central & Eastern Europe in Gdansk, Poland
  2. CityOS Smart Cities Conference in Dubrovnik, Croatia
  3. The Impacts of Civic Technology Conference (TICTeC) in Barcelona, Spain

Lessons from my experience found their way into my talks, and here’s a summary of three overlapping themes I’ve discovered:

1. Lead with people, not problems

It’s critical to reduce risk of failure when the stakes are high. In public services, the tolerance for failure is often lower than it is in the private sector. The users are citizens – they are not just customers. The products are public services that people depend on… In contrast to not getting your book delivered on time, if the fire engine doesn’t show up, your life is at stake. These high stakes create a culture that discourages innovative approaches in government services.

As an example of this culture, while the private sector widely uses the User-Centered Design approach to mitigate the risk of failure in building solutions, the public sector lags in adopting the practice.

The key to User-Centered Design is the process of designing a solution according to a philosophy where the end-user’s needs and limitations are a focus at all stages. The goal is basically that rather than requiring users to adapt their attitudes and behaviors in order to learn a system, the product can be designed in a way that it supports its intended users’ existing beliefs, attitudes, and behaviors.

Empathize, Define, Ideate, Prototype, Test

Image Credit: Stanford d.school

Projects fail when we build without understanding the full context of needs and usage. The first step in the User-Centered Design Process is about building Empathy. Empathy is not just sympathy for someone else’s circumstances, but it’s the deep intuition for what it feels like to live their lives and to understand their needs and wants and problems. You have to immerse yourself in the problem from the user’s perspective so that you are not relying on your own preconceptions or domain expertise, but you are really learning and understanding the needs of the people you want to help.

Once you’ve understood your target user’s needs, pain points, and goals, then you can define the need of theirs you want to address, and then ideate on what the possible solution could be.

A good example of this approach comes from IDEO’s in-home sanitation project in Ghana. IDEO used User-Centered Design to effectively involve the urban poor in a project to improve public sanitation in a place where the only toilets are public ones. What’s important, though, is that they didn’t go in with a preset solution.

In the first phase, they focused on uncovering new opportunities for providing in-home sanitation. They conducted interviews, used research tools, and did lots of observations and shadowed people to gain a deeper understanding of people’s day-to-day lives and their sanitation needs and preferences.

Gathering input

Image Credit: Ghanasan

They gained tremendous insights from user testing, and created a urine diverting toilet with a bio-digestor and a removable, sealed waste tank — a product that had been tested through the entire end-to-end lifecycle with all the different types of users, including how the tanks could easily be stacked for transportation by service people to take them for cleaning. The outcome was very profound and successful in achieving their goal.

For more information on how to apply the user-centered design process to public needs, view my 17-min talk at Personal Democracy Forum in Poland.

2. Prototype and test with real users

The only way to know if your solution is headed in the right direction is to test it as early as possible with your target user. That is the key difference between prototyping and piloting.

In piloting, which has traditionally been the international development sector’s approach, you often spend energy creating your entire solution and only then learn that it doesn’t work. From there, you can either toss out all your effort and start over, or go ahead anyway towards low adoption.

With prototyping, on the other hand, you prototype only what you need. You create the smallest, most basic functionality of your solution that’s enough to put in front of users and get some insights. You test your prototype early and often. Compared to piloting, prototyping saves on scale, duration, and materials. And it greatly reduces your risk of failure.

Here’s an example: the City of Boston’s Transportation Dept installed two public parklets in two different neighborhoods. These are small public areas for people to sit, chat, read, sip coffee, or hang out. Each of these public parklets cost somewhere between $15,000 and $25,000. And no one ever sits there. Can you guess why they failed?

Boston parklet

Boston parklet. Image Credit: MIT Center for Civic Media

It turns out that people were deterred both by the uncomfortable benches — they are curved in shape — and by their placement adjacent to street traffic. You can’t really sit on one and have a conversation with someone. They look more like art installations than inviting benches. The thing is, they didn’t need to do very much to test it out beforehand. They just needed to put up some sturdy cardboard or plastic prototypes of benches in the actual space and ask people to sit on them.

By contrast, in San Francisco, the City has put up at least 51 public parklets, and they are very popular. In San Francisco, they’ve been involving the neighbors and local businesses as participants in the process — and they’re prototyping using a temporary kit of parts to create low cost solutions that can be adapted based on feedback. Another benefit of involving locals in the design process is that it’s a natural generator of excitement and buy-in.

San Francisco Parking Day

San Francisco Park(ing) Day. Image Credit: Park(ing) Day

Since government as a notion is inherently user-centric  —  it exists to serve citizens and help communities thrive — it’s critical for government services to engage users in both needs finding and solution prototype testing.

To learn more about how to conduct needs finding and user testing with users, here’s a talk I co-delivered to the White House’s Opportunity Project.

3. Get citizens engaged in co-creation

The most effective solutions are those that are built bottom-up, not top-down. Needs finding and user testing allow us to take this bottom-up approach. And you can go yet a step further from needs finding and user testing to citizen engagement.

In order for our cities to be citizen-focused, they must be created from the grassroots. It’s people, not sensors, that make their cities smarter. At the Smart City OS conference in Dubrovnik, I talked about how, in order for a city to be a smart city, it needs participation from smart, engaged citizens as well as a sense of community. And to build smart solutions, we need to focus on understanding user needs and treating smart cities as lean startups from the bottom up.

“To be a smart city, a city needs participation from smart, engaged citizens and a sense of community.”

Here’s an example of involving citizens in the process: In 2012, as a Code for America Fellow, I was partnered with the City & County of Honolulu. We created Honolulu Answers as a parallel site to the City’s website that better conformed to how citizens actually want to interact with information on a city website. They’re looking for answers to questions, and they want to take an action when they’re done.

To populate the content of the website, we did something that’s radical when you think about how government is used to working: we asked citizens to write the content. We thought, if it’s supposed to be a citizen-focused website, then why not actually involve citizens in co-creating it?

You’ve probably heard of a hackathon. We held a writeathon, where in one Saturday morning, we were able to populate all of the content for most of the frequently asked questions. But more importantly than that, we created a new way for citizens to participate in their government that was inclusive.

Honolulu Answers Writeathon

Honolulu Answers Writeathon. Image Credit: Bytemarks

People came from all ages, many of them older; writers, geeks, and a blind resident came. And we attributed the answers to the citizens who wrote them. People felt so engaged, they were asking us for more questions to take home for homework. The citizen participation not only gave us headway on the new city interface in just one morning, we also saw a tremendous sense of empowerment and responsibility that residents felt for the place that they lived, based simply on this small act of participation.

What’s more, thanks to the power of open-source applications, the following year in Oakland, the Code for America Fellowship team in Oakland took the open-source codebase of Honolulu Answers and turned it into Oakland Answers. And again held a writeathon. And again we heard about the sense of empowerment and responsibility that people felt for their city based simply on this small act of participation. Honolulu Answers and the writeathon have since been redeployed in a dozen cities around the world, a community favorite.

Takeaways

In summary, the key to making government services meet our needs in the 21st Century is to:

  1. Lead with people, not problems
  2. Prototype and test with real users
  3. Get citizens engaged in co-creation

By using the powerful tools of empathy, rapid prototyping, and user feedback as an integral part of your process, you recruit citizens into being a part of the solution, rather than treating them as consumers of your product and, more broadly, of government itself. You can even recruit their skills to contribute directly in co-creation from the bottom up. This reduces your risk of failure, restores trust in government, and builds a strong foundation for collaboration among stakeholders.

Even doing all this, there are a ton of uncertainties! What should you do when you do everything “right,” but a project still doesn’t succeed? I’ll discuss this question in part 2…

Sheba Najmi is a Senior User Experience Strategist at Exygy and Founder of Code for Pakistan. Matt Luedke also contributed to this post.