AI Reporting Sustainability

green and yellow trees near mountain under white clouds during daytime

Book a 15' Call

Nanda Dias

Product Strategic Design

UX Design, AI, Leadership

Nanda Dias Design

AI-Powered Sustainability Reporting for SAP Sustainability Control Tower ®

As Product Design Lead on a flagship AI sustainability reporting tool at SAP, I ran design and engineering in parallel and tested a deliberately minimal first version on real customers' live data. That approach avoided a significant rework cost and accelerated delivery.

Role & Approach

Our customers were heading into their first mandatory CSRD reporting year, and a regulatory first year is when a company decides, once, how it will do this reporting from then on. Miss that window by six months, and the situation changes. By then, the company has likely already solved the problem themselves, with spreadsheets or a consultancy. You are no longer filling an empty gap. You are asking them to replace a process they already built.

Building the wrong version first would have meant a significant rework cost and a material delay, on a flagship AI product already under scrutiny from customers sceptical of AI. Trust costs more to win back than to earn, and enterprise customers talk to their peers. So the brief was never simply to ship fast. It was to ship fast and not damage trust.

I led design strategy, orchestrating across a PM, Head of Engineering, ML engineers, an internal Design and AI Ethics Team, innovation researchers, and sustainability experts. Sustainability reporting was new territory for our team, so my scope started with learning the domain from scratch alongside running customer research, then moved through validation into shaping the production feature.

Decisions and Actions

Aligned with engineering on a parallel timeline: they built a rough proof of concept while our design team learned sustainability reporting and ran customer research, so progress didn't stall on sequencing. The alternative, discovery first and build second, is the exact pattern that earns design its reputation for slowing things down, and it would have cost months we did not have.
Managed expectations with our PM team and communicated to customers that the first testable version was deliberately minimal, we were testing assumptions, not polish.
Ran task-based usability testing with beta customers on their own production data, the only route to real critique of the AI's output quality rather than opinions about the interface. I presented the main findings to senior leadership.
Made two deliberate bets on how to spend a limited timeline: ship something intentionally incomplete first to learn fast, then invest the time that saved into the one feature too expensive to get wrong later.

Prototypes & Main Findings

This project is still live, so some detail stays under NDA. What's shown here is everything I can share publicly. I'm always happy to talk through more of my work on a call.

Role & Approach

Decisions and Actions

Aligned with engineering on a parallel timeline: they built a rough proof of concept while our design team learned sustainability reporting and ran customer research, so progress didn't stall on sequencing. The alternative, discovery first and build second, is the exact pattern that earns design its reputation for slowing things down, and it would have cost months we did not have.
Managed expectations with our PM team and communicated to customers that the first testable version was deliberately minimal, we were testing assumptions, not polish.
Ran task-based usability testing with beta customers on their own production data, the only route to real critique of the AI's output quality rather than opinions about the interface. I presented the main findings to senior leadership.
Made two deliberate bets on how to spend a limited timeline: ship something intentionally incomplete first to learn fast, then invest the time that saved into the one feature too expensive to get wrong later.

Design Iterations & Learnings

Bet one: ship something we knew was incomplete. Assumption mapping ranked what we were least certain about, and we scoped the first version to almost nothing: a search input, a single action, one generic report template. Testing it on real production data surfaced four failures we had not predicted:

System feedback was too opaque for anyone to trust the AI was working, fixed with real-time status messaging.
Error states exposed raw technical codes instead of guidance, rewritten in plain language.
The report format was rigid enough to push people off-platform to edit, so we broke the static report into editable modular sections.
Nothing distinguished AI-generated content from the user's own data, which in an audit context is not a polish problem, so we added visual indicators for AI-generated content.

Catching all of it at low fidelity, before the harder infrastructure existed, avoided a substantial amount of rework.

Bet two: spend the time that bought on the expensive thing. With the core experience validated, we invested in structured multi-stakeholder workflows, the sort of feature that is brutal to unwind if it sits on unproven assumptions. Service blueprinting across several lines of business, always including C-level and Sustainability stakeholders, made cross-team handoffs visible before we built them. Validation also showed that a report's sections belonged to different areas of expertise, so each expert reviewed only their own part. The result: configurable report structures, role-based editing, automated handoff notifications, and a single in-product source of truth.

Reflections

We brought our internal AI-ethics team in from day one. Their core rule: no AI-generated content reached a document without human review first, so one named expert always owned what got signed off, not the AI unsupervised in front of an auditor. The per-section review and approval trail from Bet two is what made that enforceable in practice: AI-generated content never reached anyone outside the process, an external auditor or a colleague not involved in making the report, without a named expert signing off on it first. Many people working in sustainability are conscious of AI's own environmental footprint and sceptical of products that add AI as a feature rather than a genuine value driver, so we held ourselves to justifying the AI by the value it created rather than by its presence. The early signal was roughly a 10x reduction in the estimated hours to produce a report. I left the team before that could be validated at scale, so I treat it as a strong early signal and not a proven figure.

The lesson I'd carry into the next one: describe this kind of decision by what it buys, not by what it tests. I framed the incomplete-first-version call internally as testing assumptions before building, which invited the reading that design was the brake. Calling it what it actually was, buying back the time for one throwaway version, would have met far less resistance, and it was the more accurate description of what happened.

What held throughout both bets, and mattered more than either number, was customer trust. It went up, not down, meeting our leadership's most valued point from the start.

This project is still live, so some detail stays under NDA. What's shown here is everything I can share publicly. I'm always happy to talk through more of my work on a call.

Outcomes

Faster to Market

Validating at low fidelity prevented one to two rework iterations, in a market where the regulations would not hold still long enough to rebuild.

Strong Beta Adoption

Beta customers committed post-launch, each having tested on their own live data. On a launch where the real risk was reputational, that was the number that mattered.