This project is password protected
Enter the password to view this case study.
Incorrect password
Approved Vendor Lists
Avoiding errors by building AVL compliant designs
For Aurora Solar
Research, problem definition, design iterations, finalized design, handoff to the implementing team
Sales rep, Designer, Admin
Cross-domain
Design Q4 2024 · Release H2 2025
Background
Financing is a common alternative to paying cash for solar, and as interest rates on traditional loans have risen, third-party ownership (TPO) has grown in popularity. In a TPO project, the financier owns the system and enforces strict design requirements to protect their investment — including component enforcement: requiring specific manufacturers or SKUs for modules, inverters, batteries, and more. The industry term is an approved vendor list (AVL).
Problem
In Aurora, users only discovered AVL requirements through error messages. They’d design a full system, the homeowner would apply for financing, and they’d hit an error requiring a redesign with compliant components (informed by complex financier documentation) — all while usually sitting beside a homeowner trying to close a deal.
When a financing partner didn’t incorporate AVL errors in their API, the consequences were worse: non-compliant designs could require change orders (where a homeowner needs to agree to and sign off on a change in price and/or design) or refusals to fund all together.
Goals
- 🎯Surface AVL requirements without relying on error messages
- 🎯Present in both Sales Mode and Design Mode (~35% of TPO projects were initiated in Design Mode)
- 🎯Work across required component types (comparing partner AVL lists identified modules and inverters as the core types for initial release)
- 🎯Reduce AVL errors by 75% (one financier alone generated ~800 AVL error instances per week)
Design Explorations
My first step was to ideate through a few different potential paths forward. 3 leading contenders emerged.
#1 – Move the financing selection to the project creation flow and auto-populate compliant components on the design
Why this doesn’t work
- ❌Conflicted with existing logic that determines available components based on other project criteria.
- ❌Financing decisions can change during the sales cycle so users would need to skip or switch anyway.
#2 – Use component tags to indicate AVL compliance
Why this doesn’t work
- ❌Existing tags lacked a cohesive architecture. For example, the same color indicated different things in different areas of the product.
- ❌The resolve the above problem, I considered a custom tagging system. But that raised it’s own set of problems. Customers would be required to maintain their own financier AVL lists, which isn't reasonable since AVLs don't change per customer.
- ❌Too much tag metadata on a single component quickly becomes noisy and unhelpful.
#3 – Filter component lists using a tabbed navigation, oriented by financier
Why this works
- ✅Enables AVL-compliant selections from the start.
- ✅Uses a familiar pattern already supported in the design system.
- ✅Clean and scalable across integrations and component types.
- ✅Compatible with a future enhancement: if financing is selected up front, the relevant tab can be pre-selected automatically.
Additional States and Product Areas
After establishing the base tab pattern with modules, I then designed the additional artifacts: mocks for remaining component types beyond modules (inverters, batteries), tab component state changes, account-level component enablement for admins, and Design Mode.
Handoff
As a TPO subject matter expert, I identified the problem and solution — but the tab solution touched a product area I didn’t own. The owning designer was informed on the project through our weekly design syncs but additionally I scheduled a full walkthrough with the implementing team covering research, problem space, and solution. We agreed the receiving team would run their own research sessions to build firsthand understanding of the space.
For final deliverables, I handed off: an implementation guide, a click-through prototype and a research document (complete with potential customers to test with and a script focused on areas of concern).
Results
Research didn’t uncover any major changes to my proposed design, so this project moved forward to implementation.
After release, total projects with errors dropped significantly from one month to the next–this exceeded our 75%* reduction target.
*We couldn’t isolate AVL’s contribution specifically — other error-reduction work (which I also led) shipped in parallel — but given AVL’s outsized share of errors, we considered this a clear success.
“Aurora provided a unified platform that ensures accuracy, reduces rework, and allows us to handle TPO projects seamlessly. From AI-powered designs to integrated workflows, it has streamlined every aspect of our operations.”
— Our World Energy
Learnings
- Don’t let team boundaries dictate the path forward — prioritize the right solution, then align teams around execution.
- A product partner departure, a RIF, and a reorg all happened during this project. When things are uncertain, take actions that will bring clarity.