Increasing the Uptake of Renewable Energy

Introduction

Zeigo was a London-based startup on a mission to transform how businesses access renewable energy — specifically through Power Purchase Agreements (PPAs), long-term contracts between corporate buyers and energy developers that are complex, slow, and expensive to navigate.

I joined at the earliest stage, when there was no design process, no system, and no product. Alongside founding the delivery function — hiring and coordinating across engineering, product, and marketing — I was the sole designer responsible for taking the platform from concept to a working, iterated product.

As the company matured and dedicated leads were brought in across those functions, my remit consolidated around design. I owned all visual and interaction design end to end — from early concept through to high-fidelity prototype — while continuing to shape product direction in close collaboration with the founders.

User research was a shared effort with marketing, with synthesis and design direction mine to lead; the design system was built and maintained by me, alongside engineering. That position — close to business decisions and directly executing on them — defined how the product was built.

Zeigo raised multiple investment rounds before being acquired by Schneider Electric in 2022, where the product continues as part of a newly formed portfolio of decarbonisation products as Zeigo Power.

The General Problem

Navigating a PPA is out of reach for most companies. A typical agreement can span 15 years or more — preceded by lengthy legal negotiations demanding significant time, money, and specialist knowledge.

The companies that succeed here are either large enough to run specialist in-house teams or wealthy enough to pay advisory firms. Both routes are slow, expensive, and inaccessible to most of the market. Traditionally, PPAs have also required large energy footprints, leaving smaller organisations with few viable alternatives regardless of appetite.

For the majority that can't qualify on scale or afford the expertise, one of the most impactful clean energy mechanisms available remains out of reach.

The Specific Problem

Even for those with the resources to enter the process, the risk doesn't disappear — it just shifts. The most significant pain point was late-stage deal collapse: parties could invest two or more years into negotiations only for agreements to fall apart due to supply chain disruptions, shifting circumstances, or misaligned expectations. This wasn't an edge case — it was a pattern observed repeatedly across active deals.

Earlier concept testing explored marketplace-based solutions, but these saw limited traction. What it did surface was more useful: analysis of failed deals, combined with observations from the operations team, revealed that many collapses could have been avoided had key contextual gaps been identified earlier. The problem wasn't just complexity — it was that the wrong information was being exchanged at the wrong time.

Speed compounded the issue further. The longer a deal took to close, the greater the exposure to price volatility — with cost assumptions made at the outset drifting meaningfully by the time agreements were finalised.

The Vision

The opportunity was clear: if the right information could be surfaced earlier — and the most time-intensive phases streamlined through software — both the cost and duration of a PPA could be dramatically reduced.

The three focus areas were market engagement, tendering, and the selection process. Of these, tendering efficiency represented the highest design leverage — faster, better-matched connections between buyers and developers had the greatest potential to compress the overall timeline and reduce the contextual gaps driving late-stage failure.

The ambition was to reduce what typically took 32 months down to 16. This wasn't a rigorously validated figure — it was a directional target, set collaboratively, that unified the team and established tendering efficiency as the explicit design priority, shaping how effort was sequenced across the product.

Progress was tracked through two leading indicators — volume of tenders initiated and time-to-close — which provided directional confidence in the overall model rather than granular attribution of individual decisions. That tradeoff was typical of this stage, where speed of learning mattered more than measurement precision.

The Solution

Research ran the length of the product's development, drawing on stakeholder interviews, workshops, and moderated usability testing at key stages. Two things stood out: low engagement on the early marketplace confirmed the transactional format wasn't working; and the contextual gap — already visible in the failed deals analysis — was confirmed as the central design challenge through regular structured sessions with the operations team.

The operations team's direct involvement in live deals gave them a level of client insight that formal research couldn't always access — structured sessions with them ran alongside each design cycle, providing consistent access to observed client behaviour alongside direct user contact.

The design process was scaled to stage. Early exploratory work moved through whiteboard sessions and low-fidelity wireframes; later-stage validation used high-fidelity Figma & Framer prototypes tested directly with users. At each level, decisions were validated through a combination of direct user testing, ops team input, and founder review — a layered approach that meant major calls were rarely made on a single signal.

Key Design Decision: Tendering Journey over Marketplace Model

