Data Relationships Before Detailed Design

Introduction

Zeigo by Schneider Electric, built a new product to serve a growing segment of the Energy Attribute Certificate market: smaller, compliance-driven organisations that needed a faster, more accessible route to procurement.

At the time, certificate purchasing at that scale still relied heavily on brokers, spreadsheets, and manual coordination, creating challenges around speed, trust, and pricing transparency. Internal teams were beginning to see demand from buyers that Schneider Electric's consulting-led model wasn't designed to support efficiently.

There was no established product, workflow, or dedicated team when the work began. I joined during that formation stage, leading product design while helping shape the platform alongside engineering, legal, treasury, and commercial stakeholders. As the product matured, additional designers and external partners contributed across the platform, while I remained responsible for the core marketplace experience and continuity across delivery.

How it Unfolded

The work ran from brief to delivery over roughly two years, starting with user and internal research to understand how smaller buyers were currently navigating procurement.

Most of them were working through brokers, with spreadsheets doing the coordination in between — slow, opaque, and dependent on someone holding the thread. That shaped both the trust requirements and the speed expectations the product would have to meet, and grounded the initial concept we aligned with the business before assembling a cross-functional team around it.

From there, we moved into build and iteration with engineering on a lean, iterative cadence, carrying the product through beta and into early live usage.

The General Problem

The Energy Attribute Certificate market was changing shape. A growing class of smaller companies — many operating within regulated supply chains or reporting to bodies like CDP, RE100, and SBTi — were facing increasing pressure to demonstrate renewable energy credentials. For them, EAC procurement wasn't a strategic choice; it was a compliance requirement.

They needed something specific: a route in that was fast, transparent, and didn't require sustained back-and-forth to reach a transaction. Existing market structures had been shaped around large, bespoke enterprise procurement, where deal size justified the engagement.

Smaller, fragmented orders called for a different operating model — one designed for digital aggregation rather than one-to-one configuration.

The Research

Entering a new domain with no established playbook, the first job was to understand it before forming a view on what to build. Schneider Electric's existing consultancy relationships provided an immediate advantage — they opened doors to potential customers and internal domain experts who wouldn't otherwise have been accessible this early in the process.

Over six weeks, we ran around 12 interviews, workshops, and stakeholder discussions across two groups: buyers within the target market segments, and internal agents and domain experts who understood how the EAC market actually operated day to day. Both perspectives were essential — one shaped what the product needed to feel like, the other shaped what it needed to do.

Not everything we expected to find was confirmed. We had assumed price transparency would be the primary driver. Buyers were less sensitive to price than we'd anticipated. What they wanted was visibility — knowing their order was moving and having confidence it would complete. Transparency of process mattered more than transparency of price.

A second consideration emerged internally. The platform depended on Internal Agents — the market specialists who would configure each purchase opportunity, set the conditions buyer groups could form around, and manage trades through to completion. Without their day-to-day operation, there was nothing for buyers to commit to.

Understanding how the platform fitted into their work — what it added, what it replaced, what it left untouched — became as important as understanding the buyer's journey. The Internal Agent became a primary persona because the platform's success depended on their fluent use of it, not just the buyer's.

We pulled four themes out of those sessions in a team workshop — price, impact, scale, and speed — and used them to align stakeholders around the aggregation model the research pointed to. Some were named directly by participants; speed and visibility came up repeatedly and unprompted. Others surfaced as patterns across the research. Their role was less to arbitrate downstream decisions than to give a cross-functional group a shared frame for committing to a crowdfunding-style approach in a market that didn't yet operate that way. Underpinning all four was trust — without it, none would deliver.

Personas

We distilled findings into four personas to stay focused on the users who mattered most to the MVP. The Small-Scale Buyer and Internal Agent were the primary ones — not because the others were unimportant, but because the entire model stood or fell on getting this relationship right.

Small-Scale Buyer, Regional Operations Manager

John's mandate was straightforward: hit his company's renewable energy targets without overcomplicating the procurement process. He wasn't a market specialist and didn't want to become one. What he needed was a route to compliance that felt credible, moved at pace, and didn't require him to navigate infrastructure he didn't understand.

