Embodied carbon indicator MVP
ROLE
Lead Product Designer
CLIENT
NSW Government / KPMG
Detailed view
TL:DR
Background
Buildings account for nearly 40% of global greenhouse gas emissions. Embodied carbon, the emissions locked into a building's materials before anyone switches a light on, makes up 11% of that total. Fewer than 1% of building projects currently calculate and report.
The data exists across the supply chain. It lives with dozens of different participants, captured in different formats, at different stages of a build. The NSW government engaged KPMG Origins to design a tool that could bring it together. I led the design.
The problem
Operational carbon has established reduction pathways and centralised data. Embodied carbon is harder because the data is distributed across developers, builders, subcontractors and manufacturers, each capturing different things at different stages.
There's also a timing problem. Embodied carbon reductions have the most impact at the design stage. Material substitutions happen constantly during construction, so as-built data is the only way to capture a building's true emissions footprint. The industry has no reliable way to collect it at scale.
That was the gap we were designing for.
Who I was
designing for
Three persona groups interact with trade documents on Origin, each with a different relationship to the problem.
Developer
Responsible for the overall project and increasingly accountable to tenants, investors, and regulators for ESG performance. Needs portfolio-level visibility across every active build, not just individual project snapshots.
Builder
Coordinates inputs across the supply chain and is responsible for what actually gets built. Sits at the centre of the as-designed vs as-built gap and has the most to gain from a tool that makes that data visible in one place.
Manufacturer
Holds the most granular data: material composition, carbon coefficients, recycled content. The platform only works if manufacturers can participate and submit directly, at low friction.
What the research
told me
I conducted 20 recorded interviews across all three persona groups, with findings clustered using affinity mapping. Three things came back consistently.
Data is fragmented and visibility is partial across the supply chain. Developers are working from incomplete pictures of what got installed. Builders are coordinating dozens of subcontractors with different systems. Manufacturers have the material data with no standardised channel to share it upstream.
A standalone carbon calculator created too much adoption friction. Every participant understood why embodied carbon mattered. Very few saw it as worth changing their workflow for on its own. Users wanted water, modern slavery compliance, recycled content, and recyclability in the same place.
The material data lives with the people who installed it. A tool that routes all submission through the developer puts the burden in the wrong place.
Persona profiles based on Interview findings
Developer
Goals & Responsibilities
Deliver quality buildings that stand the test of time, with sustainability built in from the start. Make sustainable practices accessible and costed-in by default, creating a level playing field so sustainability-led projects aren't reserved only for large players with the capital to spend on innovation.
Pain Points
A volatile regulatory landscape makes it difficult to stay informed and compliant
Data is collected manually through paper forms and delivery dockets, making it hard to manage
Slim margins push sustainability down the priority list
Limited market understanding of the longevity-versus-sustainability trade-off, and a weak business case for embodied carbon investment
Value Proposition of ECI
Developer-led adoption means embodied carbon costs are factored into contracts and tenders, allowing builders to price it into their proposals from the outset
Clear documentation requirements give builders certainty about what's expected to enable embodied carbon measurement
Compliance with EC data capture supports brand differentiation from competitors who aren't engaged
Builder
Goals & Responsibilities
Deliver high-quality buildings that uphold strong ESG practices, aligned with evolving market expectations, to advance sustainability initiatives and minimise emissions footprints.
Pain Points
Sustainability data is hard to collect, Environmental Product Declarations (EPDs) are the most reliable source, but they're inconsistent and not readily available
Information lives across multiple systems, making collation slow and labour-intensive
No single, holistic view of an asset's sustainability documentation or data trustworthiness
Building in sustainability considerations can add up to 2% to overall project costs
Value Proposition of ECI
Streamlined collection of upfront embodied emissions data, enabling a holistic view of the asset's footprint
Seamless integration with the BTI platform provides a unified data collection experience
Accurate visibility of potential offset requirements needed to meet Net Zero targets
Manufacturer
Goals & Responsibilities
Create high-quality, market-competitive products that support customers' sustainability journeys alongside their own.
Pain Points
High demand for EPDs, but generating them is resource-intensive and costly
Scope 3 emissions are difficult to calculate, limiting the insights manufacturers can share with downstream customers to help reduce emissions
Relevant data exists across multiple systems and locations but isn't easily collated
Value Proposition of ECI
Developers using ECI are more likely to request EPDs, giving manufacturers a route to differentiate from competitors
Easy EPD collection enables accurate measurement of an asset's upfront embodied emissions footprint, positioning manufacturers as preferred providers
Greater EC calculation accuracy by replacing conservative generic factors with actual supply chain data
Surfaces opportunities for embodied carbon improvement and ensures transparency in the ECI calculation.
The first concept scored 4.4/10
We built a lo-fi prototype (a landing page) of the Embodied Carbon Indicator and tested it across all three persona groups. Participants reviewed it section by section using an emoji rating system, letting us know what resonated and what didn't, then scored the overall concept out of 10.
4.4/10
The feedback was specific. Carbon data alone carried insufficient adoption weight. The as-built focus felt reactive, measuring something after the key decisions had already been made. Several participants pushed for a platform covering a broader set of ESG data types.
I took that as a new brief.
The pivot
From carbon calculator to building data platform where carbon is a feature within a broader building data platform, not a product on its own. Alongside warranties, MSDS sheets, installation records, compliance data, and the full participant chain, it becomes worth adopting.
KPMG Origins already had an existing Building Trustworthy Index product, which gave us a foundation to build on. I reframed the brief: instead of an Embodied Carbon Indicator, we’d design My Building Data, a whole-of-building component data tool treating carbon as one data layer among many.
The delegation model followed from the same thinking. Subcontractors and manufacturers submit their own component data directly, spreading the workload to the people who actually hold it.
The second round of testing scored 8/10
Users could immediately see the value and several came back with unprompted suggestions for extending it further, material sourcing, whole life cycle carbon, modern slavery compliance.
The platform had momentum.
What the pivot forced me to redesign
Reframing the concept surfaced requirements the original brief had missed.
Delegation had to be native. The platform needed to onboard the full supply chain and give each participant a direct submission path for their own component data.
Revit integration gave users a starting point. A material list derived automatically from a Revit file gives users a baseline of what was designed. As-built submissions fill in what changed during construction, so users start from something real.
The architecture needed to support more than carbon from day one. The system needed to be expandable across ESG data types and integrated with KPMG Origins’ existing track and trace platform from the start.
Initial ideation
The expanded scope included a full navigation overhaul and a new design system to keep the product consistent with the existing Origins suite.
Navigation testing
I created the core screens on Figma and created a lo-fi clickthrough prototype highlighting the navigation between pages. Using heuristic evaluation, I gathered 11 team members of varying exposure and experience to the product to complete simple user goals to see key pain points with the new navigation.
High Fidelity Screens
Once the navigation and content for each screen was agreed upon we began to create the high fidelity screens for further validation with users. This gave a clearer picture of the type of data they will consume and how they will consume it as well as details on data entry flows.
Two decisions from the iteration process stood out
Sankey chart to tree map. The building summary dashboard initially used a Sankey chart to show emissions flow. User feedback was consistent: visually interesting, hard to act on. A Sankey shows relationships and flows. Users needed to quickly identify the biggest contributors and drill into them. A tree map did that. The largest areas are visually dominant, every block is interactive, and the chart became something users worked with rather than looked at.
Static benchmarking to projection calculations. Showing total emissions against a benchmark is useful for a completed building. During an active build, users needed to understand where their building was tracking based on materials submitted so far, relative to as-designed targets. Projection calculations gave them that. In the portfolio view, the same logic extended into a net zero burndown chart showing where a developer’s full pipeline sits relative to 2050 targets. Map filters for geography and material type opened up a secondary use case around defect tracking across buildings sharing the same materials or suppliers.
Handover
I built a full design system in Figma using atomic design methodology, translated by the development team into reusable Storybook components. As the product grows, new screens stay consistent with the existing Origins suite without requiring a designer to review every decision.
Impact
The MVP was delivered to the NSW government and is now in wider validation, the first standardised embodied carbon tool commissioned at this level in the state.
The score moving from 4.4 to 8.0 between concept rounds reflects a willingness to hear that the original direction needed to change and act on it mid-project. That call shaped everything that followed.
What I learned
The hardest moment on this project was presenting a 4.4/10 score to a client and recommending a change in direction. The research was clear and the pivot to My Building Data came directly from what users told us.
A low test score is only a problem if you treat it as one.
What I’d do next
Data entry needs further simplification. Delegation solved the structural problem of who submits data. The submission experience itself still has friction, and it’s the most consistent piece of post-launch feedback.
Developers want more from the portfolio view, particularly forecasting tools that support procurement decisions earlier in the design process.
Connecting the platform more deeply to the Origins track and trace system would bring provenance, compliance, and carbon into a single supply chain view. The architecture supports it and it’s the natural next step.