Back

Capstone · 2026 · Product Design

Redesigning civic information as a decision-support system

Hero Image — Capstone
Role Lead Designer
Timeline Jan – May 2026
Team 4 students
Skills Product Design
User Research
Systems Framing
Design Strategy

This case study is in progress.

My senior capstone is a year-long product design project in partnership with a city agency. The full documentation — research, system model, design outcomes — will be published here upon completion in May 2026. Below is an early snapshot of the problem framing, research direction, and design principles that are guiding the work.

System at a glance

Inputs

Resident intent (permits, benefits, services, programs), literacy level, language, device type

Intelligence

Information architecture organized around resident mental models — not agency org charts — with plain language and proactive status communication

Outputs

The right information, at the right moment, in plain language — surfaced before residents need to ask

Feedback loop

Search queries, task abandonment, and community navigator flags surface gaps in the information system for continuous improvement

Capstone — coming May 2026

Civic information is organized for agencies, not for residents.

Local government information is fragmented across dozens of websites, PDFs, and phone trees — organized by department structure, not by resident need. A person trying to navigate a permit, a benefit, or a community program has to understand how the city is organized before they can find what they're looking for. For residents with lower digital literacy, non-English speakers, or elderly populations, the system is effectively inaccessible — not by design, but by default.

Who's affected

Residents navigating permits, benefits, services, and programs — with higher impact on those with lower digital literacy, non-English speakers, and elderly populations

The structural problem

Information is organized around agency structure, not resident mental models — creating a translation burden that falls entirely on the resident

The design opportunity

A resident-facing system organized around "what do I need to do?" rather than "which department owns this?" — with proactive status communication baked in

Residents trust people over pages. That's not a workaround — that's a signal.

We conducted 14 contextual interviews with residents across three city neighborhoods, focused on recent moments when they had to navigate a city service. We also audited 47 city-facing web pages for readability, navigation structure, and mobile accessibility.

Research — interview synthesis map

Key insight: the informal network is the real infrastructure

Every interview participant described going to a neighbor, a community organizer, or a family member before attempting a city website. The informal network was faster, more reliable, and in plain language. This wasn't a failure of digital literacy — it was a rational response to a system that consistently failed them. Our design direction had to earn trust the way community members do.

Key insight: the problem is architecture, not content

The information residents need exists. It's just buried, inconsistently formatted, and organized for administrators, not people. The design challenge isn't creating new content — it's restructuring how existing information is surfaced, and to whom, and when.

Design for trust before usability.

Our working hypothesis: no amount of IA improvement will solve the problem if residents don't trust the source. The challenge isn't making the website "easier to use" — it's making it legible, accountable, and proactive in the way community members are. Plain language, visible accountability, and anticipatory communication are the design primitives. Usability follows from trust, not the other way around.

Design principles — trust framework

Where we are now.

We've completed research synthesis and defined three design directions, currently in low-fi testing with community members biweekly. We're also navigating the realities of institutional partnership: stakeholder constraints, political sensitivities, and the gap between what agency representatives say they want and what residents actually need. That gap is its own design problem.

In progress.

The most unexpected learning so far: the hardest design problems in civic technology aren't technical — they're relational and political. Designing for a community partner requires holding the user's needs alongside institutional constraints that are real and sometimes immovable. That navigation is as much a design skill as wireframing.

Full reflection and outcomes coming May 2026, once we've shipped and measured impact with the community partner.