Research confirmed that John's anxiety wasn't primarily about price. It was about completion. He needed to know his order was going to go through — that the commitment he'd made, and the internal sign-off he'd secured to make it, wouldn't end in ambiguity. A market he couldn't read, on a platform he'd never used before, asking for upfront payment: each of those was a reason to hesitate. The design had to address all three without adding process.

"I just need to know it's going to happen. I can deal with the rest."

Internal Agent, Market Agent

Riley sat at the other end of the transaction. She read market conditions, monitored price movements, and had the trading background to configure and manage opportunities at volume. The platform needed her to function — without an agent setting the conditions under which buyer groups could form, there was nothing for buyers to commit to.

Her work shaped the platform's structure as much as the buyer's did. Every opportunity that appeared to a buyer started as a configuration Riley had set: certificate type, geography, volume bands, price thresholds, the commitment window itself. Once an opportunity went live, the platform took on the financial and administrative weight — payments, trade records, retirement evidence — leaving Riley free to focus on the configuration and market judgement that only she could provide.

"If I'm setting this up, I need the product to handle the financial and admin side once it's live."

The Specific Problem

The research confirmed two structural constraints that would define the design.

Speed was non-negotiable. The aggregation model only holds if enough buyers commit — too many drop-offs trigger a domino effect, unravelling the commitments of everyone else in the group. Every step added to the journey was a potential failure point for the entire mechanic.

Trust was the counterweight. The research had shown commitment, not price, was the buyer's anxiety. The experience had to make commitment feel legible and safe without adding the friction that speed demanded the journey remove.

These two constraints pulled in opposite directions. Resolving them — without compromising either — was the central design challenge.

The Vision & Concept

Crowdfunding was the closest working analogy — imperfect, but useful. Grouping buyers with matching criteria and processing their transactions in bulk gave us a mechanic the market didn't have, and one buyers already understood from elsewhere. Aggregating smaller orders brought competitive price points within reach of buyers who couldn't access them alone, removed the need for one-to-one negotiations, and made the market accessible at scale.

The platform would need to earn buyer confidence quickly — through transparency and an experience that felt dependable from the first interaction.

To know whether the vision was working, we needed a single signal. We anchored the product around a North Star Metric agreed with leadership: completed orders.

Not revenue, which would have rewarded large single deals over the aggregation mechanic. Not raw volume, which wouldn't distinguish individual transactions from genuine multi-buyer groups completing. Completed orders signalled that buyer groups were forming and fulfilling at scale.

Oversized individual orders were tracked as a negative signal — useful, but not evidence that the core proposition was working.

Designing The Solution

With the pillars, personas, and vision established, the challenge shifted to execution. Before any of it could be designed in detail, we had to map the domain dependencies. EAC retirement variants differed by market — distinct registries, validity windows, and evidence requirements — and each carried implications for what the platform could promise a buyer.

Legal posture for US-based trades had to be settled. A digital treasury function needed standing up, with a third-party payment provider (BlueSnap) selected to handle upfront capture and reconciliation rather than building it in-house. None of these were design problems in isolation; together they defined what the design could commit to.

Where Alignment Slipped

The team's first move toward shared understanding was a story map — charting how data moved across each persona's journey before any screens were drawn. It gave the team a common language and kept early decisions grounded in user needs rather than assumptions.

As new design, technical, and product partners joined, the shared understanding stopped carrying as much weight as it had. Work had already progressed into experience design when two structural gaps surfaced — both stemming from a relational structure that early proposals hadn't accounted for. Users, organisations, orders, and opportunities were linked, but had been treated as largely independent.

The first was B2B dynamics. Incoming partners had designed for a single-user experience — a reasonable default, but wrong for this context.

Purchases were being made on behalf of companies, not individuals. Multiple people from the same organisation needed to access the platform, place orders, and retrieve trade and retirement certificate evidence. A single-user model introduced real risk: if the user who made the purchase left the company, access to that documentation went with them.

