Module Redesign
SINAI • Product Redesign • User Research • AI Design • B2B
Getting enterprise emissions data into SINAI, from a buried expert-only workflow to one page and an AI uploader
Role
Product design lead
Timeline
~ 1 year
Scope
Research, information architecture, interaction design, AI experience design, prototyping, hand-off
Overview (TL;DR)
SINAI makes decarbonization tracking and carbon accounting software for heavy-emitting industries. Its customers manage large volumes of data from many facilities and complex sources, and report it to regulators.
Measure is where every customer enters the activity data behind that reporting. It was our biggest blocker in sales, the most-cited reason for low NPS, and where users bounced most (70–80%). Over about a year, I led its redesign in phases: consolidating data from a five-level hierarchy into one page, replacing a three-page form with a single side panel, and designing an AI-assisted bulk uploader. The first version of the uploader failed. The second one worked.
Outcome: 50+ point NPS increase; bulk upload success from ~20% to 83%; nearly all churn-risk accounts renewed
Problem
Measure was designed for technical climate experts, and it showed. To add data, users clicked down through Business → Business Unit → Facility → Source → Data collection page, then filled in a legacy form that ran three pages in a table layout that didn't match how people thought about their data.
The business cost was clear:
-
Sales: Measure was the biggest blocker, and prospects ruled us out on UX
-
Retention: several customers were threatening to churn
-
Satisfaction: it was the most-cited reason behind low NPS
-
Engagement: bounce rates of 70–80%, the highest in the product
Fixing it was part of why I was hired.
How might we let anyone on a customer's team get large volumes of emissions data into SINAI quickly and accurately, without needing to be a climate expert?
Team and constraints
My role
I led design end to end, from research through hand-off. I started as the only designer on the project and later led a junior designer through the later phases.
The team
a PM, front-end and back-end engineers, an AI engineer, and an in-house climate expert who kept us honest on GHG methodology.
Scale
Large customers had hundreds of thousands of records, so any view had to load, filter, search and manage data at that volume.
Ripple effects
Every record fed calculations upstream and downstream, so a single change had to be reflected everywhere.​
A fixed data structure
The legacy model didn't lend itself to change, so I had to redesign the experience around it rather than start fresh.
Compliance
The product had to meet GHG Protocol reporting standards (Global and Brazil) and SOC 2 security requirements.
My thinking
I couldn't change the data model, so in moving forward I needed to change what people had to see of it. The constraint pushed us toward separating how data is stored from how people work with it.
Discovery and research
I used three sources, each building on the last:
Method 1
Customer Success and Sales feedback
We received feedback from both teams that Measure was costing us deals and risking customer churn. The product manager and I reviewed meeting transcripts and talked extensively with team members to understand more.
Method 2
Usage data
To validate the sales and CS feedback I dug into our usage data with Amplitude and Metabase, confirming the 70–80% bounce rates. This also showed where people dropped off.
Method 3
User interviews
We now knew that there was a problem, and where it was. We used interviews to guide us to possible solutions. About 20 users across two personas: climate experts, and the colleagues they asked to enter data. The verdict was consistent: the system was far too complicated.
What I learned. Two assumptions the product was built on were false:
Assumptions
Only technical climate experts enter data
Each person manages data for one source
Findings
Climate leads delegated data entry to people in operations, finance and engineering. Entering data was their only task, so the rest of the product meant nothing to them and they got lost.
People regularly managed many sources, so they had to navigate back down the hierarchy again and again.
This gave me two distinct personas to prioritize
Climate Experts: needed details and roll-ups
Highly technical, subject matter expert, wants to get into the details, works in the product regularly, adds, is responsible for reporting carbon emissions, and reviews, and approves data
Data Enterers: needed in and out of the product as easily and quickly as possible
Unfamiliar with climate-science terminology, responsible for a handful of subject areas that need to be reported on, rarely in the product, in charge of adding data
I used all of this information to map out exactly what is going wrong, and where
Explorations and solutions
This was a long and complex project, so I needed to weigh the options against each other, but also prioritize the solutions we were narrowing in on. Sometimes that meant prioritizing a solution that would just ease some frustration while we worked on something more robust.
Here are some of the options I explored
Shortcuts in the hierarchy:
Shareable custom URLs for every data page, plus breadcrumbs
Tradeoff:
Quick win, but falls very short in solving the broken up data and requires users to manage several URLs
Simplified data entry page:
Narrowed down data entry for non-technical users
Tradeoff:
Would help for the data enterer persona, but required significant development only for users not often in the product
Consolidated data page:
Rollups stay in the hierarchy; all data moves to one table
Tradeoff:
Solved the navigation problem, but had to perform at hundreds of thousands of records on a fixed data model
Single side-panel form:
The three-page legacy table rebuilt as one panel, opened next to the data
Tradeoff:
Fixed single-record entry, but not bulk entry
What was implemented
Quick win: Custom URL and breadcrumb navigation
Custom URLs let a climate lead send a colleague straight to the right page, and breadcrumbs sped up navigation. They didn't solve the problem, but they gave customers relief while we built the real fix.
Separate the summary from the data
The key decision was to split out the information based on what a user needed to do on the page. The rollup pages stayed in the hierarchy, untouched, for climate experts. The data itself moved to one new page: a consolidated table of every record, with advanced filtering and search. Every add-data flow moved there too, so users could add, manage and see all their data in one place.
Pre-redesign hierarchy page
Post-redesign company data collection page
Fix the form
We replaced the legacy table style form with a single in-page side panel. It kept every input but put them in a more intuitive order, in context. With the consolidated table, the core workflow went from 8 pages and 3 forms to 1 page and 1 form.
Pre-redesign form
Post-redesign side-panel form
My thinking:
Shipping quick wins while planning the bigger change kept customers from leaving while we got it right. And leaving the rollup pages alone (aside from re-styling) meant climate experts kept what worked for them.
Iteration: from the form to AI
The form shipped, and NPS barely moved. The new form was adopted, but when we dug in, we saw we had solved the problem for data enterers and not for climate experts. They were still gathering data outside the system and uploading it in bulk. The legacy bulk upload meant downloading a complicated template, reformatting your data to match it, uploading, fixing errors and trying again. Only about 20% of uploads succeeded.
Interviews and error logs pointed to the same cause: users weren't struggling with their data, they were struggling to force it into our template. So we stopped asking users to adapt to our format and used AI to accept their data in whatever format they had.
My thinking:
Adoption told us the form worked. NPS told us it wasn't enough. When those two disagree, the gap usually means you've helped some users and missed others.
AI uploader - V1 (spoiler - it failed)
It was our first AI feature, and we tried to do too much with it. The idea behind the solution was to let users upload any document, any format, and our AI would pull out the relevant data and create records dynamically for the users. This was great in theory, but had several critical flaws. Adoption was low and the bounce rate was over 70%. Most telling, users didn't come back. Many tried it once and returned to the manual, error-prone template they hated.
The major issues were:
The uploader processed files out of sight, meaning users couldn't see what the AI was doing
There was no way to provide additional context
The AI had no way to ask about ambiguous data, and was prone to hallucinating values
AI uploader V2
AI uploader v2 made the AI's work visible and turned the upload into a conversation. Each design decision answers a specific v1 failure:
The uploader processed files out of sight, meaning users couldn't see what the AI was doing
V2 Solution:
The interface shows exactly how the AI interpreted and mapped the data
There was no way to provide additional context
V2 Solution:
A chat panel lets users answer questions, add context and fill in missing information
The AI had no way to ask about ambiguous data, and was prone to hallucinating values
V2 Solution:
The AI flags missing required fields and any changes the user needs to make before import. After import, an icon marks every AI-added record so users can review it later
It fits into the consolidated data page from the earlier phases. Users bring data in whatever format they have, review what the AI did, resolve gaps in the chat, and land in the same table where they manage everything else.
Impact and result
The measure redesign had significant, tangible business impacts:
Core workflow
Before: 8 pages, 3 forms
After: 1 page, 1 form
Bulk upload success rate
Before: ~20% (legacy template)
After: 83% (AI uploader v2)
NPS
Before: Measure was the top-cited detractor
After: 50+ point increase, driven by this work
Retention
Before: Several accounts threatening to churn
After: Nearly all churn-risk accounts renewed
Sales
Before: Prospects ruled us out on UX
After: Deals progressed further down the pipeline
Reflection and next steps
What I'd do differently
-
Scope AI v1 much smaller. It was our first AI feature, and I didn't yet know what designing for an AI experience looked like. I have a much better understanding of AI limitations and the significance of transparency in AI interactions.
-
Watch more real sessions. SOC 2 requirements made session recordings very difficult, so we leaned on interviews, error logs and usage data. I would pair more closely with our engineering lead and legal team to try to find a solution that allows us to remain secure and within compliance but supports us getting the data we need.
Next Steps
-
Bulk data editing. We solved major problems with getting data into the system, but now that we achieved doing so at-scale, we need better ways for users to edit and manage that data in the application