The Problem With Designing Civic Tech Without Input From Affected Communities

Civic technology is what happens when software, data, and design methods get pointed at public problems: permitting systems, benefits enrollment, participatory budgeting, open data portals, election administration, the digital front doors of government itself. You’ll also hear it called govtech, public interest technology, digital government, or civic innovation. The pitch is that better tools make public institutions more responsive, legible, and fair. But when the people who will live with those tools aren’t in the room when decisions get made, the result is often a new layer of exclusion built on top of an old one. This piece is for practitioners who want to see the failure modes clearly before they reproduce them.

The pattern is familiar to anyone who has watched a well-funded civic tech project collapse into irrelevance or harm. A foundation awards a grant. A vendor or a fellowship team moves quickly. They interview a few agency staff, maybe run a survey, and then ship a product that looks polished in a demo. Eighteen months later, the tool is abandoned, or worse, it is mandatory and actively making life harder for the people it was supposed to serve. The missing variable is not technical skill. It is standing: who had the power to define the problem, who could veto a bad design, and whose knowledge counted as expertise.

The Default Posture of Civic Tech Is Extraction

Most civic technology projects begin with a problem statement written by someone who does not experience the problem. A city department wants to reduce call volume. A state agency wants to cut processing time. A nonprofit wants to demonstrate impact to its funders. The affected community appears later, if at all, as a set of “user needs” to be discovered through interviews or usability testing. That is not participation. That is extraction: taking time, stories, and trust from residents while returning a product they did not ask for and cannot control.

This is not a failure of good intentions. It is a structural feature of how civic tech is funded and staffed. Grants often require a working prototype within a year. Procurement rules favor established vendors over community organizations. Design teams are disproportionately white, college-educated, and disconnected from the neighborhoods where the technology will be deployed. The result is a predictable gap between what the tool assumes about people’s lives and what those lives actually contain.

Consider a benefits application that requires a stable email address, a smartphone, and uninterrupted internet access. For a family moving between shelters, sharing a phone, or relying on a library’s fifteen-minute computer session, that application is not a convenience. It is a barrier with a friendly interface. The designers may have tested it with “users,” but they did not test it with the people most likely to be denied.

What Exclusion Looks Like in Practice

Exclusion in civic tech rarely announces itself. It appears as a series of small, defensible decisions that accumulate into a system that works for some people and quietly fails for others. The following examples are drawn from documented cases and common patterns in public sector technology.

Language as an Afterthought

A city launches a new portal for reporting code violations. The interface is in English. A Spanish-language version is “on the roadmap.” Meanwhile, the neighborhoods with the highest rates of housing complaints are disproportionately Spanish-speaking. The tool does not need to be malicious to be discriminatory. It just needs to treat language access as a feature request instead of a design requirement.

Digital Identity That Assumes a Paper Trail

Many civic tools now require identity verification through credit history, utility bills, or government-issued photo ID. For people who are unhoused, undocumented, recently incarcerated, or fleeing domestic violence, those requirements are not neutral. They are a wall. A well-designed interface cannot fix a verification system that was built around the assumption that everyone has a stable address and a clean administrative record.

Feedback Channels That Go Nowhere

A participatory budgeting platform invites residents to submit ideas. Thousands do. The city selects a handful of projects, and the rest disappear into a database no one reads. The platform has created the appearance of participation without any mechanism for accountability. Residents learn that their input is decorative, and the next time the city asks for feedback, they do not respond. The civic tech tool has actively depleted the trust it claimed to build.

The Power Asymmetry Behind the Design Table

To understand why this keeps happening, it helps to name the asymmetry directly. In a typical civic tech project, there are at least four groups with different kinds of power:

• Funders control the money and the timeline.
• Government staff control access to data, procurement, and the authority to deploy.
• Designers and developers control the technical choices and the definition of “feasible.”
• Affected residents control none of the above, but they bear the consequences.

When the first three groups meet without the fourth, the project is not “user-centered.” It is institution-centered, with a thin layer of user research applied for legitimacy. The people most affected are treated as informants, not as decision-makers. Their knowledge is filtered through the assumptions of people who have never waited in a benefits line or navigated a court website from a phone with a cracked screen.

