An AI estimator shipped in six weeks without asking anyone to trust it blindly.
Siemens SiGREEN needed a way for procurement teams to get carbon data on components their suppliers couldn't report on. The strategy brief was blunt: it had to work for people with almost no carbon expertise. I designed the interaction model that made the automation fast enough to be worth using, and legible enough to be trusted with compliance-grade data.
TL;DR
- What shipped:
- The AI Emission Estimator, a flow that takes a line item from a bill of materials and returns a matched emission factor with a confidence score and a source trail, so a non-expert can accept or reject it on evidence rather than faith. Prototyped and launched in under six weeks.
- What I owned:
- The end-to-end interaction model the two suggestion modes, how confidence and provenance are surfaced, override behaviour, and admin-side plan gating. What I didn't: the matching engine, which is Climatiq's Mapping Agent, integrated by our backend team.
- In all honesty:
- The strongest numbers here are third-party published; the time-saving figure is from moderated testing, not production instrumentation. Both are labelled as such below.
The stakes, and the tension I had to resolve
When a supplier can't provide a carbon footprint for a component, teams fall back on secondary data proxy emission factors from reference databases. Picking the right one is specialist work: it needs sustainability knowledge most procurement users don't have, and it scales badly across a large bill of materials or a portfolio whose material composition keeps changing.
“I spend more time hunting for emission factors than making real decisions.” - procurement manager, workflow review
SiGREEN's strategy lead framed the goal as an entry-level tool, publicly, on the record one that stays “easy to use even with very little domain know-how.” Read as a design brief, that pulls in two directions at once.
The promise
The obligation
A component name in, a carbon number out. Every step added between those two erodes the reason to use it at all.
The obligation
This data feeds PCFs that are shared with customers and, in some markets, regulators. A wrong match a user can't see is a liability, not a shortcut.
My role, precisely
Sole design owner on the feature, working with a Product Owner, I owned how suggestions are presented, how confidence and data provenance are communicated, what happens on an override, and how admins gate access by plan. I ran the workshop that aligned the PO on rollout and pricing tiers, and scoped fallback UI with the front-end devs.
I did not own the matching algorithm. That is Climatiq's Mapping Agent, integrated via API by our backend team. My job started where its output arrived on screen including the cases where that output is uncertain, slow, or wrong.
At a glance
- Role
- Sole design owner
- Team
- 1 PO1 System Architect2 FE1 QA
- Data partner
- Climatiq (public integration)
- Delivery
- Prototype → launch in < 6 weeks
Decisions & trade-offs
Three forks where I chose a direction and gave something up:
Fork 1
Surface confidence and source on every suggestion not just an “AI” label
The engine returns a match confidence score and a source trail. The cheap option was to hide both behind a generic “AI suggested” tag and keep the row clean. I made both first-class in the UI instead.
- Gave up
- Visual simplicity two extra data points on every row, and a longer scan.
- Traded for
- A suggestion a non-expert can actually judge. Given the output can end up in a compliance report, an unjudgeable suggestion isn't a feature, it's a risk.
Fork 2
Two modes → Best Match and Multi Suggest, rather than one
A single best-guess mode is faster to design and ship, and fits the “one click” promise more neatly. I argued for a second mode that surfaces a ranked list of alternatives.
- Gave up
- A single clean path, and the extra build cost inside a six-week window.
- Traded for
- A way out on ambiguous or unusual components exactly the cases where one best guess is most likely to be wrong and least likely to be caught.
Fork 3
Modals over side-drawers, forced mid-project
Drawers were the pattern we'd validated for reviewing suggestions without losing page context. Development constraints ruled them out after validation, not before.
- Gave up
- Context preservation, the main reason we'd chosen drawers.
- Traded for
- A modal restructured around progressive disclosure, so the pattern's worst failure mode a wall of unranked data didn't ship with it.
The whole design problem sits in that gap. Automate the hunting; do not automate the judgement. Everything below is a consequence of that call!
The craft
The screen a procurement user actually works in: 1. Identify the component 2. Choose Best Match or Multi Suggest 3. Review each suggestion with its confidence score and originating dataset before applying it. The score and the source sit at the same level as the factor name, because deciding whether to trust a match is the real task. Applying it is the easy part.
The requirement that went back upstream
Reviewing suggestions surfaced a gap that wasn't ours to fix. Users working inside a specific dataset needed to constrain results to that dataset before matching otherwise the confidence score is answering a question they didn't ask. No amount of interface work solves that; the filter has to exist in the engine.
We took it to Climatiq as an early-adopter requirement. Pre-filtering emission factor results by data source now ships in Mapping Agent, and Climatiq credits the SiGREEN team's collaboration with shaping that release. It's the part of this project I'd point to first: the useful output of design work here wasn't a screen, it was a correctly-scoped requirement placed with the team that could actually build it.
Outcomes, and how each one is evidenced
Every figure carries its provenance. Nothing here is stated more precisely than the evidence behind it supports.
- VerifiedPublished by a third party
- MeasuredObserved in my own testing
< 6 weeks
Prototype to production launch, including a new third-party API integration
Source: Climatiq's published SiGREEN customer story. The compressed timeline is why the trade-offs above were decided in weeks, not quarters.
3× faster
Emission factor matching versus the average LCA tool, per the partner's benchmark
Source: Climatiq's published benchmark of Mapping Agent. Not my claim: this measures the engine, not my interface. My job was to design a review flow that didn't spend the advantage back on friction.
1 engine change
Source pre-filtering shipped into the partner's product after SiGREEN early-adopter feedback
Source: Climatiq's customer story credits SiGREEN collaboration with shaping this release.
80+ datasets
Emission factor datasets reachable through the integration, each surfaced by name on the suggestion
Source: Climatiq's published data coverage. Relevant to design because dataset breadth is what makes provenance labelling load-bearing rather than decorative.
~3–5 min → ~1 min
Time to complete one secondary-data entry, before and after the AI-assisted flow
How: moderated task timing in usability testing, small participant group. Not a production A/B result no in-product timing was instrumented, which I'd change (see below).
2 modes
Best Match and Multi Suggest Both shipped to production
How: shipped scope, confirmed in release notes. The second mode is the one I had to argue for.
Sources - Verify anything on this page
What I'd do differently
Next time, I'd track real usage time from the start. My result cutting entry time from 3-5 minutes to about 1 minute is real. But it came from a test, not real use. This is my biggest win, so it's odd that it has the weakest proof. Tracking real use would've taken few extra days. But it would've given me stronger numbers.
I'd also check if engineers can build a design at the same time as testing it with users not after. We tested drawers with users first. They liked it. Then we found out engineers couldn't build it in time. Switching to modals ate into our tight six-week timeline. Lesson: don't test a design users love if no one's checked it can be built.
I'd instrument in-product timing from day one. The 3–5 minutes to about a minute result is real, but it's a lab number, and the strongest claim I can make about my own contribution is therefore the softest number on this page. A live baseline before launch would have cost a day and given me a production-grade figure instead.
I'd also scope technical feasibility in parallel with the first round of concept validation. We validated drawers with users before we knew they were buildable, and adapting to modals cost time inside an already compressed six-week window. Validating a pattern engineering hasn't sanity-checked is testing a hypothesis you can't act on.
There's more detail than fits on a page.
The failed drawer concept, the low-confidence and no-match states, the pricing-tier workshop, and how the source-filter requirement got scoped Happy to walk through all of it live.