B2B SaaS · Enterprise ESG Platform
Lythouse by Zycus: Designing ESG Workflows Enterprises Can Trust
Zycus, a global leader in procurement software, built Lythouse to help enterprises account for, report, and improve their ESG performance. I worked on the core workflows that make that possible: reviewing millions of dollars of Scope 3 emission data, routing it through configurable approval chains, and turning it into audit-ready compliance reports.
The Data Review overview: total emissions, spend, and coverage across every Scope 3 category.
Snapshot
Client
Zycus (Lythouse ESG Platform)
Studio
Feelpixel UX Studio
My Role
UI/UX Designer. Owned the Data Review, Emission Approval, and ESG Reporting workflows
Team
2 designers. I worked alongside the project lead, who owned client communication
Timeline
February 2023, around 4 to 5 months from research to delivery
Live At
lythouse.com
The Context
A wrong number here is a compliance risk
ESG reporting is high stakes. Enterprises must track carbon emissions across every Scope 3 category, map spend data from ERPs and vendor systems to the right emission factors, and produce reports that comply with multiple global frameworks such as GRI, TCFD, SASB, and SDG. A wrong number in a published report is not a UX bug. It is a compliance risk.
Zycus wanted Lythouse to serve everyone in that chain, from a non-technical business user checking a dashboard to a data analyst reclassifying thousands of line items. The Zycus product team shared requirements and early wireframes on regular calls. Our job at Feelpixel was to turn that raw thinking into flows and interfaces that could actually be used at enterprise scale.
The Challenge
Three hard problems
This was a new category of product for me, and the difficulty was concentrated in three places.
01
Data density without data blindness
Emission data lives in deep hierarchies: Scope 3 categories, then UNSPSC classification levels, then individual transactions. Users needed to move from a 25,000 tCO2e total down to a single invoice line without losing context.
02
Approval logic that admins could build themselves
Emission data cannot go straight from entry to report. Different organizations have different approval chains, with different rules for who signs off and when. Hardcoding those chains was not an option.
03
Reporting that survives an audit
Multiple people touch a single report across its lifecycle: analysts, approvers, auditors. Every change to an emission factor or classification had to be traceable to a person and a timestamp.
How Might We
How might we let four very different user types work on the same dense emission data, each seeing exactly the depth they need, while keeping every change accountable?
Understanding the Domain
Domain first, pixels second
The hardest part of this project was not drawing screens. It was learning the domain fast enough to design for it. Reports, approval workflows, and emission taxonomy (UNSPSC classification, emission factor sources, Scope 3 category logic) were all new territory. We worked from three inputs.
Calls with the Zycus product team, who brought market research and domain expertise and shared early wireframes of what each module needed to do.
Product research on existing carbon accounting tools, to understand established patterns and where Lythouse could do better.
Iterative solutioning, where we proposed flows and UI back to the client, gathered feedback, and refined.
Early flow exploration for one of the three core modules.
The Users
Four roles, one dataset
The platform serves four distinct roles, each with a different relationship to the same data.
Admin
System configurator and access manager
Sets up frameworks, roles and permissions, emission factor rules, and data integrations.
Motivation: smooth system setup and governance, with bulk actions for quick decisions.
Business User
Task contributor and goal owner
Tracks expenditure and emissions, reviews requests, comments corrections, approves or sends back.
Motivation: quick, insightful data without friction.
Auditor
Data validator
Receives approval requests, provides corrections, approves or rejects data.
Motivation: ease of use and a seamless connection with the analyst.
ESG Analyst
The heaviest user
Enters data through Merlin AI, changes emission factor sources, updates values manually, submits for approval, requests data from suppliers, and creates reports.
Motivation: a smooth workflow through a very long task list.
The core tension: the Analyst needs maximum depth and control, the Business User needs summary and clarity, and the Admin and Auditor need governance over both. One interface could not serve all four the same way. The information architecture had to.
Design Decision 01
Data Review: from company total to single transaction, without getting lost
The Data Review module is where analysts and business users live. The design uses progressive disclosure across three levels.
Level 1, the overview
Total carbon emissions, total spend, and emissions per dollar sit at the top with year-over-year change indicators. Below, every Scope 3 category (Purchased Goods and Services, Capital Goods, Upstream Transportation, and so on) shows its emission, spend, and coverage side by side. Hovering a value compares it to the previous year inline, so users get context without navigating away.
Level 1: every Scope 3 category with emission, spend, and coverage in one scan.
Level 2, the category drill-down
Clicking a category opens its UNSPSC classification breakdown: IT Hardware and Software, Office Supplies, IoT Devices, each with emission, spend, and coverage. The same column logic repeats at every level, so users never have to relearn the table.
Level 3, the transaction layer
From any classification, analysts can view the underlying transactions, edit emission factors, and send selections for approval.
Levels 2 and 3: the same table logic repeats at every depth, so users never relearn the interface.
The Trade-off
We kept coverage indicators (how much of the spend is actually classified) visible at every level, even though it added visual load. In carbon accounting, a number without its coverage is misleading, and hiding it would have made the interface cleaner but the data less honest.
A persistent left rail (Carbon Analytics, Emission Review, Supplier Collaboration, Audit and Approval, Report, Settings) keeps the full journey one click away, because in real sessions users bounce between review and approval constantly.
Design Decision 02
Emission Approval: a no-code workflow builder for admins
Every enterprise routes approvals differently. Instead of fixed approval chains, I designed a node-based flow builder where admins construct their own.
The canvas uses three node types: a Requestor as the origin, Approver nodes in sequence, and End nodes. Rule badges on each branch (2 Rules, 3 Rules) show the conditions that route data down that path, and dashed return paths make the rejection loop back to the requestor visible on the canvas itself. Available nodes sit in a right-hand panel and drag onto the canvas.
The approval canvas: two rule-based branches, sequential approvers, and visible rejection loops back to the requestor.
Why a visual builder and not a form?
Approval logic is inherently branching. In a form-based configuration, a two-branch chain with return paths becomes a wall of dropdowns that nobody can verify at a glance. On a canvas, the admin sees the whole route the data will take, including what happens when something is rejected. The flow is the documentation.
The Constraint That Shaped It
Admins are not developers. The node vocabulary had to stay tiny (approve, end, rules) and the canvas had to be impossible to break. Anything the builder allows must be a valid workflow.
Design Decision 03
ESG Reports: a lifecycle you can defend in an audit
The Reporting module handles the full report lifecycle across frameworks like GRI, SASB, and custom formats. Two decisions mattered most.
Status as a first-class citizen
Every report carries an explicit state: Draft, In Progress, Sent for Approval, Marked for Correction, Approved, Completed, Published. The list view exposes status, type, owner, last update, and reporting period as sortable, filterable columns, with recent reports surfaced as cards above. Bulk selection supports download, archive, and delete, because compliance teams work in batches.
Seven explicit report states, sortable columns, and batch actions for compliance teams.
The audit trail as a narrative
Sliding open from any report, the audit trail reads as a timeline of accountable events: sent for audit by the analyst, approved by a named approver, returned for corrections, an emission factor changed from US EPA Air Travel Short to UK DEFRA Economy Domestic by a named person, a classification changed from L4 Air Transportation to Air Travel. Every entry has a person, a timestamp, and the exact change.
The trust layer: every change carries a person, a timestamp, and the exact before and after.
This is the trust layer of the whole platform. When an auditor asks why a number changed, the answer is one panel away.
A note on AI: Merlin AI powers classification and data entry elsewhere in the platform. In the workflows I designed, its output stays editable and every manual override is recorded in the audit trail like any other human action.
Outcome
Shipped, live, and sold
Lythouse shipped and is live today as Zycus’s ESG platform, sold to enterprises with Carbon Analyzer, Goal Navigator, Green Supplier Network, and ESG Reporting as its core modules. The workflows I designed (data review, emission approval, and reporting) sit at the center of the Account and Comply stages of the product’s ACT model.
The Head of Product at Lythouse credited Feelpixel’s work on the engagement for bringing clarity to data-heavy interfaces and tackling complex UX challenges across modules.
Final delivered screens across Data Review, Emission Approval, and ESG Reporting.
What I Learned
Domain first, pixels second
The fastest way to design a taxonomy interface is to actually understand the taxonomy. The weeks spent learning UNSPSC levels and emission factor sources paid back in every screen.
Enterprise trust is built in the boring places
The audit trail, the coverage indicators, the explicit statuses. None of it is glamorous, and all of it is why an enterprise can rely on the product.
Repetition is a feature
Reusing the same table logic at every drill-down level felt unimaginative at first. It is exactly what let users go three levels deep without disorientation.