The earliest version of the product took a marketplace approach — connecting buyers and developers directly with minimal friction. In theory it was the right instinct. In practice it failed on several fronts: the format was too transactional for the trust required in a 15-year commitment; developer offerings were too vague and quickly outdated; and critically, developers had no visibility of buyer profile when responding, making it impossible to prepare tailored offers.

Both sides lacked the context needed to make confident decisions — and without that confidence, engagement stalled. Drop-off data made the pattern undeniable: activity on the marketplace was consistently low, with developers disengaging before completing responses and buyers showing little return after initial exploration.

The tendering journey was the answer. Rather than connecting parties immediately, it established structured alignment upfront — capturing buyer specifications and distributing them to developers before any direct engagement began. This gave developers the profile information they needed to respond meaningfully, and gave buyers a basis for genuine comparison.

Confidence in this direction came from where engagement was highest. The tendering flow was consistently the most active part of the product — visible in both usage data and the quality of behaviour observed in user sessions and ops feedback. Between the data and what we were seeing in sessions and ops feedback, confidence in the direction was solid.

Personas

A PPA is agreed between two parties — the Renewable Energy Developer and the Corporate Buyer — with the operations team serving as facilitator. Three distinct personas, each with a dedicated interface tailored to their role and stage in the process.

Corporate Buyer

Typically a sustainability or procurement manager, the buyer entered the process driven by a combination of motivations depending on their organisation — meeting internal net-zero commitments, reducing long-term energy costs, or demonstrating ESG credentials to investors and stakeholders. What they shared was a lack of specialist PPA knowledge and a need for structured guidance through a process that would otherwise require external advisory support.

The platform was designed to make that guidance feel native rather than bolted on. The core tension was language: PPA negotiations require precise terminology — contract structures, volume thresholds, delivery locations — that developers needed to act on, but that buyers with no specialist background couldn't be expected to understand without help. Simplify too far and the specification becomes too vague to use; retain full technical precision and buyers abandon the form.

Renewable Energy Developer

Developers were managing responses across multiple active tenders simultaneously, often without knowing what a buyer needed before committing time to a reply. The result was reactive, poorly matched offers that wasted effort on both sides. The platform addressed this by ensuring developers received a full buyer specification before responding — giving them the context needed to prepare tailored offers from the outset.

Two tensions ran through the design: developers needed to respond quickly enough to sustain engagement across a high volume of tenders, but the structured format required for fair comparison constrained how they could articulate what genuinely differentiated their proposition. Getting that balance right — efficiency without flattening real differences — shaped the response flow.

Operations Team

The internal team responsible for ensuring deal quality and fit before any engagement progressed. Rather than working across buyer and developer views reactively, they had a dedicated admin panel with the ability to monitor progress and intervene directly in user flows when needed.

The challenge here was different: the ops layer needed genuine oversight and intervention capability while remaining entirely invisible to buyers and developers. Any feature built for ops that leaked into primary user views would have undermined the self-serve experience the product was built around. The result was a parallel interface — purpose-built for ops workflows — that sat completely outside what either party could see.

RFI to RFP: The Evolution of the Tendering Feature

What followed was iterative — the tendering feature evolved through four stages, each shaped by user behaviour, operational constraints, and a growing ambition to move the experience entirely into the product.

Stage 1 — Simple Inbox

The earliest iteration made no attempt to structure the process. Buyers and developers communicated directly through a basic inbox, with pricing requests handled informally and all supporting detail shared via PDF documents. It was a viable starting point — fast to ship and familiar enough that both parties could engage without training. But it offered no consistency, no comparability, and no foundation for scaling.

Three failure modes became visible in parallel: buyers were sharing inconsistent information — no two tenders looked the same, making developer responses incomparable; the ops team was spending significant time manually standardising submissions before they could progress; and both parties were increasingly reverting to email, using the product as a starting point but conducting meaningful exchange outside it. Each problem pointed to the same gap: without structure, the platform couldn't hold the process.

Stage 2 — Single Round RFI

The first dedicated tendering feature introduced structure without adding complexity. Buyers were guided through a single-round RFI process built around prescribed questions, ensuring responses were collected in a consistent format for the first time. A PDF summary was generated at close — presenting all developer responses in a comparable layout. The document remained central to the experience, both because the ops team depended on it as part of their workflow and because clients had come to expect it as a deliverable.

