Overview
Problem
Goals
Research
Process & Ideation
Final Solution
CarbonHub
Through a prior project, EnergyCAP gained the ability to generate scope 1 and 2 emissions automatically from utility bills. However customers still lacked a way to track all emissions, including manually entered data and emissions not tied to utility usage (especially scope 3).
CarbonHub was created as a standalone application that works with or without EnergyCAP to support complete, flexible, organization-wide emissions tracking.
Role: UI/UX Designer
Team: 2 UX Designers, PM, Engineering Leads, 1 SME
Tools: Figma, Miro, Maze
Organizations needed a centralized, flexible system to track all emissions—not just those generated from utility data. EnergyCAP’s existing workflows supported utility-driven scope 1 and 2 emissions but offered no way to manage additional emissions types or create custom reporting structures. As a result, many organizations relied on spreadsheets or external tools, creating fragmented workflows, inconsistent reporting, and a lack of visibility across their full emissions picture.
Our goal was to create a standalone application that could ingest EnergyCAP-generated emissions, while also allowing users to manually enter and manage any type of emissions data. CarbonHub needed to offer a flexible hierarchy that could adapt to varying reporting structures, support all emissions types, and maintain enough familiarity with EnergyCAP to minimize onboarding friction for existing customers.
Domain Learning
Our team had limited emissions experience, so we began by learning the fundamentals of emissions calculations, reporting terminology, and how different emissions types are categorized and recorded. This foundational understanding guided our early decisions and ensured that our structure would be accurate and credible.
Competitive + Standards Analysis
I reviewed a range of ESG and sustainability platforms to understand how they structured emissions, what they prioritized, and how they presented data. In parallel, I evaluated standards from CDP, GRI, EPA, SASB, and AASHE. This helped clarify common data requirements, reporting expectations, and the terminology users would expect to see inside CarbonHub.
User Interviews
We spoke with EnergyCAP users across higher education, government agencies, and corporate sustainability teams. These conversations surfaced three consistent themes: some organizations wanted to mirror their existing EnergyCAP facility structure, others needed completely custom hierarchies, and reporting expectations varied significantly depending on the governing body or internal audience. These insights made it clear that CarbonHub needed to be flexible enough to support multiple reporting models while still feeling approachable to existing users.
Comparing Industry Models to EnergyCAP
Early in the project, we analyzed how ESG platforms organize emissions and compared those structures to EnergyCAP’s established hierarchy of organizations, meters, and bills. We needed a solution that supported industry expectations but didn’t stray so far from EnergyCAP’s existing paradigm that users or engineers would struggle with it. This comparison helped determine the balance between flexibility and familiarity.
Defining the Structure Before UI Work
CarbonHub required a clear structural model before any interface design could begin. Working closely with our SME, PM, and engineering lead, we defined how emissions should be grouped, stored, and reported based on industry standards and EnergyCAP's data model. We mapped emissions to familiar concepts, such as treating sources like meters and records like bills, which allowed us to build something new without abandoning patterns users already understood.
Designing Around Reporting Realities
As we explored emissions reporting requirements across different standards, we refined which data attributes CarbonHub needed to support and how roll-ups should behave within a hierarchy. During this phase, I learned how emissions calculations work and how they inform reporting, ensuring our UX supported users’ real workflows rather than theoretical ones.
Visual Exploration
Once the structure was established, we explored layouts, navigation patterns, and data visualizations. Because CarbonHub was a second application meant to work alongside EnergyCAP, we aimed for consistency in visual language while allowing CarbonHub to establish its own identity. The challenge was ensuring the two applications felt related, part of the same ecosystem, but differentiated enough in purpose and functionality. Our visual exploration focused on creating a familiar yet modern extension of the EnergyCAP experience.
Key Insight
The breakthrough moment came from embracing EnergyCAP’s existing object metaphors. Aligning CarbonHub’s structure with meters, bills, and organizations made onboarding intuitive for EnergyCAP users while still supporting emissions data in a more flexible and comprehensive way. This approach strengthened internal alignment between design and engineering and reduced cognitive load for users adopting the new system.
CarbonHub introduced a flexible hierarchy built around Collections, Sources, and Records, allowing organizations to create structures that fit their reporting needs rather than forcing them into a facility-based model. Users could manually enter emissions data or supplement EnergyCAP-generated emissions, enabling them to account for all emissions types, including those not associated with utility usage. The interface followed familiar EnergyCAP patterns, such as hierarchical navigation and object-based workflows, while incorporating modern visual elements and widgets designed specifically for emissions reporting. Integration with EnergyCAP allowed utility-based emissions to flow in automatically while still enabling CarbonHub to stand on its own.
