Making civic reporting outcomes visible — even when no action is taken
Making civic reporting outcomes visible — even when no action is taken.
Role: UX & Interaction Design
Scope: Interaction architecture & prototyping
Focus: Accountability-driven civic systems
Basis: Personal observation of a local civic reporting platform
From reporting to visible outcomes — including when no action is taken.
Problem
Civic reporting systems enable issue reporting, but fail to show what happens after submission.
Civic reporting systems enable issue reporting, but fail to show what happens after submission.
Lack of visibility
Reports can disappear without clear feedback or visible resolution.
Lack of visibility
Reports can disappear without clear feedback.
Unclear responsibility
It can be unclear who is responsible or whether any action is taken.
Unclear responsibility
It can be unclear who is responsible.
Eroded trust
This can create uncertainty and weaken trust in the reporting process.
Eroded trust
Uncertainty can weaken trust in the process.
Core insight
The problem is not reporting — it's the lack of visible outcomes.
Core insight
The problem is not reporting — it's the lack of visible outcomes.
Design Approach
Prioritizing location in reporting
The experience prioritizes location first, anchoring reports in a real-world context from the start. Instead of forcing users to scroll through complex category menus upfront, starting with a map aligns directly with how citizens naturally perceive local issues.
Prioritizing location
Anchors reports in the real world immediately, avoiding complex category menus upfront.
Making responsibility explicit
The system shows which department reviewed the report, what happened next, and why, reducing ambiguity around ownership and outcomes. Rather than relying on generic "In Progress" or "Pending" tags, naming the specific department builds genuine accountability.
Making responsibility explicit
Shows exactly who reviewed the report and why, replacing ambiguous statuses with clear accountability.
Shifting from reporting to outcomes
The experience emphasizes status updates and outcomes, shifting the focus from submission to resolution. Rather than making the number of submitted reports the primary measure of activity, I chose to foreground report status and outcomes, helping users understand what happened to their individual report.
Shifting from reporting to outcomes
Focuses on resolution and status updates, rather than just the volume of submissions.
Designing for “no action” cases
Unresolved cases remain visible to support transparency and trust. I consciously chose not to quietly archive or hide rejected reports to make the platform look "cleaner," as doing so would break user trust and obscure the reality of municipal limitations.
Designing for “no action” cases
Unresolved cases remain visible. Archiving them might create a "cleaner" UI, but keeping them public builds trust and reflects reality.
Validation
This was a self-initiated concept based on personal observation rather than formal user research or usability testing. The proposed flows and design decisions therefore represent hypotheses that would require validation with users and municipal stakeholders.
This was a self-initiated concept based on personal observation rather than formal user research or usability testing. The proposed flows and design decisions therefore represent hypotheses that would require validation with users and municipal stakeholders.
Solution
A transparent tracking system
The proposed solution keeps reports visible after submission, with clear status updates and final outcomes.
A transparent tracking system
The proposed solution keeps reports visible after submission, with clear status updates and final outcomes.
Outcomes remain visible even when no action is taken. Reports can be opened to see who reviewed them, what happened, and why.
Outcomes remain visible even when no action is taken. Reports can be opened to see who reviewed them, what happened, and why.
Role: UX & Interaction Design
Scope: Interaction architecture & prototyping
Basis: Personal observation of a local civic reporting platform
How reporting works
01 — Select location
Anchors the report in reality before asking for complex details
Anchors the report in reality before asking for complex details
02 — Choose category
Kept secondary to location to match the citizen's mental model
Kept secondary to location to match the citizen's mental model
03 — Descibe issue
03 — Describe issue
Frictionless input focused on essential context only
Frictionless input focused on essential context only
04 — Review & submit
Prevents erroneous submissions through a clear final check
Prevents erroneous submissions through a clear final check
05 — Track report status
Replaces the typical "black box" processing with explicit next steps
Replaces the typical "black box" processing with explicit next steps
Design Outcomes
Help users understand what happens after submission
Reduce uncertainty through clear status updates
Keep reports visible even when no action is taken
Make reports feel acknowledged and processed
Users understand what happens after submission.
Reduce uncertainty through clear status updates.
Keep reports visible even when no action is taken.
Make reports feel acknowledged and processed.