PG&E

Turning wildfire data into a usable map.

I built the React mapping interface, interactive data layers, and address and county lookups, working from the Figma design system.

My role
React Engineer
Period
Dec 2020 — Aug 2021
Project type
Team project

What I built

  1. Interactive mapping

    Built the React application and D3 overlays on ESRI Maps, including county polygons and switchable mitigation layers.

  2. Location lookup and detail

    Built address and county search paths that open the same local risk, history, and mitigation information.

  3. The public-facing interface

    Translated Figma components into Tailwind UI for search, legends, map controls, and county detail, with keyboard and screen-reader support.

Project outcome

Address and county searches lead to one consistent local view of shutoff likelihood, history, and mitigation work.

Try the demo
Illustrative map interface; displayed risk values are sample data.

Start with a place, then reveal the detail

Address and county lookup lead into local risk and mitigation information. The map remains the visual context while the detail view explains the selected location.

Interface preview

PG&E

Recreated wildfire safety map with category controls, county shading, and a legend

Illustrative map interface; displayed risk values are sample data.

Project context

Customers needed location-specific wildfire and power-shutoff information without having to interpret raw geographic data.

Try the demo
How I built it

Project details

Role
React Engineer
Dates
Dec 2020 – Aug 2021
Location
San Francisco, CA
Domain
Consumer / safety transparency

Tools & technologies

React · D3.js · ESRI Maps SDK · Tailwind CSS · Figma

View the public map

Project facts

Utility service area
5.5M — Utility customer base. This is service-area context, not a measured usage figure for the map.
Map stack
React · D3 · ESRI — React for the application shell; D3 driving overlays; ESRI Maps SDK for the basemap, projection and GIS primitives.
Categories
Four — Switchable mitigation overlays: line undergrounding, hazard prevention, outage-size reduction, enhanced detection.
Design handoff
Figma → Tailwind — Design tokens and component variants mapped 1:1 from Figma to code — no intermediate CSS-modules layer.

Interface notes

  • React + D3 over an ESRI Maps SDK base

    County polygons, service-area outlines, high-fire-threat-district overlays and category-switchable project layers all render from a single D3 data layer over the ESRI base.

  • Address → county → detail

    An address resolves to its county and PSPS-likelihood detail; opening a county pulls up completed mitigation work, circuit status and customer impact in plain language.

  • Figma to Tailwind, end to end

    Every panel, popup, legend and modal was styled in Tailwind directly against the Figma handoff — one design system across the whole surface customers see.

A safety tool customers can actually open

Public Safety Power Shutoffs only work as a wildfire-prevention tool if the customers on the receiving end know what's happening, where, and why. The utility had committed publicly to that level of transparency — community-by-community mitigation work, undergrounding plans, sectionalization device installations, the likelihood of a shutoff for any given address — but the existing portal was an aging surface customers had a hard time navigating.

The Community Wildfire Safety Map is the consumer portal that fixed that. A homeowner opens the page, types an address (or picks a county directly), and gets a real answer about their own area before fire season: completed and forecast mitigation work by category, a multi-year PSPS history table, a cities-in-this-county listing, and total mileage of upgrades by type. No phone tree, no PDF download, no “contact your utility representative.”

The PSPS playbook only works if the customers on the other end of it know what's happening, where, and why.— The motivating constraint

Four choices that defined the build

The map is the visible product, but the lookup flows are how customers actually use it, and the design system is what keeps the whole surface coherent across phone, tablet and desktop. Four decisions did the load-bearing work.

React for the shell, D3 for overlays, ESRI for the basemap

Each rendering layer does the work it's best at. ESRI Maps SDK owns the basemap — tiles, projection, GIS primitives, the underlying geographic accuracy. D3 owns everything on top — county polygons, project markers, hazard zones, category-switchable mitigation overlays — because the work there is data-driven (hundreds of features by category, restyling on interaction, animating between states). React owns the surrounding application surface: the controls (search, filters, dropdown), the modal, the routing.

Tradeoff: Three rendering technologies to coordinate (DOM, SVG-via-D3, ESRI canvas). In exchange, each is doing what it's optimized for, and adding an interactive overlay doesn't fight the basemap's rendering.

A single declarative data layer driving every category

County polygons, service-area outlines, high-fire-threat-district overlays, and every category-switchable project layer all read from one D3 data layer. Switching from undergrounding to hazard prevention to outage-size reduction is a single state change — no re-render of the base, no separate render path per category, no copy-pasted overlay logic that drifts over time.

Tradeoff: More upfront data shaping to fit every category into a unified shape. In exchange, adding a new mitigation category later is one declarative entry, not a new render path.

Address and county both converge on the same detail surface

Two lookup paths — type an address, or click a county directly — converge on one detail modal. PSPS likelihood, cities in the county, completed mitigation work, planned upgrades by category and mileage, all sourced from the same data payload regardless of entry point. Customers don't relearn navigation when they switch from address-based to area-based lookup.

Tradeoff: The modal carries more data and has to load gracefully across both entry points. In exchange, the cognitive load on the customer is roughly one menu, not two.

Figma → Tailwind, no intermediate design layer

Every panel, popup, legend, dropdown and the county modal are styled in Tailwind directly against the Figma handoff. Design tokens (colors, spacing, type) translate 1:1; component variants live in code mapped 1:1 to design system entries. No CSS-modules layer in between, no generic component library to bend toward the design — direct translation, design system as the API.

Tradeoff: Tighter coupling between code and the design source. In exchange, design system changes can't silently drift away from what ships — a Figma update is a code update.

The map, the lookups, and the county detail

The map layer is React for the application shell with D3 driving every overlay on top of the ESRI Maps SDK basemap. D3 handles county polygons, service-area outlines, high-fire-threat-district overlays, and the category-switchable mitigation markers (undergrounding, hazard prevention, outage-size reduction, enhanced detection) — all rendering off a single declarative data layer so adding a new category later is a data entry, not a new render path.

The two lookup flows — typing an address, or clicking a county directly — are what turn the visualization into a tool. Both converge on the same detail modal: PSPS likelihood, a multi-year shutoff history table, cities in the county, completed and forecast mitigation work by category, total upgrade mileage by type. Customers don't relearn navigation when they switch from address-based to area-based lookup.

The map controls, the category dropdown with its swatch legend, the popup cards on individual project markers, and the full county detail modal all live in the same Figma design system. I held that line in Tailwind so the surface reads consistently end to end, with WCAG 2.1 keyboard and screen-reader support for the broad public audience the map serves.

Scope

  • React application shell with TypeScript and Tailwind, styled directly against the Figma design system
  • D3 overlay layer rendering county polygons, project markers, hazard zones and category-switchable mitigation overlays
  • ESRI Maps SDK integration for basemap, projection, and underlying GIS primitives
  • Address and county lookup flows; unified detail modal for both entry points
  • Full county detail modal: PSPS history, cities, completed mitigation work, planned upgrades by category and mileage
  • Search panel, category dropdown, legend, popup cards, zoom and find-my-location controls
  • WCAG 2.1 accessibility — keyboard navigation and screen-reader support for the public-information audience the map serves
  • Performance work — lazy-loaded category overlays, controlled re-renders, throttled map interactions