There's a natural instinct when designing any resident-facing tool: make it easy. Simplify the choices, reduce the friction, get people to the finish line without frustration. That instinct is usually right. It is almost entirely wrong for budget engagement.
When the City of Lawrence, Kansas, built out its budget simulation, residents kept leaving a specific kind of feedback: this was hard. Not hard to use. Hard to decide. City leaders read that as a win. They were right to.
A budget simulation could be built to feel effortless. Big categories, simple sliders, no real consequence tied to any single choice. It would test well. People would finish it quickly and report a pleasant experience.
It would also be nearly useless.
The entire value of asking residents to build a budget themselves comes from the friction of doing it under real constraints. If cutting one thing doesn't cost anything, if increasing another thing doesn't require a tradeoff somewhere else, residents aren't experiencing anything close to what governing actually requires. They're playing a game with no stakes, and the input that comes back reflects that. Everything looks like a priority when nothing has a cost.
Lawrence built its process around the opposite idea. The city's team, led by community engagement champion Hannah Ballard, described the budget as one of the city's most important deliverables and also one of its most complex. Rather than smoothing that complexity away, Lawrence built service-level rubrics that translated budget line items into plain-language descriptions of what a given service level actually meant, from a baseline "Service Level 1" up through a fully staffed "Service Level 5." A resident adjusting the Fire Medical Department's budget wasn't just moving a number. They were choosing between staffing levels, and seeing exactly what that choice meant for the service they'd receive.
That took real effort to build. Ballard noted that creating the rubrics required extensive cross-departmental collaboration and a real push to translate technical language into something the public could actually use. It would have been far easier to skip that step and let residents adjust abstract dollar figures instead. Lawrence chose the harder path because the easier one wouldn't have produced input anyone could trust.
Polco's Budget Simulation is structured intentionally around three objectives, and none of them are about making things easy. The first is Learn and Explore: giving residents real clarity on how public funds get allocated, and making visible just how interconnected budget categories actually are. Cutting one line often means straining another, and residents need to see that connection before they can make an informed choice about it.
The second objective is where the real friction lives: Make the Tough Choices. This is where residents experience, often for the first time, what it actually feels like to fund a new priority while protecting essential services, in real time, with immediate visible impact. There's no way to soften this step without hollowing out the exercise. The difficulty is the mechanism, not a side effect of it.
That difficulty is exactly what separates a budget simulation from a satisfaction survey. A survey asks residents what they'd like. A simulation asks residents what they're willing to give up to get it. Those are fundamentally different questions, and only one of them produces information a finance director can actually use.
Lawrence's results bore this out. Nearly 300 residents worked through the full simulation, wrestling with real constraints across public safety, infrastructure, and social services. The results showed a clear community priority: more investment in affordable housing and programs for unhoused individuals, even at the expense of funding elsewhere. Because that input came from people who had worked through the actual tradeoffs rather than just stating a preference in the abstract, the city commission could act on it with real confidence. Lawrence allocated funding to a new homeless programs department and adjusted other budget areas accordingly, a decision informed by residents who understood exactly what it cost.
Ballard summed up the shift plainly: there are tradeoffs in every budgetary decision a city makes, and balancing a budget is genuinely tough work. Giving residents a shortcut around that difficulty wouldn't have made the process more inclusive. It would have made the results less trustworthy.
There's a temptation, especially for governments new to this kind of engagement, to build the friendliest possible version of a budget tool. Fewer categories, softer language, choices with minimal consequence. It's an understandable instinct. Nobody wants to frustrate the residents they're trying to engage.
But comfort and credibility pull in opposite directions here. The version of a budget simulation that feels easiest to residents is usually the version that produces the least useful data. The version that makes people say "this was really hard" is the version where they actually grappled with the same constraints staff and elected officials grapple with every year, which means their input reflects something real.
Lawrence's experience points to a broader principle worth applying to any resident engagement effort: don't design out the hard parts. Design so residents can handle them. Plain-language rubrics, clear visual feedback, real-time impact indicators, these are the tools that make difficulty navigable without making it disappear. The goal was never to make the budget feel simple. It was to make a genuinely complex process something residents could engage with honestly.
Request a Demo or Try Polco Free to see how Budget Simulation turns complexity into understanding instead of smoothing it away.