This asymmetry is not accidental. It mirrors the broader distribution of power in public institutions. Civic tech often inherits the same exclusions it claims to fix because it does not challenge who gets to set the agenda. A tool that makes it easier to report a pothole is not the same as a tool that gives residents control over how street repair funds are allocated. The first is a service improvement. The second is a shift in power. Most civic tech stops at the first.

What Meaningful Community Input Actually Requires

Meaningful input is not a workshop. It is not a focus group. It is not a survey link posted on a city website. Those methods can be useful, but they are not sufficient. Meaningful input requires three things that most civic tech projects are not structured to provide.

1. Decision-Making Authority

Affected residents need the power to say no. If a community advisory group can only offer suggestions that the project team is free to ignore, then the group is not advising. It is legitimizing. Real input means that residents can block a design, redirect a budget line, or kill a project entirely. That is uncomfortable for funders and agencies, which is precisely why it matters.

2. Compensation and Time

Residents are asked to give their time, their stories, and their trust. In most civic tech projects, they are asked to do this for free, while the designers, developers, and consultants are paid. That is not collaboration. It is a subsidy from the community to the project. If input is valuable enough to shape a product, it is valuable enough to pay for. Stipends, childcare, transportation, and scheduling that respects work and family obligations are not extras. They are the baseline.

3. Ongoing Governance, Not One-Time Consultation

A single workshop at the beginning of a project is not community input. It is a checkbox. The people affected by a tool need a role in its governance over time: reviewing changes, monitoring outcomes, and holding the implementing agency accountable. Without that, the tool will drift back toward the priorities of the institution that owns it. Community input is not a phase. It is a relationship.

Case Patterns From the Field

The following patterns are drawn from public reporting and practitioner accounts. They are not isolated incidents. They are recurring structures that show up whenever civic tech is designed at a distance from the people it affects.

The Benefits Portal That Assumed Too Much

Several states have modernized their benefits enrollment systems in recent years. In some cases, the new systems reduced processing times for applicants with stable internet access and strong digital literacy. But for applicants without those advantages, the systems introduced new failure points: session timeouts, document upload requirements, and automated eligibility checks that produced errors requiring in-person appeals. The people who were already most likely to be denied benefits were the ones least able to navigate the new system. The design teams had optimized for the median user, not the marginal one.

The 311 App That Ignored the Actual 311 Calls

Several cities have launched mobile apps for reporting non-emergency issues. The apps are popular with younger, wealthier residents. But the people who call 311 by phone are often older, lower-income, or less comfortable with smartphones. When cities shift resources toward the app and away from phone support, those residents lose access. The app does not replace the phone line. It competes with it. The design decision about where to invest was made by people who use apps, not by people who use phones.

The Open Data Portal That No One Asked For

Open data portals are a staple of civic tech. They publish datasets about budgets, crime, permits, and more. But the portals are often built without asking residents what data they actually need. The result is a repository that serves researchers and journalists but does little for the residents whose lives the data describes. In some cases, the data is published in formats that require technical skill to use, effectively excluding the people who might have the most urgent questions. The portal is a public resource in name, but a specialist resource in practice.

Why “Move Fast and Break Things” Is a Dangerous Frame for Public Systems

The tech industry’s default posture is speed. Ship early, iterate, learn from failure. In a consumer app, a failed feature is an inconvenience. In a public benefits system, a failed feature can mean a missed rent payment, a lost food benefit, or a deportation hearing scheduled for the wrong day. The cost of failure is not distributed equally. It lands on the people with the least margin to absorb it.

This is why the civic tech field needs a different relationship to risk. A resident who depends on a public system cannot opt out of a bad redesign. They cannot choose a competitor. They are a captive user, and that captivity creates an ethical obligation that consumer tech does not have. The people who design public systems are not just building products. They are setting the terms under which people access their rights. That is a governance function, not a design function.