It was also, practically, the fastest way to get something meaningful in front of users. There was early awareness it couldn't stay central indefinitely — but moving data into the product at this stage would have slowed delivery without materially improving the experience. It was a deliberate interim.

Stage 3 — Two Round RFP with Shortlisting

The process matured significantly with the introduction of a full two-round RFP. Shortlisting between rounds gave buyers a structured decision point, and match scoring helped surface the strongest fits from an increasingly large developer pool.

The developer feedback mechanism introduced here deserves specific attention. Previously, unsuccessful developers received no structured outcome — the ops team spent significant time manually calculating comparative performance and communicating results individually.

The feedback interface automated that process entirely — giving developers a relative scoring view across criteria such as pricing, location, and contract terms without ops having to generate the analysis. Developers used it actively as a benchmark for assessing competitiveness and improving future submissions. Ops continued to reference it in review calls, but no longer had to produce the underlying work.

The PDF evolved in parallel, expanding to include full market commentary, half-hourly energy data, data analysis, and evaluation scoring. It was now doing substantial analytical work, but that work was still living outside the product.

Stage 4 — Bringing the Data into the Product

The final iteration addressed what had become the most significant constraint: a growing volume of valuable, time-sensitive data locked inside static documents. The initiative was to migrate that data progressively into the platform — transforming it from a PDF output into live, interactive content with sharing capabilities.

This unlocked what the document-based approach never could: reduced reliance on ops to interpret and distribute analysis, buyers and developers engaging with live data directly, and all meaningful interaction taking place within the product.

The PDF wasn't eliminated — that would have broken an established expectation — but its role was deliberately diminished, repositioned from a primary deliverable to a supporting export.

Forming & Distributing Buyer Specification

A PPA requires buyers to articulate complex energy requirements — volume, location, timing, contract length — in a form that developers can actually act on. Three things needed to work: structuring that complexity into a guided format without overwhelming users unfamiliar with the terminology; ensuring every specification was consistent enough for developers to compare tenders on equal footing; and keeping the experience fast enough that buyers didn't drop off midway.

An earlier version of the form presented buyers with the full set of required fields at once. Observed drop-off made the problem immediately clear: buyers unfamiliar with PPA terminology were confronted with the entire scope of the process before they'd built enough context to feel confident proceeding. Progressive disclosure was the direct response — surfacing fields conditionally based on what had already been captured, keeping the apparent scope manageable at each step without sacrificing the completeness developers needed.

Free text was minimised throughout in favour of defined inputs — unstructured responses would have produced incomparable specifications, undermining the platform's core value of consistent evaluation across developers. Distribution controls were built in proactively around the commercial sensitivity of energy procurement data: buyers retain full visibility of which developers receive their specification before it goes out, giving them the confidence to share detailed requirements.

Developer Response & Feedback

Once a specification was distributed, developers needed to respond in a way that was both meaningful to buyers and efficient for themselves. Three things had to be true: enough buyer context upfront to self-qualify before investing time in a response; responses structured enough for buyers to compare across very different developer profiles; and for developers who weren't selected, something more useful than a rejection.

That last point was a deliberate design decision — and one that required iteration to get right. An earlier version surfaced raw scores without context, which caused frustration rather than useful reflection; developers who felt they'd been competitive had no basis for interpreting why they hadn't been shortlisted.

The redesigned interface showed a relative scoring view — where each developer's offer ranked against others on specific criteria such as pricing, location, and contract terms — giving them a meaningful basis for assessing their own competitiveness. Closing that feedback loop improved the quality of future responses and maintained developer engagement with the platform over time.

The buyer specification sits at the top of the response flow so developers see the full picture before committing to a reply. The structured response format mirrors the specification fields directly — buyers can compare across very different developer profiles without having to interpret free-form answers. And for those not shortlisted, the feedback interface gives a relative ranking across key criteria rather than a binary outcome — something they can actually act on.

Analysis and Shortlisting

By the time responses were in, buyers could be looking at a significant number of offers — each a complex, long-term proposition. The risk was decision paralysis. The design needed to surface the most relevant signals without requiring buyers to read everything, make comparison fair across very different developer profiles, and give ops enough visibility to step in where needed.

