Civic Innovations

A new focus on the user

These days, in the world of civic technology, it’s all about the user.

Digital government service redesign, with an enhanced focus on a higher quality user experience, is being institutionalized in the federal governments of the U.K., U.S and Australia. The civic technology community is rallying around a new focus on building solutions that are needs-responsive and community-driven.

“Build with, not for” became the unofficial theme of last year’s Code for America Summit, and the upcoming Personal Democracy Forum in New York will feature a similar theme with talks and panels focused on broader engagement and inclusiveness in the development of civic technology.

Organizations like Code for America have long been focusing on redesigning government service interfaces, but this idea now seems to have permeated every corner of the civic technology movement. This wider embrace of the need to enhance the user experience with government is coupled with a recognition that civic tech solutions are most effective when developed with the full participation of those that they are meant to benefit from them.

In the words of Laurenellen McCann, who introduced the “build with, not for” mantra at last year’s Code for America Summit:

“To be used for social good…technology needs to be directed, and for its greatest, most transformative impact, it needs to be directed by those who will benefit the most from the creation of the social good.”

With investment in civic technology predicted in the billions of dollars over the next few years, this feels like the right time to critically evaluate where we are in the civic tech movement. We should work to identify strategies that will help ensure that the work we are doing will be as impactful and lasting as it can be. This is the right time for new ideas on how we can do this work better.

With that in mind, it is worth noting that the fundamental idea of inclusive, collaborative development of services – with the full participation of those being served – is not a new one. Ideals very similar to those articulated in the “build with, not for” approach to civic technology are encapsulated in a concept familiar to those from the world of public management – “coproduction.”

The idea of coproduction is focused on the collaborative development of public services – with those being served by government (or other public service providers) acting as empowered collaborators to help determine how these services are designed and delivered.

In a 1983 article published in the journal Public Administration Review, Jeffrey Brudney and Robert England (from the University of Oklahoma and Oklahoma State University respectively) offer the following summary of coproduction, which could be used almost word-for-word to describe the modern civic technology movement:

“Coproduction is an emerging conception of the service delivery process which envisions direct citizen involvement in the design and delivery of city services with professional service agents. In this manner, coproduction proposes an answer to the more services-less cost dilemma: By supplementing – or perhaps supplanting – the labors of paid public officials with the service-directed activities of urban dwellers, coproduction has the potential to raise both the quality and the efficiency of municipal services.”

The idea that a journal article from 30 odd years ago could articulate some of the ideas underpinning recent thinking in the world of civic technology might seem surprising – I certainly found it so. But this is good news – there is a large body of both academic research and professional practice around coproduction over several decades that may hold valuable lessons for the world of civic technology.

Additionally, for practitioners and researchers in the field of public management, the underpinnings of the modern open data, civic hacking and civic technology movements (which all developed in just the past few years) are actually well represented in the long history of research and practice that supports the field.

There is much that both civic technologists focused on user-centric, community-driven service design and professionals in the field of public management can learn from each other. These two worlds are not so far apart – our objectives are more closely aligned than some might have thought.

What is Civic Technology?

“One of the wonderful things about civic technology is that no one really knows what it means.”

— Forest Gregg, DataMade.

To understand what the literature on coproduction might teach those in the civic tech movement, I think its probably helpful to first clearly define what civic technology is. This term can seem nebulous, and may be defined to cover a fairly broad range of technology and activities.

David Moore of Participatory Politics has an interesting post describing the different kinds civic technology where he makes specific note of those solutions focused on “responsive and open city services” – apps like SeeClickFix, Public Stuff and others.

In another post, Micah Sifry of Tech President groups the different actors from the broad spectrum of activity in the world of civic technology into four general categories. This is a useful approach to understanding the landscape of civic technology, and can help us zero in on the segment of most interest to this discussion.

For the purposes of discussing user-centric, collaborative digital service design vis-à-vis the traditional idea of co-production, we can limit our analysis to the work being done in what Sifry describes as “digital government organizations” – these are organizations and individuals concerned with improving the access to and quality of government services from both inside and outside of government.

Organizations like Code for America and civic hacking groups in cities across the country are those most visibly embracing (and starting to use) the new user-centric, community-driven approach to civic technology. Inside government, new organizations like 18F and others are establishing methodologies that focus on user needs as a prerequisite for building or acquiring new technology solutions.

For the purposes of this discussion then, the term “civic technology” is taken to mean technology solutions that help governments do their job of delivering services to citizens more efficiently, enhancing the quality of public services or supplementing the services offered by governments or other public sector organizations.

A good example of what I mean by using this definition is a civic technology solution called Promptly, built for the City of San Francisco by a Code for America Fellowship team in 2013. Promptly sends succinct, clear messages to CalFresh recipients via SMS notifying them of upcoming due dates and providing other important information with the goal of preventing unnecessary benefit terminations (referred to as “churn” in the world of social services).

Its a great example of civic technology enhancing the quality of a service already provided by government. It’s design embraces the user perspective – in fact, it was developed using stories from actual CalFresh recipients who were caught in a benefit churn cycle. It uses plain language in messages sent to CalFresh recipients – as opposed to the dense legalese in official letters from a city agency – and can provide information in multiple languages (something that official hard copy notices do not provide).

