By Schneider Electric
Buying renewable energy certificates as a group means dozens of companies committing volume against one price, in a window that closes on a date. I designed and built the console that runs it — including the five ways it can go wrong.
Two sides use it. EAC Control, the Schneider team that creates an opportunity, sets the price ceiling, shares it with organizations and closes the trade. And the buyers, corporate procurement teams committing volume, who see an anonymised version of the same opportunity. Before the console, the price was agreed by email and the volumes tracked by hand.
The decision: treat the closing of the trade as the product. Not the browsing, not the catalogue — the closing. There are six whole flows for it: confirm at the wholesale price, confirm with reconciliation, target not reached, zero orders, error, and cancellation. That is not defensive design. That is the feature.
You only know there are six outcomes if you know what the system does with money. The agreed wholesale price can differ from the sum of the orders placed. A window can close under its MWh target and still be closable. A window can close with zero orders. And a cancellation means issuing refunds to people who already paid — which is why the buyer sees a written reason on the card, not an error code.
Reconciliation is the crux, and it arrived last. At order time the buyer pays against a wholesale commodity cost. By confirmation, the cost agreed with the supplier may be lower. So the screen asks whether it changed and lets the operator enter the final figure — constrained to be equal to or below what the buyer already paid, because the only legal direction for that number is one that owes the buyer money. The stack recomputes in front of them and the field answers live.
Finding it late was expensive. Reconciliation is not a screen you bolt on: it changes what the confirmation step is allowed to do, so the whole closing flow got a second version. What I'd do differently: map the money before the screens. Every scenario I found late was a question about what happens to a payment, not about a UI.
The method was flow first, literally. Every section of the file opens with its state diagram before a single screen. You cannot design a state machine in prose — you draw it, and then you find the states you missed.
What didn't work: the product did not reach the volume it was built for. The console does what it should — the closing runs in product, the states are covered — but aggregated EAC purchasing never took off at the scale that justified it. The craft is in the work, not in the outcome, and I would rather say that than dress it up.
Exelobaiza | Design Engineer