What Barcelona’s Decidim Shows About Digital Participation

A participation platform can make an invitation visible: submit an idea, discuss a proposal, choose a project. The harder question is what connects that invitation to a real public decision.

Barcelona’s use of Decidim offers a concrete way to examine that connection. The platform project’s account of the city’s 2020–2023 participatory budgeting describes proposals moving through submission, technical review, prioritization, selection, and follow-up.

The useful lesson is not that software automatically creates democratic participation. It is that a sequence of public decisions can be supported by a common, inspectable record—provided the institution supplies the rules, resources, and responses.

What the documented case establishes

Decidim’s case study reports a €30 million allocation, 1,982 submitted proposals, 823 technically validated proposals, and 76 selected for implementation. It identifies city residents aged 14 and over as the target public.

Those are the project’s reported figures. They describe the scale and stages of a process; they are not, by themselves, an independent finding that participation was representative or that every selected project achieved its intended benefit.

The distinction matters because public participation has several possible outcomes: people take part, proposals change, institutions explain decisions, money is allocated, and projects are delivered. Evidence about one stage cannot automatically establish the next.

For this article, the first-party account is a basis for analyzing process design. It is not a substitute for an independent evaluation of democratic or social impact.

A platform is a set of components

The Decidim project describes open-source infrastructure for participation and community governance. Its tools include proposals, meetings, discussion, and selection mechanisms.

The significance of that model is that different stages can be represented within a connected environment. A public proposal need not disappear into an unstructured email inbox. Meeting information, explanations, and later updates can be related to the process people joined.

Still, components need configuration. A proposal tool does not determine who is eligible. A voting interface does not determine the available budget. A status label does not establish whether the institution has made a fair decision.

These are choices made through governance and administration. Treating the platform as a finished participation process would hide the work that matters most.

Follow the transition between stages

The Barcelona account describes technical review and public explanations for accepted or rejected proposals. That is an important design feature: the transition can produce a reason, not just a changed status.

For another city considering a similar process, each transition should raise a question.

This table is an editorial framework. It draws out the decisions a team would need to make; it does not claim every implementation of Decidim follows an identical path.

Openness creates opportunities, not guarantees

An open-source license can enable inspection, adaptation, and reuse of software. It does not guarantee that a deployment will be accessible, well maintained, or accountable in practice.

Likewise, public visibility of proposals can improve the record without settling whether the people who contributed reflect the wider community.

Decidim’s Social Contract states commitments concerning transparency, participation, privacy, and other democratic principles. These are useful expectations against which to ask questions about an installation. They should be distinguished from evidence that every deployment realizes those commitments.

Ask who maintains the local system, how decisions about changes are made, and how participants can report a problem. The governance of the software and the governance of the public process are connected, but they are not identical.

Keep the offline work in view

A digital process can be easier for some people and harder for others. Devices, language, confidence, disability, time, and trust all affect who can participate.

The OECD’s participation guidance recommends choosing tools to suit the participation method and considering digital divides. A practical implication is to plan assistance and in-person routes as part of the same process.

When people contribute through different channels, explain how their input enters the common record. Avoid creating an online process with rich status information and an offline process whose submissions become difficult to trace.

Budget for the people who explain the invitation, support participation, review proposals, and answer questions. A software budget alone does not pay for that work.

Ask what an impact claim would require

Suppose a process has many registered users. That tells us something about platform activity. It does not establish how participation was distributed, whether people understood the choice, or what influence they had.

An evaluation could examine who took part and who did not, how proposals changed, how decisions were explained, what was implemented, and how participants experienced the process. The method and available data would determine how confidently those questions could be answered.

Do not combine all of them into a broad claim that a platform “improved democracy” without stating what was observed.

Similarly, a selected project and a completed project are different states. Follow-up needs to preserve that distinction so a reader can see what has actually happened.

What another city can take from the case

Start by defining the decision that residents can influence. Make the constraints and the commitment to respond explicit. Then decide which software components support the process.

Design the public record around transitions: what was proposed, how it was evaluated, why it progressed or stopped, and what happened after selection. Give the operating teams enough capacity to keep that record current.

The case connects the questions in civic tech and GovTech: public influence depends on administrative capability. It also connects to accessible service design, because an invitation is incomplete when people cannot act on it.

Decidim is interesting as infrastructure for that work. Its larger lesson is that the quality of digital participation resides in the relationship between an interface and an institution prepared to keep its commitments.