Orders had to sit at the organisational level, with organisations themselves invitable to purchase opportunities — and the design rebuilt around that.

The second was flexible purchasing. The proposed design was static — one company responding to an opportunity based on a prescribed invoice issued by an agent.

The logic was sound as a starting point but wasn't extensible. Iterating toward multi-buyer aggregation would have required a full rewrite rather than incremental development. The future state the product needed wasn't compatible with the structure being built.

What resolved the misalignment was a data relationship model — a practice I'd carried into projects before, learned from engineering teams who treated database structure as the foundation everything else translated from. I introduced it here alongside site maps annotated with specific data points, not to define technical architecture, but to understand where data lived, how it connected, and what that meant for the journeys being built on top of it. The model mapped nine core entities — Purchase Opportunity, Commitment Window, Order, Organisation, User, Payment, Retirement Information, Trade, and EAC Retirement — and made their relationships explicit.

An Order, for instance, sat at the centre of a web of downstream data: a payment record, a trade confirmation, retirement information, and potentially multiple EAC retirements. Organisations were shown as containers for multiple Users, with Buyer and Control access types. That structure — which looks obvious once drawn — shaped how we rebuilt the experience and kept the growing team aligned around the same vision.

Established earlier, the model would have been the foundation. Introduced when it was, it was a correction.

Slicing Into Releases

With alignment restored, we broke the product into release sequences and worked through them on a lean cadence: define a milestone, build it, validate against the buyers and agents we'd already engaged, then move to the next. Prioritising the most critical functionality first let the team validate the core before expanding outward — building confidence without overextending.

The invite system was the first slice: the gate that let the beta begin with a known population of buyers responding to a known set of opportunities, before the transactional mechanics had to prove themselves.

Delivering The Experience

By the time we were producing interfaces, the hard structural questions were already resolved. One principle governed the design process: removal over addition. Each iteration stripped away rather than accumulated, keeping the journey to a completed order as direct as possible.

The experience ran as a four-beat sequence, paced by the agent and responded to by the buyer. Riley invited known organisations onto the platform and into specific opportunities. She created an opportunity and opened a commitment window — the price, the volume required to achieve that price, and the deadline a group of buyers had to fill. John, alongside other invited buyers, transacted against that window.

Riley collected orders as they came in, judged the volume at deadline, and confirmed the trade. Once retirement took place, the cancellation statement closed the loop with evidence John could use for reporting. Each beat carried its own design problem; together they formed the journey to a completed order.

Invite System

From her own interface, Riley could see every organisation on the platform and the users within them. New companies entered through the organisations section, where she added the email address of the single contact who'd be invited to set the organisation up.

The system locked to the email address itself, not the invite link. The recipient had to register against that address, but once through, they controlled which colleagues joined the organisation.

Teammate invites didn't need Riley's involvement; she didn't have to gate every individual. Her second layer of invite came when she configured an opportunity: she selected which organisations were admitted to it, and only those organisations saw the opportunity or could place orders once the window opened.

For John, the invite arrived as a single email and a clear path forward: register against the invited address, set up his organisation, bring in the colleagues who'd need access to documentation later. Anchoring access to the email rather than the link kept entry predictable regardless of whether the original message was forwarded, delayed, or revisited.

With orders sitting at the organisational level rather than the individual's, the trade and retirement evidence didn't leave with him if he did. The two layers — account access first, opportunity access second — gave the beta a controlled population to validate the mechanic against, without exposing it to the open market before it was ready.

Purchase Opportunities & Order Windows

Every opportunity began with Riley. She configured the certificate type, geography, and volume bands that defined what the market could form around, then opened the commitment window — the price, the volume required to achieve that price, and the deadline by which the group had to fill. On the other side of those terms, John transacted: scanning opportunities, picking the one that matched his needs, and placing an order against the window before it closed.

For John, the opportunities screen had to do two things first: help him quickly identify whether an opportunity matched his needs, and give him enough confidence in what he was looking at to keep going.

Buyers evaluated opportunities on certificate type, geography, and volume — they needed to match on all three before price and delivery timeline became relevant. The information hierarchy followed that sequence: matching attributes came first; price and timeline followed once the fit was established.

