EverBright | solar financing platform
Usage Phase
Turning a React conversion into a guardrail for honest solar savings
My role
Design lead (sole designer)
Timeline
Q4 2024 to Q3 2025
Team
1 PM, engineering team, 1 design reviewer
Skills
Product design, systems thinking, stakeholder management
55% → 34%
Utility-bill rejection rate across the platform. I designed the Usage Phase rebuild and the guardrails behind this cross-functional drop.
2 days
Turnaround on an urgent California regulatory change, once the phase was rebuilt in React. Before, this would have been a slow, cumbersome fix.
4
Ways reps could previously inflate a homeowner’s savings, closed: projected usage, editable time-of-use, uncapped usage, and unverified rates.
01 — The stakes
A 25-year promise, entered on aging code
Financed solar is a 25-year commitment. The Usage Phase is where a sales rep enters the homeowner’s utility data: provider, rate schedule, usage, and cost. Every savings projection is built on top of it—if it's wrong, the savings that the homeowner signed up for never arrive.
In April 2025, EverBright switched on stricter utility-bill verification to protect homeowners and reduce legal exposure. Overnight, rejected submissions jumped from 16% to 68%. The Usage Phase sat at the center of the problem, and it was running on aging, half-migrated code where every fix was slow and risky.
Utility-bill rejection rate through 2025
Verification launched in April 2025 and rejections spiked overnight. Training, policy, and my rebuild brought them back down to 34%.
16%
Before verification
68%
Verification launches
55%
Training + policy
34%
Rebuild + guardrails
02 — Role and problem
The scope was narrow on purpose
My brief was deliberately tight: convert the Usage Phase to React, bring it onto our design system, and layer in targeted UX wins (aka, not a full redesign). A previous partial migration had been done with no design involvement, and it showed.
The interesting problem wasn't the conversion itself; rather, it was doing it in a way that actually moved the rejection numbers without blowing past the scope everyone had agreed to. That tension between quick tactical wins and long-term flexibility, all inside a fixed timeline, shaped the decisions that followed.
How might we
…turn a technical conversion into something that actually reduces rejections and protects homeowners, without expanding into a full redesign?
03 — Process
Process
1
Started from research, not a blank canvas
Months earlier I had run field research with sales reps. One Usage Phase-related insight informed this project: reps bend usage data to tell the savings story they think homeowners want to hear. The Usage Phase wasn’t just a series of routine inputs; it was where savings accuracy either held or slipped.
Insight: Sales reps often manipulate usage data to tell the homeowner what they view as a more accurate story. Since savings is a projection, they believe that they need to project the utility data as well.
2
Audited every component, then filled the gaps
I catalogued each legacy component that needed converting and found the gaps in our design system where new components were needed. I partnered with the design-system team to build what was missing.
Before: legacy CSV upload
After: redesigned Document Upload
3
Designed guardrails: easy to be honest, hard to inflate
This is the part that mattered most. With product, engineering, and risk, I reshaped the inputs so the honest number was the easy one to enter and inflating it took real effort. Small changes to a form, but they decide whether a homeowner’s promised savings actually show up.
Made the honest path easy
What I added
Historical usage inputs above the chart
Type-ahead rate-schedule search
Usage and cost split into two charts
Assistance programs (CARE, FERA, etc.) surfaced, improving savings accuracy by ~40%
Made inflation hard
What I locked down
Annual-usage cap (~3x typical)
Removed editable time-of-use profiles
Removed the projected-usage feature
Locked California rate selection to verified defaults
4
Turned a surprise regulation around in two days
A California regulatory change landed with no warning: projects now had to include twelve months of verified interval usage data to proceed, with a documented reason whenever it was missing. On the old stack this would have been a slow, risky fix. On the clean React base, I built the compliance flow, surfacing the new requirement and handling the missing-data cases, and we shipped a compliant version in about two days.
The rebuilt California compliance flow
5
Held quality together through a mid-project re-org
A re-org broke our review rhythm and PRs piled up across several developers. I built a bug and UI-fix tracking table to stay organized across the team, ran reviews under a compressed timeline, and worked with product and engineering to triage what shipped. Afterward I facilitated a retro to bank the lessons.
04 — Outcome
What changed
The rebuild did its quiet job: cleaner data going in, fewer rejections coming out, and a system flexible enough to absorb whatever regulation or market threw at it next.
55% → 34%
Utility-bill rejections, as unnecessary inputs came out and accuracy improved. A cross-functional effort I designed key pieces of.
2 days
To ship an urgent CA regulatory change, versus a slow fix on the old stack.
Zero
Legacy Angular / Semantic UI left in the phase. The unified React + design-system base makes future changes fast and safe.
Strategic context: this was one prioritized initiative in a research-driven, multi-year sales-platform strategy. My guardrails were the data-integrity piece; a partner team tackled the homeowner’s proposal experience. Both traced back to the same field research. I also laid the groundwork for tracking second systems (solar added to homes that already have it, around 40% of California deals), ready for when the business prioritizes it.
05 — Key takeaways
Key takeaways
When a team changes, re-establish how you’ll work together
Before the re-org, devs checked in often and I ran reviews along the way. After, that cadence didn’t carry over and reviews slid to right before launch, where easy fixes got dropped as “low impact.” Next time a team shifts, I would re-establish the review rhythm upfront.
A clean rebuild pays off long after launch
The two-day regulatory turnaround only happened because the system was finally in good shape. Invisible infrastructure work is easy to undervalue until the moment it saves you.