Company
Pano AI
Role
Lead Product Designer
The team
1 TPM, 2 PMs, 1 designer, 8 engineers, 1 QA engineer
Timeline
Phase 1: May–June 2026
Phase 2: August 2026
Phase 3: September 2026 – present
Context
Pano’s mission is to provide actionable intelligence for climate disasters. Today that means wildfires: Pano’s cameras use AI to spot smoke and alert customers, often while a fire is still small. Historically, Pano has served a variety of customers, including fire agencies, forestry teams, private landowners, and utilities, and each group needs very different things. Instead of making one product fit everyone, we built a new platform just for utilities. I led design on it, from early concepts through the MVP.
Why utilities
Power lines don’t start most wildfires, but when they do, they’re often the worst ones. They caused at least 8 of the 20 most destructive fires in California’s history. Sixteen states have now passed wildfire laws for utilities, half of them for the first time in 2025. Utilities are spending billions in response.
Our challenge
Today, Pano focuses on detection. We alert customers to new fires and give them what they need to confirm them, like live camera views and map data. We challenged ourselves to imagine what it would look like to serve utilities across all of their wildfire work, before, during, and after a fire.
PHASE 1
From Three Big Bets to One
From initial research, we identified three big bets we thought would resonate with utilities. I designed first concepts for each one and shared them in person with two customers who’d agreed to be co-design partners. One had a mature wildfire program and the other was still building theirs. Onsite, I walked execs, wildfire directors, and operators through the designs and iterated on them on the spot as they gave feedback.
Since the designs were going straight to customers, I skipped wireframes and went to high fidelity in Figma. With no PM yet, I turned each user need from the research into a hypothesis to test.
Executive dashboard
Utility leaders need a quick read on what’s happening across all their work, without digging through each of their team’s tools.
Hypothesis: If leaders can see fire risk, weather, outages, and threatening fires in one live view, they won’t need to interrupt their team during a response to ask for updates.
What we learned: Executives agreed it was a gap, but they were lukewarm on it, since calling their team for updates already works for them.
Executive Dashboard Designs
PSPS decision support
A Public Safety Power Shutoff (PSPS) is when a utility turns off power ahead of dangerous weather, like strong winds in dry conditions, so its lines can’t spark a fire. It’s a hard, costly, and unpopular call, since thousands of people, including hospitals, can lose power. Utilities need help deciding when to do it and which lines to shut off.
Hypothesis: Bringing faults, lightning, camera views, circuit risk, and the impact of each possible shutoff into one place will help operators decide when and where to cut power.
What we learned: PSPS decision support would be used by meteorologists, a new user group we don’t have traction with yet. We decided to hold off and package it later with another new product for them.
PSPS Decision Support Designs
Incident management
When a fire is detected, the utility needs to know how big it is, how fast it’s moving, whether its assets could be affected, and whether its assets might have caused it. Then they decide whether to send crews or cut power. Today a lot of teams track this in spreadsheets and group texts, so a new fire can slip through the cracks. Utilities call each fire they track an incident.
Hypothesis: Showing every fire’s stage and owner in one view, next to cameras, maps, and nearby assets, will help teams triage new fires faster.
What we learned: This was the piece customers were most excited about. It’s where they felt the most pain, and other detection tools don’t offer it.
Incident Management Designs
Based on the feedback, we narrowed in on incident management to start.
PHASE 2
Focusing on Incident Management
Next, I went deeper on incident management to understand how each utility actually responds to a fire. I mapped their response stage by stage, then designed a more detailed future version to test with customers.
Mapping each utility’s response
To make sense of the research, I mapped each utility’s wildfire response stage by stage, showing who steps in at each point and what they’re responsible for.
Who we designed for
• Wildfire operators need to quickly figure out whether a new fire matters, then triage it into the right next step: monitoring it passively, watching it closely, or escalating it
• Wildfire response directors need a high-level overview of every fire, and need to make sure every new fire has someone triaging it
From our research, three key user needs shaped the design: seeing the overall picture, making sure someone is handling every new fire, and knowing whether a fire matters.
01. What’s the overall picture?
Directors told us they need a high-level view of every open fire. I designed three views of the same fires, because each one answers a different question.
• Map: shows where every fire is, with the geography around it
• Board: shows where each fire is in the team’s workflow, with a camera preview on each card. Best for most teams, who have fewer than 20 open fires a day
• Table: shows the same workflow, but is easier to scan at volume. Best for big territories with 100+ open fires a day, where a board gets hard to read
All three views are organized by stages that match how each team already works. Teams investigate a new fire to see whether it could affect their assets, monitor it, then close it once they’re no longer concerned. Each customer names these stages a little differently, so I let customers rename stages and add their own.
Incident Triaging Designs
02. Is someone handling it?
Utilities need an operator to triage every new fire, to figure out how serious it is and take the right next step. Some utilities have one person on call with a backup, and others assign an operator to each region.
I designed the experience so people claim a fire from whatever view they’re in. On the board, new alerts sit in the first column. Regional operators can filter the board or table to their area. On the map, new fires pulse, and operators can assign one to themselves with a click.
Incident Map Designs
03. Does this fire matter?
Once an operator claims a fire, they have to decide whether it could affect their assets, which determines what actions the utility takes. Today, they piece that together from more than seven tools, like cameras, maps, weather, and their own asset records. When an executive calls with a question, the answer is often “I’ll have to call you back.” Operators need one place to understand a fire and see whether it could reach their assets.
One customer asked for a severity score, but what they really needed to know was whether a fire could affect them, so I designed threat levels based on how close a fire is to their assets.
Incident Page
Feedback
When we shared the Phase 2 prototype, one customer said it was exactly what they wanted. But it was still a prototype, and we needed to build it.
PHASE 3
Building the MVP
Instead of waiting to ship everything at once, we’re releasing incident management in small pieces. We started with triaging, since every customer brought it up and no competitor supports it, then moved on to the incident page. Each piece goes out in beta, so customers can use it on real fires right away and tell us what isn’t working.
The board view of incidents
We decided to start with the board view, because it’s the view the February design partner prefers. They also have fewer than 14 open incidents at a time, which is the volume a board handles well. We may add the table view later for customers with bigger territories, depending on interest. For this first release, I scoped the Phase 2 design down to what a team needs to triage a new fire: seeing a new alert come in, claiming it, and moving it through their stages. Threat levels, richer card data, and search come in later releases.
Designing the incident page
After the board, I designed the incident page, where an operator goes to work a single fire. For the MVP, I focused the page on assessing risk: understanding the fire and whether it could affect the utility’s assets.
We knew the incident page would eventually hold a lot of data, so it was important to start with an overview that highlights the key information first. A key design principle I set for the page was progressive disclosure. Operators get the key details at a glance and can then dig into more, like other nearby cameras, the full map with all of its layers, or more asset information. As we add more data, the extra detail can go into new tabs without crowding the overview.
PHASE 3
Design System and Handoff
A design system for the new platform
While designing the MVP, I also designed a new design system for the platform. I defined and implemented the foundational tokens and documented them in Storybook. More on this in my design systems case study.
Handoff formats
To help engineers build exactly what I designed, I handed off the design in the formats they already use, plus a few new ones I was trying out:
• Interactive prototype
• Draft pull request with the prototype code
• Developer mode inside the prototype, where clicking a component shows its specs, with markdown engineers can copy into their AI coding tools to check they’ve covered every state
• Handoff canvas with the flows and annotations
• A control bar in the prototype that switches between versions and data states, like how many stations or assets a fire has, so engineers can see every state
Testing the handoff by building it
To test the new developer handoff tooling, I coded the card styling myself from the developer mode specs and added each card state to Storybook. Writing the code showed me where the specs fell short, like values that didn’t use our theme and icons from the wrong library. I updated the developed tooling, then turned the setup into a skill so any designer can add developer mode to their own prototypes.
Measuring Success
The MVP is still being built, so these are the metrics we plan to track once customers are using it. The first big signal comes in February, when our design partner decides between us and the competitor.
Customer sentiment
• Feedback from our design partners
Supporting metrics
• Time to assign an owner to a new fire
• Weekly active users on the customer’s wildfire team
• Incidents closed vs. left to go stale
Business outcomes
• Customers retire their tracking spreadsheets
• Customers use fewer tools per incident
What's Next
In parallel, I roughly designed what each experience could look like in the future. This helped make sure the MVP could scale and got the team aligned on a north star to build toward.
On the incident management board, next up is richer data on each card, plus sorting and search.
On the incident page, we’ll be adding more data and a rules engine, so actions can be triggered automatically based on a fire’s threat level.
Learnings and Reflections
I loved co-designing with customers
This was our first new product line built with customers as real partners. As a designer, I don’t always get to talk to customers directly, so visiting them in person, showing them designs live, and going back with new versions was really rewarding.
Ask customers to show us, not just tell us
Some of our biggest insights didn’t come from conversations. They came from customers walking us through the worksheets and older tools they use every day.
Utilities don’t always know what they own
One customer told us they’d just found out a power line belonged to them. It makes sense once you know that most US power lines were built in the 1960s and ’70s, and many records started as paper maps that were never fully updated. To fight wildfires well, utilities need to know more about their own grid: what they own, where it is, and what condition it’s in.