Schneider Electric's brand ran consistently throughout, providing the institutional credibility a new platform couldn't yet earn on its own. An early iteration included a comparison view, allowing buyers to evaluate multiple opportunities side by side. It was cut — not because research ruled it out, but because the data sources needed to power it hadn't been standardised yet, and building for it would have added complexity without being essential to the first release.

The order window itself was the highest-stakes moment in the journey. John was being asked to commit money, upfront, to a group he couldn't see, on a platform he'd never used, on conditions someone else had set. The design had one job: make the consequence of that commitment legible before he made it.

What he'd committed to appeared clearly — certificate type, geography, volume, price, delivery window. A step-by-step sequence immediately following payment spelled out what happened next, removing the ambiguity research had identified as his primary anxiety.

The progress indicator showing how close the group was to completing earned its place by serving double duty: a live signal to the buyer that the model was working, and a fill signal to Riley that the conditions she'd set were drawing the commitments she needed.

Order Collection & Finalise Trade

This was where the agent's setup met the buyer's response. Riley watched orders accumulate against the window she'd opened and, at deadline or earlier if the volume cleared, judged whether acquired volume was enough to confirm the trade.

Her view gave her visibility of committed buyer groups and the conditions she'd configured for each opportunity in one place, surfacing enough information to act quickly — adjusting conditions, escalating near-complete groups — without becoming a case management tool that added to her workload. Keeping it separate from the buyer's view let her work at the density her trading background allowed, without forcing John to navigate an interface built for someone else.

For John, the outcome of that view arrived as a trade confirmation — the signal that the volume he'd committed to had executed. It was the prompt he needed to communicate internally that the order had landed, ahead of the evidence that would follow.

Retirements & Evidence Shared

Once the EAC retirement took place, Riley uploaded the cancellation statement that formally recorded it. That document closed the transaction from the agent's side.

For John, the alert that the evidence was ready was the moment the transaction became fully real. The cancellation statement was the record he'd need to demonstrate compliance to reporting bodies like CDP and RE100 — and to justify the spend internally.

Certificate source, energy type, and origin geography appeared in verifiable detail, not summarised. The document worked as a standalone — something that could be forwarded without needing platform context to make sense.

The step-by-step explanation from the commitment stage carried through here in resolved form — each step marked complete, the full journey visible. For a buyer who had entered the process uncertain whether their order would complete, closing that loop was the final trust signal the design had to land.

Results

The beta validated the platform's mechanics end-to-end — invitation, commitment, payment, trade, retirement, evidence — across one completed order. The transaction moved through cleanly and the buyer's feedback was positive. Their volume was sufficient to meet the window's threshold on its own, so the trade completed at the confirmed price without other participants having to join.

What that didn't prove was the multi-buyer aggregation mechanic — buyer groups forming, holding together, and completing across multiple committed organisations. That was the behaviour the NSM was built to measure, and a single transaction couldn't confirm or deny it. It remained the open question the product needed more runway to answer.

Reflection

The beta also clarified a dependency worth naming earlier: the aggregation model performs at scale, and the initial phase couldn't fully demonstrate that. A leaner scope, or a client profile less dependent on multi-buyer group volume, could have provided a faster validation path for the core mechanic. The design was built to support the full vision; aligning that ambition with what was achievable in the initial phase is the conversation worth having before build begins, not after.

What the process proved was more contained but genuinely transferable. The data relationship model gave everyone on the team — design, product, engineering — a shared reference for what existed, how it connected, and what the experience had to be built around. Where the story map gave us sequence, the data model gave us structure. Misalignment on product vision produced real cost on this project; the model is what resolved it.

Establishing data relationships as a shared team artefact before detailed design begins — not in response to friction — is the practice I now carry into every project. Sitting close to engineering earlier on showed me how much of a product's scalability is set by its data structure, and how expensive it is to retrofit design built on assumptions the data won't hold. On a formation-stage project with a growing, distributed team, it's one of the most effective tools for keeping everyone oriented around the same vision.