Responses are normalised into a consistent format regardless of how developers submitted, making side-by-side evaluation possible at a glance. Criteria weighting was fixed by the platform in the first iteration based on standard PPA priorities — with secondary detail available on expansion — and buyer-adjustable weighting introduced in a later release.

The ops overlay works at two levels: in-product prompts for lighter guidance at critical decision points, and direct outreach for situations needing more significant input — both invisible to buyers, keeping the self-serve experience intact.

PPA Calculator

The calculator served two distinct purposes depending on where buyers were in the process. Its primary role was mid-tender: once developer offers were in, buyers needed a way to evaluate proposed pricing against live market benchmarks and forward-looking forecasts — understanding whether the terms being offered reflected genuine value over the contract lifetime. It also served a pre-tender use case, allowing buyers considering a PPA for the first time to assess feasibility across different European locations before committing to a full specification.

In both cases, the challenge was making complex energy economics accessible to buyers with no specialist finance background, while producing outputs rigorous enough for ops to use in client conversations. Forward-looking forecasts were powered by specialist third-party providers — including Cornwall Insight, Aurora, and EEX — which provided market projections over the contract term. Historic price curve data was drawn from the platform itself, grounding the analysis in actual deal data rather than market estimates alone. The mix of providers evolved over the product's lifetime as the energy forecasting market developed.

Only three fields are required — energy volume, current tariff, and contract length — keeping the barrier to entry low regardless of where the buyer is in the process. Projections are visualised as a range against market benchmarks rather than a precise figure, reflecting genuine market variability and avoiding false precision that would undermine trust. Data sources and assumptions are surfaced inline throughout, so buyers understand what they're looking at before drawing any conclusions.

Results

In one instance, a tender closed in just 4 months from initial expression of interest to signed agreement — a fraction of the 32-month industry baseline that had defined the original ambition, and a result that wouldn't have been possible without the structured matching the platform enabled.

Across its lifetime, Zeigo facilitated over 50 tenders across Europe, engaged 100+ active renewable energy developers, and supported the completion of 10 Utility PPAs and 2 Corporate PPAs. The European corporate PPA market was nascent during this period — structurally inaccessible to most organisations and dependent on specialist advisory relationships that few companies could afford. In that context, the platform's reach reflected meaningful traction in a market that was only beginning to form.

Operational improvements were consistently observed through ops team feedback. Developer response rates improved as the structured specification format gave respondents the context needed to self-qualify before committing time to a full reply. Time from tender open to shortlisting shortened as the analysis and comparison tools reduced the manual interpretation burden on both buyers and the ops team. Repeat usage amongst developers was strong — the platform became a reliable channel for accessing corporate procurement opportunities across Europe.

The acquisition validated the commercial thesis. Rather than being sunsetted, the product was adopted and scaled within Schneider's Sustainability Business division under the Zeigo Power brand.

My involvement extended into this period, before moving on to bring new products to life (Data Relationships Before Detailed Design) within Zeigo in 2024.

What the data also revealed

Corporate buyer retention told a different story — and an instructive one. Most buyers either completed a PPA and had no immediate reason to return, or used the platform to evaluate the market before concluding a PPA wasn't right for their organisation. The latter was the more common outcome.

It exposed a fundamental tension: digitising what is essentially a consultancy-led process is not a natural fit for a self-serve software model. The platform made the process more accessible and structured, but couldn't get around the underlying reality that many corporate energy buyers need guidance to reach a decision, not just tooling.

That insight points to a specific design challenge worth naming. Many buyers entered the platform with genuine intent to pursue a PPA — but volume requirements and the length of contracts made it difficult to build the internal buy-in needed to proceed. In practice, they used Zeigo as a feasibility exercise rather than a procurement process.

The platform had been designed for buyers who had already decided to act; the majority hadn't yet reached that point — and there was no designed response for them. Focusing design attention where demand actually sat — on the feasibility-to-commitment gap, and potentially on different commercial structures for buyers who couldn't yet qualify for a full PPA — would have been the natural next challenge, and one that could have materially shifted both buyer retention and the product's business model.