Case study · work product
CarbonNex
An ESG reporting product. I designed the core workflows — how data gets in, how it's made comparable, and how it comes back out as a report someone can defend.
The three workflows. Inputs arrive in whatever shape they were recorded in. Normalize maps them onto one shape — and anything that doesn't map cleanly is flagged rather than dropped. The report is assembled from the normalized set, with every figure still leading back to the input it came from.
the problem.
ESG reporting looks like a writing task and behaves like a data-reconciliation one. The thing at the end is a document — but almost everything before it is figures arriving from different parts of a business, recorded by different people, at different times, to different levels of confidence.
Three properties of the domain make that hard:
- The data isn't born in one placeIt's generated wherever the activity happened, which is almost never where the reporting happens. Someone has to go and get it, and that someone is usually not the person who needs it.
- Comparable-looking numbers often aren'tFigures show up in different units, over different periods, against different boundaries. Quiet errors live in the conversions, and they survive right up until someone checks.
- The output has to be defensibleAn ESG report is something a person is eventually asked to stand behind. The first question about any figure is where it came from — so if the answer isn't in the product, the product hasn't finished the job.
what carbonnex does.
CarbonNex is an ESG reporting product: it takes an organisation's environmental, social and governance data and turns it into reporting.
My work sat on the layer underneath that — the core workflows. Not the visual design of the report and not the pipeline code, but the sequence a user moves through, what the product does at each step, and what it does when a step doesn't go to plan. Those decisions are what a reporting tool actually is once you're using it every quarter.
On what's not on this page: internal figures, screenshots, the customer list and anything else that belongs to the company aren't here. No adoption numbers, no uptime, no invented outcomes. What's here is the shape of the work and the reasoning behind it.
the workflows I designed.
-
01
Data in
Getting figures into the system from wherever they live. The design questions here are ownership and incompleteness: who is responsible for a given input, what the product shows when a number hasn't arrived yet, and how a half-finished period is represented.
The trap is treating a missing input as a zero. A gap and a zero look identical in a total and mean opposite things, so the workflow has to keep them distinguishable all the way through — which is a decision you make at intake or not at all.
-
02
Normalize
The step that makes the numbers comparable — raw inputs, in whatever shape they arrived, mapped onto one consistent internal shape. This is where a reporting product earns its keep, because everything downstream assumes it was done properly.
The interesting design isn't the happy path, it's the leftovers. Something always fails to map cleanly, and silently dropping it is the failure mode that destroys trust in a reporting tool. So the workflow surfaces exceptions instead of swallowing them, keeps them in the dataset rather than off to one side, and makes it explicit whose job it is to resolve each one.
-
03
Report out
Assembling the normalized data into the output. The constraint that shapes this workflow is traceability: every figure in the report should lead back to the input it came from, because that's the first thing anyone asks about an ESG number.
Designing for that constraint reaches backwards — you can only offer a trace at the end if you kept the lineage at the start. Which is why these three workflows had to be designed as one, not three.
how it fits together.
Read left to right the product is a straight line: data in → normalize → report out. That straight line is the easy half. It's also the half that gets specced.
The half that decides whether people keep using the thing is what happens when data is late, partial, in the wrong unit, or disputed — and workflow design is mostly deciding those cases deliberately, in advance, rather than letting them get decided by whoever writes that branch of the code first. That's the actual craft in a product like this, and it's most of what I spent my time on.
The through-line across all three: never let the product quietly guess. A missing figure stays visibly missing, an input that won't map gets flagged rather than dropped, and a number in the final report can always be traced back to where it came from. In a domain where the output is something a person has to defend, being honest about what you don't know is a product feature — the same instinct behind everything else I build.