Crafting Civic Tech:
A Kickstarter Guide for Community Collaboration on Civic Technology
Image remix by Josh Stearns; photo by Erich Stüssi
So you want to start building civic technology with, not for your local community? Excellent. Here in Washington, DC, we feel the very same way.
On Sunday, October 19, 2014, we held a workshop at the DC Day of Civic Hacking to discuss what it means to integrate community perspectives into the creation of civic tech and how, practically, members of our local civic hacking community could get started doing so.
This guide is a translation of the major lessons, notes, and action steps from that workshop, packaged as a 4 part tactical guide. We wanted to share our work, even at this early stage, in the hopes that it could benefit others similarly looking to transition from aspirational to actionable inclusion.
There are many approaches to this work. This guide details just a few. As we implement some of the processes talked about here locally, we hope to expand from this resource to include more references, war stories, case studies, and citations from our experience in DC and from peers elsewhere.
Slightly easier to navigate, downloadable version of this “document” available here.
INDEX:
Part 1: Tinkering for Social Impact
Case Study: Street Bump [Boston, MA]
Part 2: Defining “Community”
Part 3: Intervention Points to Include Communities
Case Study: LargeLots.org [Chicago, IL]
Part 4: Supporting Inclusive Processes
[Part 1]
Tinkering for Social Impact
Photo by Sandra Moscoso Mills
To tinker is human.
Playing with ideas and tools on our own or in whatever size groups we choose, learning how to take things apart and put them back together, to remix and build anew — that particular kind of self-directed discovery and creativity is fundamental to the way we learn both about ourselves and our world. Tinkering builds confidence and knowledge, adds fuel to our creative fires, and provides a strong bond to the people we choose to include in our experimentations. One might even go so far as to say that tinkering is a sacred part of the human experience — an experience that is that too often removed from us (by stress, consumer products, streamlining, professional expectations of perfection, structural privilege, etc. Think of all the reasons why you don’t currently tinker (or why you do/can)).
Right now, in the world of civic technology, we are a-tinkering. This doesn't mean that we’re not building useful tools, but it does mean that what we build is largely for ourselves: Our emphasis on software and APIs above other tools and technologies more represents the skills possessed by the folks involved (and the skills we’re interested in growing and playing with) than, necessarily, the best fit for every societal or governmental problem we’re looking to address.
In part, this is also because of who is defining “the problems”. With our digital toolbox out in front of us, those of us who already identify as civic technologists (or kin to) are surveying our cities, towns, and governments and looking at what we can see that we can help fix with the tools we have. It’s a perspective that is based on our experience — as all human perspectives are. And it is a useful perspective: There are a lot of digital and data-related problems that our work really can help solve, clean up, and otherwise address. But ours is only one of many experiences: If we continue to look at the world (at the public sphere, in particular) from our eyes alone, we’re going to miss a whole heckuvalot of it—including the bits where our tools and skills can be of great use.
It is one thing to tinker.
It’s another thing to craft for social impact.
Example: The City of Boston created a now “infamous” app called Street Bump to detect potholes using smartphone sensors. But not everyone has a smartphone or the capacity to download apps or the digital literacy to use them as intended.
The result? Potholes in wealthier, whiter, younger neighborhoods were detected, directing city services to these more privileged neighborhoods and leaving neighborhoods that were already underserved (especially in terms of their infrastructure upkeep) further disadvantaged.
The City responded to the issue, addressing both where the app was deployed and how to account for inequities in reporting. But the question stands: Who was this app created for? Who was it intended to help?
Was this an experiment in service delivery or was this built as a long-term solution to a social problem? If it was the latter, what do you think about the approach the city took? Was an app the right platform?
Photo by _chrisUK.
To design for the civic sphere is to design for a multitude:
People of different backgrounds, professions, families, cultures, and privileges — people, critical to the social ecosystem that makes up the “civic arena”, whose daily lives and needs you and I straight up can’t imagine. That doesn't mean we can’t help. It just means we need to be mindful of the difference between when we are tinkering (creating for ourselves) and when we are crafting (creating with (and for) ourselves and others).
Yes: some of the most impactful tools and technologies have come from the minds and labs (“garages”) of the few. But just because we can invent civic-feeling stuff on our own for others, should we? The promise many of us come to civic technology with is the promise of democratized problem-solving, of citizen contribution, of participatory, collaborative governance. Sure, we civic technologists are citizens, too…But if we want to build the right tools to help the most people, we can’t trust-fall into our own capacities and knowledge. We have to experiment with ways of crafting civic tools with our communities and the people we want to impact.
How to get started:
There’s a number of ways to create inclusive development practices. This guide will detail a few, including:
- How to create a stakeholder map to help identify who you should be bringing to the table. [Jump to Part 2]
- Where opportunities lie to bring new stakeholders into the tech creation process. [Jump to Part 3]
- How structure existing civic tech community spaces and gatherings to support both the freedom to tinker and the crafting of social impact tools.[Jump to Part 4]
[PART 2]
DEFINING “COMMUNITY”
Messy notes from the DC Day of Civic Hacking workshop.
Quick disclaimer:
This section makes the assumption that you are starting from a base of a pre-existing civic tech social structure (meetup group, organization, hackathon, makerspace, etc) and looking to create substantive in-points for collaboration with other people in a shared geographic or otherwise related area. This is not the only way that communal collaboration on civic technology happens (and not even, necessariliy, the best way), but it is one way—and if you’re interested raising your social impact game, this is where you have to start: identifying the communities, individuals, and networks that are engaged on an issue and meeting those people where they are. Even in situations that start with community leadership, you’ll find that going through some of the community identification process outlined in this section will still be a great asset—a way of gutchecking, expanding, and exploring the sustainability of projects to make sure technical contributions are supportive, not duplicative or out of touch with existing social initiatives.
We’ll explore more examples of how to engage in community-driven processes in follow-up resources, but you can get a taste in the LargeLots.org case study after Part 3 of this guide.
With that out of the way, let’s focus on the task at hand: You want to work on a civic tech or social impact project and you want to do so in a way that’s inclusive of the “community”. To do this, we have to get specific—both about just who the “community” is that we want to involve and what the “issue” is that we’re working on. In fact, in order to do the former, we have to start with the latter.
Step 1 : Define what you’re working on
Later guides will walk through how to do this step with community members (see Ideation in Part 3), but let’s start by assuming you already have some sense of direction or a particular issue in mind that you’d like to affect.
Ask yourself: Is this project really about “education” (or “the local economy” or “public transit” or….) or is the point to impact school selection, high schools, truancy, school lunches? If you’re working on school selection, are you considering how school districts may or may not map to the geographic boundaries of your town/city/county? Public or private schools? Both?
The goal of this exercise is less about hyperspecificity (again, we want to make sure that we give space to others who work on and are deeply involved in the issues we see to give their input), and more about establishing enough context for our work that we can identify who the key players are in the space we’re going to enter (see Step 2). (Start with “education” and you’ll have a pretty overwhelming list, even if the place (city, town, county, etc) is small. Start with “after school programs” and the organizations and key individuals you need to reach out to will become more obvious or at least more easily discoverable.)
Step 2: Identify the people and organizations related to your work
Once you have a sense of direction, whip out a pen and paper (seriously; or, fine, use a doc) and make a list of the people who are connected to that issue. (This list = your stakeholder map.)
The kinds of people and orgs you’re looking to identify are those who…
- have direct lived or work experience on the issue at hand
- have a stake in the outcomes (and process)
- are already working on this issue
- are working on or involved in overlapping or intersecting issues
- will be affected by the work you do
Reflect on these “buckets” to help identify a broad human landscape.
- Individuals (leaders (formal and informal — ever met the “mayor” of your neighborhood?) and future “users” (in the education example, think: parents, students, teachers, administrators…))
- Non-profits/social service organizations (look at both who’s working on issues locally and, if relevant, nationally)
- Government agencies and programs
- Community groups
- Businesses, public/private partnerships (both local and national level that play a role in your local context)
- Other social or economic infrastructure (hospitals, libraries, museums, galleries, clinics, farms, business improvement districts, etc)
Although the goal of Step 1 was to help you focus, the goal of this step is to go broad. You want a long list.
Once you run through the obvious and research (on your own and through outreach) the not-so-obvious, think about what issues the topic you work on intersects with. Sticking with our education example, if you’re working on school lunches, you might want to think about including organizations that work on issues related to homelessness, nutrition, or social work. Nervous about discovering these intersectional players? Ask some of the key players you identified in your review of the categories above to help. As we’ll explore more in Part 3, “participating” in the creation of a tool doesn’t mean everyone helps in the same way or at the same point in the process. Some of the stakeholders you identify might play their biggest role by helping you refine, expand, and/or reduce your list. In fact….
Step 3: Identify preliminary, potential roles that your community will play
Don’t think about this step as assigning permanent roles. You haven’t yet connected with your stakeholders and you need to leave room for them to surprise you or express their own interest in helping out or identifying where they can be of most help. Think instead of this step as helping you to mentally chunk out the ways in which you might work with the (hopefully) diverse list of names you just generated and refining the asks you’ll make of some of them when you do reach out to them.
Think about the ways in which the names you’ve collected might be…
- partners (orgs and individuals that can help boost the signal of your work, get you access to resources and people’s attention through either simple affiliation or activity)
- collaborators (orgs and individuals that will play more active, hands-on roles throughout the development process and after, in evaluation and iteration)
- connectors (orgs and individuals that will help you evaluate your list of stakeholders, bring the right folks to the table, and help spread the work or help you gather resources through communications and outreach at different points in the process)
- testers (orgs and individuals who can guide, gutcheck, prioritize, and help evolve the work)
There are other roles and more specific roles, but again, the point of this framework is just to help you sort your list.
In particular, ask yourself:
Who do I have direct connections to on this list?
Who are the obvious leaders (orgs and individuals)?
Who is it hard for me to see that I might have missed?
Who has influence (power, money, press attention) in this work already—and who doesn't but should?
How diverse is this list? (Think about age, geographic representation, race, gender, class…)
Who can help me bring these people together?
As you might sense, your “connectors” are going to be especially important (particularly at this early stage), so do due diligence in identifying which groups or people are going to be helpful to you in that capacity.
Step 4: What happens next
Outreach. The real work. The good stuff.
Start by reaching out to your connectors. Invite them into your space and gatherings, but also meet them (literally) where they are, too. Assess the project together. We’ll explore in future guides and case studies how to dig into this process further, but to get you thinking, too, hop on down to Part 3.
[PART 3]
Intervention Points to Include Communities
Image by Berkeley Unified School District
All right. You’ve got your stakeholder map: You understand the community you need to work with, the people you have access to and the people you don’t yet, but need to, you’ve started your outreach to them, and you even have some key connectors involved. What now?
The answer will depend on the project—and on the people involved (including you). Not every project will entail the same amount of communal contribution—or even that the roles played by stakeholders will be consistent. But in order to start thinking about crafting tech with community members, you need to be able to see basic opportunities to do so. To this end, here’s a breakdown of four major “intervention points” [Ideation, Design, Development, Iteration] where you can think about communal approaches to technical work, with some ideas to help you get started. (We’ll update this section with more examples, inspiration, case studies, and resources.)
#1 Ideation
Ideation is the world before the problem statement or design prompt. It’s the brainstorming, tinkering, talking, researching, reflecting, and observing stage where opportunities for technical impact are discovered and articulated. Integrating community input in the idea stage can range from including relevant stakeholders in dialogue around a selection of ideas or issues that you've come up with to embedding yourself in stakeholder contexts and doing some active listening. (For example, if you’re interested in working on education issues, you might want to start attending PTA (Parent Teacher Association) meetings.) Ideation can be about drilling into the specifics of a problem (“school lunches”) or wayfinding within a broader issue (“education”). This is the pioneer space of civic tech: where we need to engage with people outside of our own sphere if we hope to create tools that have meaning and social impact. The more we civic technologists can see ourselves not as guides of community ideation, but as listeners, participating in ongoing dialogues(especially in place-based communities) and responding with technical solutions to our communities’ expressed ideas and needs, the better.
#2 Design
When the subject of community collaboration on tech arises, “human- or user-centered design” usually jumps to mind for those familiar with the field. Human-centered design is an approach to engineering products and services that gives attention (and priority) to the needs, wants, and limitations of the people the product is designed for. Often (but not always), this involves some degree of co-creation by these people (AKA “users” or “stakeholders” as defined above) that extends into the long-tail of the tool (which we talk about more in “Iteration” below).
These design principles, when applied correctly with thorough consideration and, again, prioritization of stakeholder input, can be an essential part of crafting tools and projects that not only address community concerns but also best fit the way in which a community thinks, learns, and accesses the world. Luckily, this is also a process with a rich, active field of practice, which means there’s a lot of guidance out there for how to do this right. See, for example, resources like:
- IDEO’s Design Kit
- frog’s presentation: Bringing Users Into Your Process Through Participatory Design
- The Encyclopedia of Human-Computer Interaction, 2nd Edition
- Whitney Hess’s excellent post: The User Is Not Like Me
Human-centered design approaches can be applied even when the tool, product, or service is not software. See, for example, Data Murals, painted representations of information, designed in communal contexts, or the Digital Stewards program, which grows, designs, and maintains community wireless networks.
#3 Development
This is where we technically do the most “community” integration at the moment, in the sense that the majority of the existing civic tech universe is also deeply invested in sharing their code (open source) and data (open data, APIs) and working with peers across the country doing the same. But how could we work with other communities and community members in the development stage? This could range from collaboration with educational programs for coding (opportunities to collaborate with local code schools, youth programs, universities, community colleges…) to co-build civic projects to integrating steps for feedback and testing throughout the development process.
Much of the language up until this point has assumed that you’re building civic software or mobile applications, but think bigger! Co-development of civic “tech” could be the process of training local non-profit workers to clean their tech’s documentation, helping to co-build a mobile computer lab with a library, creating a multi-lingual text (SMS) program and coordinating with local groups for translation, or working with your community to set up a wireless network. “Development” is the stage where you tackle the technical implementation of a project, but the tech involved isn’t confined to what common trends dictate. It should respond to the community’s needs and what you decide, collectively, will have the most impact for the issue at hand.
#4 Iteration
The kitchen sink. This is how a project evolves, integrates, and affects a community. Iteration is shorthand not just for testing and recalibrating a project based on use out in the “real world” (read: the actual context the project was designed for); it’s about the evolution of the project over time, as the issue that inspired it evolves, and as the project integrates into the broader communities it was designed to affect.
Sure, activity in this category could be focus-grouping or a hackathon, but it also could be about community outreach, distribution, training—and evaluation. This is where you can be especially creative in working with stakeholders. Perhaps that education project you were working on was largely designed to serve parents and teachers, but you involve students in a series of gatherings and coworking sessions to evaluate its utility and impact. Or maybe your procurement project (to make it easier for new businesses to do contract with governments) was largely designed with tech companies in mind, but you create the space to collaborate with other local businesses to evaluate the project and find ways in which it can evolve to support a much wider array of new, small and mid-sized entrants into the local economy. Iteration is where we hold ourselves accountable, dream bigger, and define the future.
Community Collaboration in Action: LargeLots.org
In 2011, the City of Chicago convened a new public planning process called Green Healthy Neighborhoods, a program designed to address, among other neighborhood issues, the presence of the 10,000+ city-owned vacant lots. In 2014, Teamwork Englewood, a neighborhood group involved in the planning initiative, reached out to DataMade, a local civic tech company, to help facilitate the implementation of a pilot program (designed with neighborhood input) that would allow residents to participate in the resolution of the vacant properties. The result? LargeLots.org.
The story of LargeLots is the story not just of inclusive civic tech development, but of community-driven tech, with a variety of stakeholders active during each of the four stages outlined above. Below, we've highlighted stories from the IDEATION and ITERATION phase of the project that demonstrate important lessons in collaboration.
IDEATION:
LargeLots was not derived at a civic hack night. It started as part of the city planning process. Green Healthy Neighborhoods approached residents of Englewood neighborhood and asked what should be done to resolve the 2000 city-owned vacant lots in the neighborhood. Neighbors, organized through the Resident Association of Greater Englewood (R.A.G.E.) came up with a plan to allow local property owners to purchase lots for $1 (yup, “one dollar”), which you can check out more about here.
After seeing how wonky and unnecessarily technical (toggling between multiple city and county websites, forms, and PDFs) the implementation would be, another neighborhood group, Teamwork Englewood, decided to reach out to local civic hackers (DataMade) to get help making the process easier for those applying for properties.
Note that the idea for this project was refined by the stakeholders most affected by it and that the role of technology was second, in response to an expressed need. Note too that DataMade was visible enough within the greater Chicago community that it was discoverable by the neighborhood groups who wanted to collaborate. This visibility was due in part to a partnership held between DataMade and a local non-profit with deep neighborhood reach, LISC Chicago, with the explicit mission of bridging social impact tech to existing efforts within Chicago communities.
ITERATION
LargeLots did a lot to help Englewood streamline the process for those seeking to purchase city property, but in so doing, created a lot of backend work for City employees. To resolve this issue, DataMade and Teamwork Englewood worked with the city on a second pilot of the LargeLots program, transitioning the program entirely online.
Spot the potential problem? Not all stakeholders affected by the vacant lot program (or interested in participating in it) have equal access to the Internet. To address this, the DataMade/Teamwork Englewood dream team partnered with Chicago Public Library to work on digital literacy guidance and resources for those without a home computer.
Note that the evolution stage of the project included the proactive collection of more stakeholders (including the City, the Library, and additional input from community members), adjusted its implementation (technical and social) to accommodate multiple dimensions of community need and direction, and saved total digitization until the second pilot. Although waiting to take this project enirely online created more work for the city in the first pilot, more importantly this additional test layer prevented the isolation of other critical community members up front and created space for additional stakeholders (libraries!) to play a critical partner role in the execution. In this way, LargeLots wasn’t just being sensitive to community inclusion, the project itself became a community connector, a reason for diverse actors to collaborate and make social ties. If “social impact” starts anywhere, it starts here: in relationships.
Compare this example to Street Bump. Think about the ways in which the City (and the local civic technologists) played radically different roles in the development of each tool. Think about the platforms chosen, their strengths and weaknesses. How could Street Bump have been handled more like LargeLots? What choices make LargeLots distinct? What other key players can the LargeLots team include to expand and deepen community collaboration in their third pilot? What resources will community members need once they’re participating in the LargeLots program? What stakeholders would need to be involved to provide those resources or services?
For more about LargeLots and the lessons learned, check out Demond Drummer and Derek Eder’s talk at the 2014 Code for America Summit.
Image by Fumi Yamazaki
[PART 4]
Supporting Inclusive Processes
Here’s what we’re thinking in DC: Most of the folks working in our local civic tech context work as volunteers and they work on unpaid time. To get into the habit of making inclusive processes the norm for social impact projects, we need support (from each other and the existing structures that support us) to start implementing differently—social incentives to make sure that we’re putting in the time needed to do this right. In our context, that means help from our local civic hacking meetup (Code for DC), among others.
Although this is not (yet)official Code for DC policy, the pitch that came out of our workshop is the following: Project differentiation along two tracks.
Track #1: Tinkering
Openly declare that the default of our space is tinkering. Ensure and protect that folks can simply come into our space to flex their civic and creative tech muscles. Take the pressure off projects to scale or be new or to be transformative in the world outside. Demonstrate that tinkering has a “safe space” in our community, a valued place — but not the only place.
Track #2: Official Projects
If we want to create social impact technology, even in these volunteer settings, let’s ensure both incentives for inclusion and support for crafting them in an inclusive manner. One way we thought to do this was to reserve the “official” seal of approval from our civic tech meetup for only those projects built through community inclusive processes. To get this approval, we’d implement a lightweight peer review process. Peer review would entail running through a checklist that includes not just technical, but social considerations (drawn from the stakeholder identification process (Part 2) and intervention points (Part 3) identified above, among other considerations) to help a project transition from a tinkering space onto an impact track. (Or to just start fresh on the impact track.) It would also enable social support (buddy system!) within our volunteer context, a way of (1) distributing the load of planning, (2) increasing potential contact with connectors by widening our individual networking capacities, (3) help identify problems or gaps in our approaches early on, and (4) provide structure to hold us accountable to working together with those outside of our home base.
Although we’re outlining this process as one for a meetup, iterations of this idea fully apply to hackathons, data jams, hack nights, makerspaces, and any other environment that serves as a magnet for civic tech creation. (Heck, even though the scale of most of this guide assumes a municipal context, the lessons extend to state and national work, as well.)
Who instigates this process?
In DC, we’re piloting a workstream based on the two track system starting on the project level, taking one initiative focused on affordable housing and moving it through an inclusive process. (This housing project started with community integration at the ideation stage, with a light touch in design and development, but the tech project leads are interested in being more thorough, particularly on the iteration stage, and are working to include more individuals and community organizations in the process.) Which is all to say that there are many actors who can step up to suggest or pilot inclusive processes: Individual project leads as well as (tech) community organizers can be instigators.
So too can funders and other external players (government officials, businesses) who support civic hacking and tech and invest time, interest, or money in its cultivation. Make inclusion a requirement for project funding. Evaluate projects based on their thoughtful, substantive integration of diverse perspectives. Set the default to open (to many voices) and have projects justify when they opt for a closed, non-communal process.
There is an extent to which we go through the processes outlined above already. Some education hackathons do invite teachers, parents, and students or work with intermediaries on project design. But remember: the goal of this exercise isn't only to draw “community” members into our tinkering spaces. It’s to integrate our work, our tech into community contexts—the only social and physical spaces where impact happens—and flip our perspective from (grass)top-down to bottom-up.
It’s 2014. We know we’re capable of the “tech”. Now let’s focus on the “civic”.
Slightly easier to navigate, downloadable version of this “document” available here.
Next up: Hackathon alternatives—a guide to collaborative ideation and meeting folks where they are. Got a case study you’d like to see in this guide or other areas you’d like tactical support on? Email helloATcuriouscitizensDOTcom.