When a civic tech team says it is “iterating quickly,” the question to ask is: Who bears the cost of the iterations? If the answer is the residents, then the speed is not a virtue. It is a transfer of risk from the institution to the community.

What a Different Process Looks Like

The alternative is not to abandon technology. It is to change who controls the process. The following practices are drawn from community organizing, participatory design, and the small number of civic tech projects that have managed to avoid the extractive pattern.

Start With the People Most Likely to Be Excluded

Instead of designing for the median user and then patching for edge cases, start with the people who face the most barriers. If a benefits application works for someone with no stable address, no smartphone, and limited English proficiency, it will work for almost everyone else. This is not a technical trick. It is a political choice about whose experience counts as the baseline.

Pay Community Partners as Co-Designers

Community organizations that already have trust with residents should be funded as full partners, not as outreach subcontractors. They should have a role in defining the problem, shaping the solution, and evaluating the outcome. Their staff should be paid at rates comparable to the designers and developers on the project. If the budget cannot support that, the project is not ready to claim community input.

Build Public Accountability Into the Tool Itself

A civic tech tool should make its own decisions visible. If an algorithm denies a benefit, the applicant should be able to see why. If a participatory budgeting platform filters out certain proposals, the filter should be public. If a city uses data to allocate services, the data and the allocation formula should be open to challenge. Accountability is not a report published after the fact. It is a feature of the system.

Measure What the Community Cares About

Most civic tech projects measure success in terms of adoption, efficiency, or cost savings. Those are institutional metrics. The people affected by the tool may care about different things: whether they were treated with dignity, whether the process was legible, whether they had any recourse when something went wrong. If those outcomes are not measured, they will not be managed. The metrics themselves are a form of power.

The Role of the Practitioner

If you are a designer, developer, product manager, or researcher working in civic tech, you have more power than you may want to admit. You can ask who is not in the room. You can push back on a timeline that skips community review. You can refuse to ship a feature that you know will fail for the people who need it most. You can document the tradeoffs and make them visible to the people who will be affected.

None of this is easy. It will slow projects down. It will create conflict with funders and agency staff. It may cost you a contract or a promotion. But the alternative is to be the person who built the tool that made someone’s life harder. The field is full of those tools. It does not need more.

The question to ask at the start of any civic tech project is not “What can we build?” It is “Who gets to decide what we build, and what happens to the people who are not in the room?” If you cannot answer that question honestly, you are not ready to build anything.

Frequently Asked Questions

Why is community input often treated as optional in civic tech?

Because the people who fund and staff civic tech projects are rarely accountable to the communities they serve. A foundation answers to its board. A vendor answers to its contract. A city agency answers to its leadership. None of those accountability structures require the approval of the residents who will use the tool. Community input becomes optional because no one with power is required to take it seriously.

What is the difference between user research and community input?

User research is a method for understanding how people interact with a product. Community input is a form of shared decision-making. User research can be done to people. Community input requires doing things with people. A project can conduct extensive user research and still exclude the community from every meaningful decision. The two are not interchangeable.

How can a small civic tech team afford to pay community partners?

The same way it affords designers, developers, and project managers: by budgeting for it from the start. If a project cannot pay community partners, it should not claim to be community-centered. The money exists. It is a question of priorities. A project that spends six figures on software but nothing on community compensation has made a choice about whose time is valued.

What should residents do when a civic tech tool is failing them?

Document the failure. Keep records of denied applications, lost documents, and unanswered requests. Bring those records to the agency that runs the tool, to elected officials, and to local journalists. Ask for the data on how the tool is performing for different groups. If the agency will not provide it, that is itself a finding. Public systems are subject to public pressure, but only when the failures are made visible.

Next Steps for This Site

This article is the first in a recurring column on exclusion mechanisms in civic technology. Future pieces will examine specific tools: algorithmic eligibility systems, digital ID programs, participatory budgeting platforms, and the procurement rules that shape them. If you have seen a civic tech project fail the people it was supposed to serve, or if you have worked on one that got it right, I want to hear from you. The field needs more documented cases, not more polished demos.