SecureShare
End-to-end design for a confidential emissions data exchange platform. Built the IA, data models, dashboards, and hotspot analysis for enterprise compliance workflows.
Contraints, User, & Stakeholders
Carboledger is an early-stage enterprise B2B SaaS platform for sustainability compliance and carbon data management. 16 people total (including marketing, sales and operations). I was founding designer. The product operated under GDPR, SOC II, and ISO 27001; not as checkbox compliance but as hard constraints on what data I could collect during user research, how sessions could be recorded, and what information the product could store about users. The data that is being shared is highly confidential, so they need assurance that their data is not being used other than intended purposes. Thousands of datasets is currently being managed over emails and spreadsheets.
Requirements arrived as compliance framework references, domain jargon, and vague stakeholder notes. There was no design system, no design manager, no prior UX direction to inherit. Every major decision, what to build, how it should behave, which regulatory constraints to encode as product guardrails, was mine to own and document. I also had to make sure all of the non-technical stuff is being translated correctly to the engineering team, and their technical jargon to non-technical stakeholders.
The product was designed for following three primary stakeholders:
1. The Sustainability Manager (Primary User / Buyer) A mid-to-senior professional at a manufacturing or trading company responsible for scope 3 emissions reporting. They run supplier campaigns, manage the product portfolio, and are accountable for PCF data quality. They're time-pressured, dealing with multiple suppliers across regions simultaneously, and frustrated by inconsistent data formats and slow supplier responses. They need control, visibility, and automation.
2. The Supplier Sustainability Contact Often a sustainability coordinator or even a general operations contact at a supplier company, someone who may not have deep PCF expertise. They receive a data request, may not know what PACT or ISO 14067 requires, and are juggling this alongside their day job. They need the process to be as simple as possible: clear instructions, flexible document upload, and ideally a guided calculation tool if they don't have their own emissions data.
3. The Customer Procurement / Sustainability Analyst A buyer-side analyst at the company purchasing from the User. They need PCF data to feed into their own scope 3 reporting or supplier assessments. They're not on the platform day-to-day, they access it via a shared link, want the data in a format they can immediately use (Excel export), and expect to see products named the way they know them. Trust and data reliability matter a lot to them.
What was actually breaking
Enterprise clients needed suppliers, external organisations that were not Carboledger customers, to submit structured compliance data such as product specifications, emissions values, certifications, and supporting documents. There was no dedicated product surface for this workflow. Everything was managed through emails and spreadsheets.
The submitted data was then used to calculate emissions for the goods enterprises manufactured and sold to their own customers. Because of this, enterprises needed complete control over how data was structured, validated, shared, and reused across workflows. That level of control was nearly impossible to maintain through fragmented email threads and spreadsheet-based coordination.
The product was built for sustainability experts managing emissions data across multiple industry-standard formats from hundreds of suppliers and thousands of raw materials sourced over the previous year.
The challenge was that every supplier followed their own methodology for preparing and sharing data, making the collection process highly inconsistent and difficult to standardise.
On the other side, when users needed to share their own data with customers, the system had to present information in a format that was easy for external stakeholders to understand, while still giving users complete control over what data was shared, structured, and exposed.
The result: request cycles lasting 6–8 weeks. Hundreds of hours spent coordinating, chasing, reformatting, and re-requesting data.
A single supplier request could involve weeks of back-and-forth coordination across emails, spreadsheets, PDFs, and multiple stakeholders. Suppliers often submitted incomplete datasets, incorrect regional calculations, unsupported formats, or missing verification documents, forcing enterprise teams to manually validate, reformat, and repeatedly follow up before the data could actually be used for emissions calculations or customer reporting.
The result was request cycles stretching from 6 to 8 weeks, with hundreds of hours spent coordinating suppliers, chasing follow-ups, reformatting submissions, and repeatedly requesting missing or incorrect data. There was no reusability in the process. Even if a supplier had previously submitted the same data, teams often had to request it again because nothing was stored in a structured or queryable way. The workflow also lacked auditability and visibility. Enterprise users had no reliable way to track submission status, identify bottlenecks, or manage progress across 10 to 30 active suppliers simultaneously.
Designing for Conflicting Workflows and Constraints
The challenge was not simply designing a better form. It was designing a system that could reduce the operational burden created by multiple stakeholders with completely different goals, workflows, and constraints.
For sustainability managers, collecting and sharing data was not the actual job. Their core responsibility was helping their organisation reduce emissions across the products they manufactured and sold. But in practice, they were spending significant time coordinating suppliers, validating submissions, following up on missing information, correcting formatting issues, recalculating values, and preparing reports for customers.
Suppliers had their own operational challenges. Many were not mature enough to have structured sustainability reporting practices in place. Preparing data often required them to coordinate internally across sales, operations, and sustainability teams to understand which products had been sold, in which regions, and under what reporting methodology. Even when suppliers submitted data, important fields were often missing, inconsistent, or incorrectly scoped.
This created constant context-switching and coordination overhead for enterprise users. A common failure case was suppliers submitting emissions data for the wrong manufacturing region. For example, a customer may have required data specifically for products sourced from North America, but the supplier submitted data calculated for Asia operations instead. The enterprise user then had to identify the mismatch, communicate the issue, and restart the request cycle.
At the same time, enterprises needed strict control over how data was shared externally. Sustainability and supply chain data was commercially sensitive, and incorrect handling could create compliance risks, damage trust with customers, or even affect public perception of the company. The system therefore had to balance ease of contribution for external suppliers with strong controls around data visibility, accuracy, auditability, and confidentiality.
What I built and why
I designed SecureShare as a collaborative data exchange system that allowed external suppliers, who were not part of the Carboledger ecosystem, to securely submit sustainability and compliance data without requiring access to the internal platform.
One of the core design decisions was reducing the operational burden on suppliers. Different suppliers had different levels of sustainability maturity. Some already had structured reporting systems, while others were still managing everything manually through spreadsheets and PDFs. Instead of forcing every supplier into a rigid workflow, the system was designed to accept data in multiple formats and adapt around existing supplier behaviour.
For suppliers already creating sustainability reports in PDFs or spreadsheets, we reduced manual data entry by allowing them to upload existing documents directly. The system extracted and mapped relevant fields automatically, then asked users to verify the information before submission. This significantly reduced submission effort while improving data consistency for enterprise users downstream.
The workflow also accounted for the reality that sustainability data rarely exists with a single person. Suppliers often needed inputs from multiple teams across different countries, including sales, operations, procurement, and sustainability departments. To support this, the platform enabled distributed collaboration so multiple stakeholders could contribute to the same request without relying on fragmented email coordination.
To reduce supplier drop-off during long request cycles, the platform automated reminders, deadline management, and follow-up workflows. Enterprise users could track detailed request statuses across suppliers, products, and raw materials, helping them identify delays, incomplete submissions, and incorrect datasets early in the process. In cases where automation was insufficient, users still had the visibility needed to perform manual follow-ups effectively.
Once data was collected, the system standardised and structured it into ready-to-use formats that could be exported directly into Excel or integrated with external enterprise systems for downstream emissions calculations and reporting workflows.
Another major design challenge was balancing ease of sharing with enterprise-grade control over sensitive data. Companies needed confidence that commercially sensitive sustainability information would remain secure and only be used for its intended purpose. The system therefore provided granular controls over what customers could access, how data was shared, and which datasets remained private. Transparency was also built into the contributor experience so suppliers clearly understood how their data would be used before submission.
To further reduce operational fragmentation, I also designed an in-platform communication workflow that allowed enterprise users and suppliers to collaborate directly inside the product instead of switching constantly between emails, spreadsheets, and external tools.
Beyond compliance workflows, the platform also enabled suppliers to suggest lower-emission alternative products to customers, helping support broader emissions reduction initiatives across the supply chain.
The Alias System — solving fragmentation across supply chains
What initially looked like a simple naming problem turned out to be a much deeper operational and data consistency challenge.
The same product was often referred to differently across suppliers, customers, regions, internal teams, and historical records. A product purchased from one supplier in 2024 could appear under a different name in 2025 after a formulation update, internal renaming, or regional variation. Customers also frequently recognised products using their own internal naming conventions rather than the supplier's original product name.
This created major workflow problems across the platform.
Enterprise users struggled with duplicate products being created unintentionally because teams searched using internal aliases instead of canonical product names. Bulk uploads often failed because uploaded Excel templates contained alternative naming conventions that did not match existing records. Searching, updating calculations, and maintaining historical product records became increasingly difficult as datasets scaled across suppliers, regions, years, and reporting formats.
The challenge became even more complex during customer data sharing workflows. While enterprise users needed internal consistency and traceability, customers needed to see product names that matched the terminology already used inside their own procurement and reporting systems.
To solve this, I designed a multi-layer alias architecture that separated product identity from product presentation.
The system maintained a canonical internal product record while supporting:
- Customer-specific aliases
- Internal team aliases
- Historical product naming
- Supplier naming variations
- Region-specific naming conventions
This allowed the same underlying product calculation to remain structurally linked across workflows while still being presented differently depending on the context and audience.
For customer sharing workflows, users could assign customer-specific aliases so external stakeholders only saw the naming conventions familiar to them. Internally, teams could still search, update, and manage calculations using their own operational terminology without creating duplicate records.
The alias system also improved bulk upload reliability by mapping uploaded product names against existing aliases instead of relying only on exact product name matches. This reduced duplicate entries, improved searchability, and made year-over-year calculation maintenance significantly more manageable.
The result was not just better naming consistency, but a system that could preserve data continuity across changing suppliers, regions, reporting standards, internal workflows, and customer relationships without breaking usability.
Multi-User Roles — balancing collaboration, ownership, and control
The challenge was not simply creating a permissions matrix. It was designing a system that allowed multiple teams, departments, and stakeholders to collaborate on highly sensitive sustainability data without losing accountability, security, or operational clarity.
Enterprise sustainability workflows are rarely handled by a single person. Different teams are responsible for different parts of the process, collecting supplier data, reviewing calculations, validating compliance documents, exporting reports, managing customer sharing, or maintaining internal records. At the same time, not every user should have access to everything.
The complexity increased further because organisations often operated across multiple workspaces, suppliers, customers, and reporting periods simultaneously. A single user could belong to multiple workspaces with different responsibilities in each one.
To support this, I designed a flexible multi-user role system that balanced collaboration with granular access control.
The system introduced layered roles including:
- Super Admins with organisation-wide control
- Workspace-level members with restricted visibility
- Admins responsible for operational workflows
- Members with task-specific permissions
Instead of relying on rigid predefined roles alone, the platform allowed enterprises to customise access based on operational responsibilities. Organisations could control whether users were allowed to:
- Send supplier requests
- Share customer data
- Edit calculations
- Export datasets
- Manage workspace members
- Access historical records
- Configure sharing permissions
Workspace architecture became an important part of the UX design. Teams needed the flexibility to isolate workflows by department, customer, supplier group, or operational unit while still collaborating inside the same system. Workspace members could only access products and calculations explicitly shared within their workspace, reducing unnecessary exposure to sensitive data.
One of the key design goals was making permissions understandable without overwhelming users with enterprise complexity. Sustainability managers needed confidence that sensitive customer and supplier data remained protected, while still allowing teams to move quickly across operational workflows.
The result was a role system that supported enterprise-scale collaboration while maintaining clear ownership, controlled visibility, and trust across highly sensitive compliance workflows.
Workspace Members — reducing internal coordination overhead
One of the key discoveries during research was that sustainability data workflows were not handled by a single team alone.
While sustainability managers were responsible for collecting, validating, and sharing Product Carbon Footprint (PCF) data, they constantly depended on other internal teams throughout the process. R&D teams were involved in validating product compositions, procurement teams helped coordinate supplier information, operations teams verified sourcing regions, and compliance teams reviewed reporting requirements before data could be shared externally.
But despite this dependency, most collaboration still happened outside the platform through spreadsheets, forwarded emails, Slack messages, and disconnected approval chains.
This created several operational problems:
- Teams lost context when switching between tools
- Data ownership became unclear
- Different departments worked on outdated exports
- Sensitive calculations were shared manually across emails
- Sustainability managers became bottlenecks for every request
Initially, I explored simpler collaboration approaches where all internal users operated within the same shared environment. But research sessions revealed that organisations needed more controlled collaboration boundaries. Not every internal team required access to all suppliers, calculations, customers, or historical records.
This led to the workspace architecture.
I designed workspaces as controlled internal collaboration environments where enterprise users could organise and share relevant datasets with specific teams without exposing the entire system.
For example:
- R&D teams could access only the product calculations relevant to formulation analysis
- Procurement teams could track supplier-related workflows
- Compliance teams could review reporting documentation
- Regional teams could operate independently within their own workspace
Users could also belong to multiple workspaces simultaneously depending on their responsibilities across the organisation.
A major design challenge was balancing flexibility with simplicity. Enterprise permission systems often become difficult to understand because of deeply nested access structures. The goal here was to create enough control for enterprise-scale collaboration while keeping workspace behaviour understandable for non-technical operational teams.
The final workspace system reduced internal coordination overhead by centralising collaboration directly around the data itself instead of forcing teams to manage workflows across disconnected tools and exports.
Contribution Analysis Tool — identifying emission hotspots across products and suppliers
Once enterprise users collected Product Carbon Footprint (PCF) data from suppliers, the next challenge was understanding where emissions were actually coming from across their supply chain.
The purpose of the Contribution Analysis tool was to help sustainability teams analyse how different products, raw materials, suppliers, regions, and lifecycle stages contributed to overall emissions.
Instead of manually comparing spreadsheets and calculation reports, users could break down emissions data into structured comparisons directly inside the platform.
The tool allowed users to:
- Compare emissions across suppliers for the same raw material
- Identify which products contributed most to total emissions
- Analyse regional differences in emissions values
- Understand how individual lifecycle stages impacted overall calculations
- Compare historical calculations year over year
- Detect anomalies or unusually high emission values
- Evaluate lower-emission alternative products suggested by suppliers
The system also surfaced supporting calculation details, methodologies, verification documents, and underlying assumptions used in the PCF calculations so users could validate the reliability of the submitted data before using it in reporting or customer-sharing workflows.
This helped sustainability teams move beyond simply collecting emissions data toward actually using it for supplier evaluation, operational decision-making, and emissions reduction initiatives.
What changed
The platform reduced enterprise request turnaround time from 6–8 weeks to under 8 hours in high-volume workflows by replacing fragmented email coordination with a structured end-to-end data exchange system.
More than 470 hours of coordination overhead were eliminated per request cycle by automating supplier follow-ups, standardising data collection, reducing manual formatting work, and centralising collaboration between suppliers, customers, and internal teams.
The supplier submission experience significantly reduced operational friction. Instead of manually filling large forms, suppliers could upload existing PDFs, spreadsheets, and supporting documents directly into the platform, allowing the system to extract and structure the required data automatically. This improved submission completion rates while reducing supplier drop-off during long request campaigns.
The alias architecture reduced duplicate product creation and improved reliability during bulk uploads by mapping internal, supplier, and customer-specific naming conventions to the same canonical product records. This made historical calculation management and year-over-year reporting significantly easier for enterprise teams.
The workspace and multi-user permission system enabled organisations to collaborate securely across sustainability, procurement, R&D, compliance, and regional teams without exposing sensitive datasets unnecessarily. Teams could operate independently while maintaining shared visibility into calculations, supplier requests, and customer-sharing workflows.
The platform also increased trust and transparency across the supply chain. Suppliers retained clarity around how their data would be used, while enterprise users gained granular control over customer access, export permissions, historical calculations, analytics visibility, and data-sharing timelines.
More importantly, sustainability teams were finally able to spend less time coordinating spreadsheets and follow-ups, and more time focusing on actual emissions reduction initiatives.