CivicPulse: Civic Engagement App Prototype by Spencer GrantCivicPulse: Civic Engagement App Prototype by Spencer Grant

CivicPulse: Civic Engagement App Prototype

Spencer Grant

Spencer Grant

The bill on CivicPulse's Legislation screen is real. "Housing Options and Opportunity Act (25-0066)" comes straight from a Baltimore mayor's-office press release. A civic app that fakes its data teaches people not to trust civic apps, and that's the exact problem it's supposed to solve.

Role
Solo: research, personas, information architecture, hi-fi UI
Click through the full prototype above, or open it in Figma →
30-second summary
City data is technically public but unusable: buried in PDFs, split across departments, written for staff, not residents.
Solo concept work: two personas at opposite ends of civic engagement, grounded in real Baltimore legislation and budget records.
Same information, two depths (skimmable vs. trackable), sourced and never editorializing: earn the trust before asking for it.
Concept only. Not tested with real residents. City-impact case is reasoned, not measured.

The problem

Every city government I looked at technically makes its data public: council votes, budgets, 311 requests. Almost none of it is usable by the person it's supposed to serve. It's buried in PDFs, split across departments that don't talk to each other, and written for city staff, not residents.
One resident said it better than I could: "It's not about information overload. It's about information in the right format." The data existed. The interface to it didn't.

Two Baltimore residents, opposite starting points

Jasmine, the organizer

Runs community programs, already attends council meetings. Needs to track a bill from proposal to outcome without hunting across five city websites.

Jordan, the bystander

Doesn't vote locally, gets his news from Instagram and TikTok. Wants to know what's happening in his district without becoming an activist first.
Same information, two depths: skimmable for Jordan, trackable and shareable for Jasmine. Neither version could be the "real" one with the other bolted on.

Five screens, one thread: earn the trust before you ask for it

CivicPulse Dashboard: starred bills, an upcoming committee meeting, and a local neighborhood initiative
Starts with what a resident already follows, not a firehose of everything happening city-wide. Starred bills, nearby meetings, local initiatives.

Why this would matter to a city

This never shipped to real residents, so there's no participation or trust data to cite. What I can show is which city-level goals each decision was actually built to move, and why.

Lower staff burden, not just resident convenience

Plain-language status next to a sourced link is aimed at the same "where's my money going" question that otherwise lands as a 311 call or a constituent-services email. A resident who can self-serve the answer is a repeat contact a city office doesn't have to staff.

Participation is a funded KPI, not a vibe

Meeting attendance and comment volume are metrics open-government and civic-engagement offices are often literally funded and graded against. One-tap RSVP and a dashboard that starts with what a resident already follows are aimed directly at that number, not engagement in the abstract.

Trust as the thing being sold

Neighborhood-level budget framing maps to the kind of equity mandate a lot of city offices already carry, and "sourced, never editorializing" is what makes a transparency tool usable as evidence in a resident trust survey instead of dismissed as another city PR channel.

What I learned

Civic tech was a harder design problem than I expected, and not for the reason I assumed going in. The hard part wasn't information architecture, it was that almost every interesting decision was also a trust decision. Show a rep's voting record and it can read as a smear. Personalize by neighborhood and it can read as surveillance. The only real response was to be relentlessly neutral: sourced, plainly worded, never editorializing. Trust risk as a design constraint, not an edge case.
The honest limitation: this is unmoderated concept work, not something validated with actual Baltimore residents. The data is real. The reactions to it are still my best guess, not an observation. A concept this dependent on earning trust needs to be tested with the people whose trust it's asking for. That's the next version, not a footnote.
Like this project

Posted Sep 17, 2026

Solo UX concept: turned real Baltimore city data into a transparency app residents can actually use, not just technically public records.