By Schneider Electric
Zeigo HUB is where a supplier reports to the company it sells to how much energy it uses and how much it emits. Every site, every energy source, every month, with the right unit. It is the kind of data every company has somewhere, usually in a spreadsheet, and the kind nobody wants to retype into a product they opened five minutes ago.


Nobody asked me to fix onboarding. I was reading the funnel in Mixpanel and saw where it broke: the data steps. About two thirds of the suppliers who reached them left without finishing. I brought the funnel to the team and proposed the import.
The form already had autosave and an Invite Collaborator link. That tells you something: people were leaving mid-way and handing it to someone else. Scope 3 alone is 15 categories across two years. Energy Consumption asks electricity, steam, heat and cooling per year plus every region you operate in.
The hypothesis was simple: suppliers already have this data in a spreadsheet. If they can hand us the spreadsheet, most of the drop disappears. I ruled out shortening the form, because the fields are regulatory; saving progress and nagging by email, because it treats the symptom; and integrating with each supplier's accounting system, because there are thousands of suppliers and no common system. The spreadsheet was the one thing everyone had.
The decision that made it work was to design one data structure and make three things speak it: site, energy source, period, amount, unit. The template suppliers download has exactly those six columns. The parser in the browser maps the upload into that shape. The table renders that shape. The backend only ever receives the shape, already confirmed.
The import was born in Zeigo Activate, where sites already reported energy by source and month. The instructions PDF still carries the Activate logo. When HUB's survey showed the same drop, I brought the pattern over instead of designing a second one.
Real files are never clean. Users in the US wrote 1,000.5; users in Europe wrote 1.000,5. Some left units inside cells, some mixed periods. Instead of rejecting the file or silently normalizing it, the upload lands in a review table. Doubtful cells are tinted and marked. Empty cells show a plus. The header counts what is pending, and Confirm and update stays disabled until that count is zero.
Clicking a flagged cell opens the parsed values with two buttons: Reject Data or Save and confirm. The data is populated in the interface but nothing is sent until every item is confirmed. A designer alone would have shipped an upload that fails and asks you to try again. An engineer alone would have normalized server-side and lost the user's trust the moment a comma turned into a thousand-fold error.
I built the first version as a code prototype with Claude and Cursor, wired to the real template, in about a week. Fast enough to measure instead of debate. We put it in front of real suppliers with Mixpanel for completion and Clarity recordings for where they hesitated. The first version trusted the file. Users broke it in a day with commas, decimals, units and regional formats. That is where the review layer came from.
I opened the PR. The HUB engineers adapted it to their conventions and it shipped with small changes.
The structure outlived the feature. The same template, upload, review-rows pattern was reused as-is for Invite Collaborators: download a template, upload it, rows with a status. And every Zeus component HUB needed along the way went back into the system.
What I'd do differently: ship the validation layer in the first prototype. Real user data is never clean. I knew that and still tested the happy path first.
“Working with X has been great. He is reliable and fast. The solutions he designs are creative and empathetic to the end-user experience!”
Exelobaiza | Design Engineer