Munich Budget (Hackathon)
Participatory budgeting for Munich — researched, designed, and prototyped in 48 hours.
Client
City of Munich
Role
UX Designer, Prototype
Duration
48h Hackathon
Industry
Civic / Government
Client
City of Munich
Role
UX Designer, Prototype
Duration
48h Hackathon
Industry
Civic / Government
Stack
A civic UX project built at a 2-day hackathon — but grounded in six weeks of prior research. München Budget is a mobile app that lets Munich residents discover, evaluate, and vote on local projects in their neighborhood. Full double diamond process: stakeholder mapping, user interviews, affinity mapping, Ist and Soll user journeys. Then 48 hours to ship.
The Challenge
Munich has a participatory budgeting process. Citizens can propose and vote on local projects. The problem: the existing system was buried in city websites, hard to use, and completely disconnected from the neighborhoods it was meant to serve. Most residents did not know it existed. The city had no reliable way to reach people who were not already civically engaged.
Research
We mapped four distinct user groups: students, retirees, parents, and city administration staff. Each had different motivations, different barriers, and different relationships with local government. The stakeholder landscape was more complex than expected: Bezirksausschüsse, Stadtrat, IT department, press, and social institutions all play a role. The consistent finding across all groups: people want to participate. The system just never makes it easy.
Synthesis
Affinity mapping across Needs, Pains, Gains, and Activities produced one dominant insight: citizens do not distrust the city. They simply never hear about the chances to engage. Bureaucratic touchpoints, scattered information, and zero feedback loops had eroded the habit of participation. The question that focused everything: how might we design a participatory budget at the neighborhood level that makes co-determination easy and motivating for Munich residents?
Design Question
That question became the frame for every decision that followed. Not "what features should the app have" but "what would make a busy Munich resident actually stop, open the app, and vote." The answer pointed to three things: hyperlocal relevance (your Stadtteil, your projects), radical simplicity (three taps to vote), and visible impact (progress bars, live vote counts, a confirmation that feels like it means something).
User Flows
The Ist-Journey showed friction at every step: scattered websites, unclear contacts, bureaucratic forms, and no feedback after submission. The Soll-Journey mapped the redesigned path. Register once. See projects near you. Read what they cost and how long they take. Vote. See your choices confirmed. Watch the results unfold. Each stage designed to close the gap between intention and action.
The Prototype
Two days. One core flow. We built the full voting loop in Figma: splash screen, home with active voting phase, map and list of nearby projects, project detail with budget and timeline, vote summary, and the confirmation screen. Every decision reinforced a single feeling: your vote is real, and you can see where it goes.
The Challenge
Munich has a participatory budgeting process. Citizens can propose and vote on local projects. The problem: the existing system was buried in city websites, hard to use, and completely disconnected from the neighborhoods it was meant to serve. Most residents did not know it existed. The city had no reliable way to reach people who were not already civically engaged.
Research
We mapped four distinct user groups: students, retirees, parents, and city administration staff. Each had different motivations, different barriers, and different relationships with local government. The stakeholder landscape was more complex than expected: Bezirksausschüsse, Stadtrat, IT department, press, and social institutions all play a role. The consistent finding across all groups: people want to participate. The system just never makes it easy.
Synthesis
Affinity mapping across Needs, Pains, Gains, and Activities produced one dominant insight: citizens do not distrust the city. They simply never hear about the chances to engage. Bureaucratic touchpoints, scattered information, and zero feedback loops had eroded the habit of participation. The question that focused everything: how might we design a participatory budget at the neighborhood level that makes co-determination easy and motivating for Munich residents?
Design Question
That question became the frame for every decision that followed. Not "what features should the app have" but "what would make a busy Munich resident actually stop, open the app, and vote." The answer pointed to three things: hyperlocal relevance (your Stadtteil, your projects), radical simplicity (three taps to vote), and visible impact (progress bars, live vote counts, a confirmation that feels like it means something).
User Flows
The Ist-Journey showed friction at every step: scattered websites, unclear contacts, bureaucratic forms, and no feedback after submission. The Soll-Journey mapped the redesigned path. Register once. See projects near you. Read what they cost and how long they take. Vote. See your choices confirmed. Watch the results unfold. Each stage designed to close the gap between intention and action.
The Prototype
Two days. One core flow. We built the full voting loop in Figma: splash screen, home with active voting phase, map and list of nearby projects, project detail with budget and timeline, vote summary, and the confirmation screen. Every decision reinforced a single feeling: your vote is real, and you can see where it goes.
THE PROTOTYPE
Next project →
Competitive Intelligence AI