Independent, experimental zoning and property-feasibility product for Montreal.

MapBylaw

AI-Assisted Zoning Exploration

MapBylaw is an independent experiment in making zoning and property-feasibility information easier to explore, with AI recommendations that have to stay grounded in the same verified data as the rest of the product. The work emphasizes navigation, filtering, and an honest recommendation contract rather than claims about complete municipal coverage or planning authority.

Independent / Product experiment
  • AI product UI
  • Typed API contracts
  • Information architecture
  • Filtering UI
  • React-PDF
MapBylaw landing page introducing a zoning and bylaw exploration product experiment.
Landing page. The public entry point positions the work as a clearer way to navigate zoning information, not as an official or exhaustive database.

Context

Zoning information is dense, technical, and easy to present in ways that overwhelm people quickly. The experiment focused on information architecture, progressive disclosure, and a more legible path through property-related questions.

Problem

When bylaw and zoning information is presented as an undifferentiated wall of detail, the product forces users to do too much translation themselves. The interface needed to reduce that friction without implying official completeness or certainty beyond the experiment’s scope.

Diagram

A wall of bylaw detail vs a guided path

Undifferentiated detail

  • Every detail presented at once
  • Users translate bylaw language into answers themselves
  • Organized around raw document structure
  • Reads like an unstructured archive

Task-oriented workflow

  • A map-led overview comes first
  • Filtering narrows to the information a question needs
  • Progressive disclosure moves into lower-level detail later
  • Framed as an experiment, not an official municipal reference
The value of the experiment depends on whether people can navigate the information, not on how much of it fits on one page.

My role

  • Designed the frontend product direction and information architecture for the experiment.
  • Built navigation and filtering patterns aimed at making property workflows easier to follow.
  • Designed the AI recommendation contract and the boundaries on what the model is allowed to claim.
  • Worked across the Fastify API, the React dashboard, and the React-PDF report so all three render the same recommendation payload.

What I built

  • A map-led product surface for browsing property context and zoning-related details.
  • Filtering and progressive-disclosure patterns for moving from overview into more specific information.
  • Workflow framing that treats complex bylaw information as a navigable product problem.
  • A recommendation service with a narrow context builder over verified inputs (zoning, sector, policy flags, feasibility signals, and computed scenarios) and Zod-validated structured output.

Technical decisions

Decision

Focus the product around information architecture and workflow clarity instead of trying to present every possible detail at once.

Why

The value of the experiment depends on whether people can navigate the information, not on how much text can fit on a page.

Trade-off

Reducing surface complexity means some details appear later in the flow rather than immediately.

Result

The product experiment demonstrates a clearer path through complex information without over-claiming completeness.

Decision

Use progressive disclosure and filtering to keep the interface oriented around tasks rather than raw document structure.

Why

Users need a guided path through the material, not only access to the underlying rules.

Trade-off

Task-oriented presentation requires more careful curation of what appears first and what remains secondary.

Result

The interface makes exploration feel more intentional and less like reading an unstructured archive.

Decision

Treat AI recommendations as a typed product service with one contract across the API, the dashboard, and the PDF report, instead of as presentation copy.

Why

Loosely typed recommendations make it hard to prove what the model saw, validate what it returned, or guarantee the dashboard and PDF say the same thing.

Trade-off

A narrow context trades breadth for grounding: recommendations are less expansive, and output that steps outside the schema is rejected rather than cleaned up.

Result

Each recommendation references a computed scenario and the verified inputs it relied on, and the dashboard and PDF render the same payload.

Diagram

From map overview to specific zoning detail

Select a step to see what happens there.

Step 1 of 3

Map overview

Browse property context on a map-led product surface.

Detail appears later in the flow on purpose, so users reach it with enough context to understand it.

UX and detail decisions

  • Framed the work clearly as a product experiment rather than as a definitive municipal reference.
  • Used filtering and disclosure patterns to reduce cognitive load before users reach lower-level detail.
  • Kept the interface oriented around navigation and understanding instead of raw data density.
  • Recommendations show their cited inputs and limitations instead of hiding missing data behind confident-sounding prose.

Interface evidence

MapBylaw dashboard showing map context, property details, and filtered zoning information.
Dashboard. The workflow emphasizes map context, filtering, and progressive disclosure to make dense information easier to follow.

Outcome

  • Created a product experiment that demonstrates information architecture and workflow thinking on a complex domain.
  • Showed how filtering and progressive disclosure can make dense zoning information more approachable.
  • Turned AI recommendations from free-form suggestions into specific, auditable output tied to verified inputs and computed scenarios.

What I would improve

  • Continue exploring clearer task-based entry points for different property questions.
  • Expand the evidence set carefully without implying official coverage or exhaustive zoning accuracy.