Accuracy isn't enough. A planner has to be able to stand up in a council meeting and explain why. CAN-SIMPLAN is the design that makes that possible. An AI-assisted zoning tool where every output is traceable, every decision is defensible, and the human stays accountable throughout.
Explore interactive prototype
Many tools promise efficiency: summaries, risk flags, recommendations. But when outputs arrive without clear reasoning, they introduce a new risk. In a governance context, a decision must be traceable because it must hold up under questioning.
The model might be accurate but accuracy isn't enough. I need to be able to stand up in a council meeting and explain why.
— Municipal planner, research insightDesign challenge: How might we design an AI planning tool where every output a planner acts on is something they can explain and stand behind?
Early research conversations revealed a consistent pattern: the barrier to AI adoption wasn’t skepticism about model accuracy, it was the inability to explain any individual output to a colleague, a councillor, or a community member asking difficult questions.
The design problem wasn't speed. It was legibility, to keep a human hand visible at every step.
The original framing
How do we speed up the proposal review process with AI?
The reframe
How might we design AI-assisted decisions that a planner can clearly explain, trace, and defend?
CAN-SIMPLAN is designed around one principle: the AI surfaces analysis but the planner makes the call.
Every interface decision was tested against that constraint.
I owned the end-to-end interface, from login through audit trail, as the sole UX designer on a four-day multidisciplinary sprint team.
When a concern is raised, the workflow pauses, and the planner must record a rationale before proceeding. This introduces friction by design because it turns a passive step into an explicit decision. The argument against was based on behavioural reality: optional fields get skipped, especially under time pressure, which is precisely when the rationale matters most. That friction was the point.
Model confidence, version, and timestamp are visible at the top of each proposal. A planner asked to defend a decision needs to know what the system knew, and when. Surfacing that upfront is the difference between a traceable decision and an opaque one.
Each simulation flag includes a plain-language explanation written for planners, not data scientists. The planner’s role is judgment. The interface’s role is translation.
Every action is logged directly within the proposal view rather than hidden in an administrative panel.
A decision-support tool that strengthens a planner’s ability to explain what they decide.
Eight-screen prototype covering the full proposal lifecycle, completed in four days, selected as winning project. The thesis held: in civic AI tools, legibility is a precondition for use, not an enhancement.
The project reinforced a consistent pattern: in civic contexts, adoption depends less on performance than on whether the system can be understood. When reasoning is visible, trust becomes possible.
Test the rationale-recording step at realistic volume. In a sprint prototype, mandatory rationale was evaluated against a single proposal. A planner reviewing twenty proposals in a week may experience it very differently, either as a meaningful pause or as rote overhead. I’d run a longitudinal study before committing mandatory checkpoints everywhere. The design likely needs tiered friction: mandatory for high-concern flags, optional for low.
Involve a planning legal team earlier. The audit trail was designed with legibility for planners in mind. Whether that format satisfies the evidentiary and procedural requirements for an actual appeal or council challenge is a different question, that requires legal review, not just UX testing. In a real development cycle, that input belongs in the design phase, not as a downstream compliance check.