In short, it was designed and built with both the user perspective and the user experience in mind.

What is coproduction?

The academic literature on coproduction goes back to at least the early 1980’s, and it is interesting to note that some of the early discussion around this concept is borne out of notable examples of municipal distress. In fact, I think these early attempts to define coproduction could be successfully used today to describe the civic technology & civic hacking movement:

In their 1983 article “Toward a Definition of the Coproduction Concept,” Brudney and England make special note of the financial plight at the time in the City of Detroit where then Mayor Coleman Young proposed a new approach to city services that included the efforts of ordinary citizens. This approach was derided at the time by some as an example of “self-service government.” Brudney and England’s response could very well have been written as part of the lexicon of the contemporary civic tech movement:

“Government is a reflection of those who define the city – the local citizenry. The ‘self-service’ concept constitutes a redefinition of traditional service delivery patterns.”

The modern civic tech movement was largely born out of the experience of cities. Washington DC, New York and Chicago were among the first governments to actively recruit outside software developers to build solutions on top of government open data. And the first governments to partner with Code for America – and the majority over the life of the organization’s history – have been cities.

It makes sense that we would see cities as the places that gave rise to both the initial embrace of coproduction and later the civic  tech movement. Cities provide a more comprehensive and intimate range of services to citizens. And they are also extremely limited – far more so than states or the federal government – in their use of various revenue sources to fund their operations.

If necessity is the mother of invention, it makes sense that cities are the birthplace of the the civic tech movement and the touchstone for our understanding of the concept of coproduction.

The most broadly accepted definition of what coproduction is – at least as far as I could find – comes from a 2003 study in the Journal of Developmental Studies:

“The provision of public services…through regular, long-term relationships between state agencies and organized groups of citizens, where both make substantial resource contributions.”

Though written in an entirely different context, I think its striking that this definition of coproduction could very accurately be applied to the modern civic technology movement in general, and the more recent community-driven, user-focused efforts of “build with, not for” in particular.

What can we learn from coproduction to improve civic technology?

I think there are some valuable lessons we can gain from looking at the academic literature on coproduction that can help guide and fortify the efforts of those advocating for user-centric, community-driven digital service design.

The first, and most important is that some of the foundational ideas driving the modern civic tech movement are – in a way – a corollary to an idea that has several decades of familiarity to public managers and public administration researchers.

One of the most significant hurdles facing advocates of open data and government collaboration with civic tech groups is the perceived “newness” of it. Anyone who has ever pitched the idea of “government as a platform” to a public official will know how hard conveying this idea to those outside the world of civic tech can be. But many of the ideas that the civic tech movement is built on are not new – they are well represented in decades of academic study and professional practice in the field of public management.

Our job as advocates of open data and government collaboration with civic tech groups may not be so much to convince public officials that they should start doing these things, but to show them the ways that they already are.

Additionally, the academic research on coproduction may offer a framework for how our modern view of “build with, not for” gets implemented. I think there are lessons we can take away from this large body of research that can inform how we reimagine they way we build 21st Century digital services.

For example, a 2007 study by Tony Boviard from the University of Birmingham helps establish a matrix that we might use to distinguish between the different efforts to bring a user centric focus to digital services from inside government (through the work of organizations like 18F) and from outside government (through the work of civic hackers and organizations like Code for America and the Smart Chicago Collaborative).

Boviard constructs a continuum that weighs the relative level of involvement of the different actors in the coproduction process – service users and professional service providers. He distinguishes between coproduction that occurs with the community of users playing a mainly consultative role while the service itself is delivered by service professionals, and what he terms “full user-professional coproduction.”

He uses the example of participatory budgeting as an example of the former state – where members of the community provide input that is used (or not) by budget professionals to make spending decisions. The later state – where community members are full partners in service delivery – are traditionally seen in things like neighborhood watch groups or community cleanup efforts, where community members actively participate themselves in the delivery of a service.

When we think about user-centric digital service design in the context of this continuum, it can help us to distinguish some different approaches at work. The approach being taken by government organizations like the Government Digital Service (GDS) in the U.K. and 18F in the U.S seem to have adopted more of a “user consultation” approach to building government digital services. The people working in these organizations care deeply about the user’s perspective and the experience they have when consuming digital services, but the design and implementation of digital services remains the purview of government professionals.

In contrast, the approach envisioned by proponents to the “build with, not for” philosophy seem more focused on achieving full user-professional coproduction. The techniques being developed for building this kind of civic technology are meant to better ensure the full participation of the communities that will use them. It seems to focus less on consulting the user community and using their input in the design and delivery of services by professionals, and more on empowering users to be an integral part of the civic tech lifecycle.

This is not meant to suggest that one approach is necessarily better than the other (or any other approach that may be used), just that the focus is different. Groups like GDS and 18F are charged with helping government agencies achieve their mandated duty to provide specific services. Civic hacking groups may work on solutions that fall outside the traditional scope of a government agency, or that cross the boundaries of government agencies or different levels of government. This kind of inter-governmental collaboration on specific services may be difficult for governments themselves to achieve, so in this regard civic hacking groups may help fill crucial role in digital service delivery.

Another important observation we may draw out of the existing literature on coproduction that has implications for digital service design is the role of the individual service consumer. A 2013 study by Stephen Osborne and Kirsty Strokosch in the British Journal of Management uses the term “consumer coproduction” to describe the role that an individual consumer may play in the coproduction process:

“The users’ contribution as a co-producer during service production is not only unavoidable but is also crucial to the performance of a service and the impact of the service upon them.”

Brudney and England also make a distinction between individual and collective coproduction, and suggest that the benefit of individual coproduction – the activities of any one person – is minimal:

“…individual coproduction consists of active, voluntary behaviors that citizens undertake for their own consumption. Examples include turning in fire alarms, picking up litter from adjacent streets and informing officials of faulty traffic control equipment. While these activities involve active citizen participation, without organization and coordination, the aggregate benefits to the city are minimal.

I find it interesting to note that this criticism of the role of the individual in the coproduction process does not raise the issue that any one consumer’s viewpoint may not reflect the sentiments, desires or needs of other consumers but rather that the impact of any one individual may be limited in scope. And while this may have indeed been the case when Brudney and England set out to describe coproduction in the early eighties, it is far from the case now.

An individual with the skills and tools to create an app can now have a significant impact on a community or even a city. The internet and the staggering array of tools we now have to cheaply and efficiently construct digital services make it possible for an individual to create an app or online service that unites and coordinates people, and magnifies the impact of individual activity.

In fact, a single individual using an app may have an impact far beyond their own experience – consider services like SeeClickFix or Public Stuff that empower individual users to report issues to their government that may impact an entire neighborhood or community. And while the ability to do this has probably always existed in some form, the level of immediacy and transparency that these apps provide has not been available before and significantly strengthens the impact an individual user may have.

The potential impact of a single civic app developer, or a small group of like minded individuals can be seen in a now retired app that provided transit information for the Philadelphia area. This app was built by a small group of software developers that happened to be commuters using SEPTA’s regional rail service. Dissatisfied with the existing options they had for consuming schedule information, they built their own web-based tool called iSEPTA.

Acting very much in their own self interest, and with little or no engagement of the broader transit rider community, this small group built an app that was eventually used by thousands of transit riders every day, inspired a cottage industry of transit apps in Philadelphia (as well as several transit-focused hackathons), and eventually prodded SEPTA itself to develop better transit apps for its riders.

The motivations of the group behind iSEPTA are shared by many in the civic tech community. In the words of another transit app developer from Philadelphia:

“Like so many urban developers, I just want to provide resources that make my fellow citizens’ lives a little easier. Really, I made it for myself and hope that someone else out there will also find it useful.”

As we become more aware of the benefits of including the community in the development of civic apps, and in surveying a broad range of user perspectives in their design, it’s interesting to note the breadth of the impact a small group of developers – or even a single person, properly motivated and equipped – may have. These are sentiments we want to nurture, and as we embrace a community-driven approach to civic technology, we should keep in mind the power of the individual.

Finally, the academic research on coproduction may help us to better understand the limitations of community-driven civic app development – or, more accurately – may help us avoid repeating the issues that have cropped up over the long history of coproduction.

Osborne and Strokosch take pains to point out some of the limitations of coproduction, and make note of the important role played by service professions:

“Service professionals and planners must trust that they will receive some return from co-production, whilst service users must trust that their contributions will be recognized, valued and acted upon.” [Emphasis added]

It seems to me that this is a particularly relevant point for the civic technology community – as we build civic technology with a focus on users and community, we must be conscious of the fact that government employees are a part of the community and are potential users of civic technology solutions.

Consider the example of another transit app built several years ago by a small team in San Francisco. The app was meant to replace an outdated, labor intensive process used by managers at San Francisco’s Municipal Transportation Agency with real time data on transit asset locations. But months after its creation it was largely unused by the agency because purchasing iPads for managers to use the app was deemed cost prohibitive.

This response from SF Muni to an efforts to replace their outdated process strikes me as a typically bureaucratic response. Throwing up your hands and decrying a lack of funds is a reaction seen often in government – in this case it suggests that a key component of the user community for the app was not included in the process that led to its development. In a way, this underscores everything that the user and community-driven service design approach is meant to help fix.

Research and experience on coproduction suggests, though that part of the community of users for civic technology are governments themselves.

The Future is the User

“We must begin digital projects by exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives.”

— U.S. Digital Services Playbook

The world of civic technology is maturing, and the leaders of the civic tech movement are moving us to a place where the user is at the center of what we build.

Investment in civic technology over the next few years is expected to be significant. This is the right time for us to embrace new ideas that will make our efforts more impactful and more durable. As we develop new ways to bring the user into the process of designing and implementing new digital services, we have opportunities to draw on the experience in other disciplines and enrich our understanding of what works and what doesn’t work.

The decades-long academic and professional history around coproduction offers a unique opportunity to sharpen our understanding of how we can collaborate with users to build valuable services.

There is much we can learn from the past, to help build a better future.