ImpactEdge
An already-built enterprise platform, four user roles, and a redesign delivered as system patterns — not screens.
Redesigning the System Behind a Four-Portal Sustainability Platform
ImpactEdge is an enterprise sustainability management platform: organizations used it to collect, manage, and analyze environmental data across multiple domains. The product was live and in active use across four portals — Admin, Data Owner, Partner, and Certifier — each with its own responsibilities in the same underlying process.
The platform was powerful, and that power had a cost: deep data structures, a dense feature set, and workflows that were hard to follow for the people using them.
Role: Product Designer — UX audit, system redesign, dev handoff
Constraint: improvement of a live product during active development — not a rethink
Understanding the domain
Before touching screens, I needed the logic of the domain. Sustainability management is continuous-improvement work: the platform was, at its core, an enterprise version of the PDCA cycle (Plan–Do–Check–Act) used in quality management — extended into five stages: Plan, Collect, Review, Analyze, Act.
That lens made the problems easier to name. The four roles all worked inside one continuous cycle, and the interface had to keep them oriented in it — which is exactly where it was failing.
The real structure of the problem
Two structures defined the product.
The data hierarchy: Topics → Subtopics → Activities → Data Owners. And it was not a clean tree — one data owner could be attached to multiple entities, which demanded interaction logic that is flexible without becoming chaotic.
The data hierarchy in Settings: Topics and their Subtopics — Climate alone spans Scope 1, Scope 2, Scope 3 and Financed Emissions.
The main workflow: data moved from request through submission and review to approval. The chain ran across portals, and at any moment users needed three answers the interface wasn't giving: What action is required? What status is this item in? Who is responsible?
I reviewed the internal documentation, drew on the Product Owner's knowledge of how teams used the platform, ran a heuristic evaluation, built a sitemap of how modules, data, and navigation connect, and used Jobs To Be Done to anchor decisions in what each role was trying to accomplish. The audit kept pointing at the same root cause: the UI treated a deeply structured, stateful system as a set of flat, disconnected screens.
The sitemap that anchored the redesign — the continuous-improvement loop is visible in the product's own modules: Plan, Collect, Review, Audit, Report, Analyze, Act.
The decisions
1 · Hierarchy lives in one view
Problem: Flat tables couldn't represent the Topics → Subtopics → Activities structure, so understanding related data meant navigating between screens and holding context in your head.
Decision: Nested tables that keep parent and child records in a single view, using the same column structure at every level.
Review & Approve: scope-level rows and their underlying records in one view — approve or reject without leaving the table.
Why: In review and audit work, context is everything — nesting keeps related data in view instead of scattering it across screens.
2 · One table system, not many tables
Problem: Most screens in the product were data-heavy tables — dense information, status and priority indicators, sorting, filtering — and each screen solved these problems its own way.
Decision: Reusable table components with a clear hierarchy and defined action placement, specified once and reused across the redesigned screens.
The same table pattern reused for facility management: hierarchical rows, inline editing, owner assignment — one data owner can appear across many entities.
Why: Consistency in a data-heavy product is not cosmetic. When every table behaves the same way, users stop re-learning the interface and start trusting it.
3 · Interactions that match their weight
Problem: One overlay pattern served interactions of very different weight — confirmations, forms, alerts — with nothing in its structure signaling what was being asked.
Decision: Two defined patterns with documented rules: pop-ups reserved for confirmations, structured modals for forms and feedback.
A structured modal doing form work: creating a data request with reporting period, facilities, topic, sub-topic, and activity.
Why: In a compliance-driven product, the difference between "confirm this" and "complete this" matters. Distinct structures let users build a mental model of what each interaction demands.
4 · Filters that show their state
Problem: Applied filters disappeared from view, leaving no visible record of what was shaping the data on screen.
Decision: A filter bar where each filter shows its current value in place, with selection counts inside every dropdown, a "+ More" control that pulls additional filter fields into the bar, and one-click Reset.
The filter bar showing its state: each filter displays its current value, dropdowns show selection counts, and "+ More" pulls additional filter fields into the bar.
Why: Visible state closes the feedback loop — users see how filters shape results and can change them without starting over.
5 · A status system for the approval chain
Problem: Items moving through the request–submission–review–approval chain didn't clearly show where they stood — what action was required, what status they were in, or who was responsible.
Decision: A structured status system, so an item itself shows what action is required, what status it is in, and who is responsible.
Status made visible: each topic card shows its progress and state at a glance.
Why: In an approval workflow crossing portals, "who has this and what happens next" cannot live in people's memories. The status system is also where the domain's continuous-improvement loop becomes visible: it shows where an item stands in the cycle.
What was delivered
One set of system patterns for the four portals — Admin, Data Owner, Partner, and Certifier — rather than isolated screen fixes: the nested tables, the reusable table components, the two overlay patterns, visible filter state, and the structured status system. Table components, interaction patterns, and the status rules were documented as dev-ready specs while the product was in active development.
The platform had no analytics on internal workflows, so task completion could not be measured directly. The two metrics this redesign should move, once instrumentation exists: time to find related records, and how long a certification audit takes.
Reflection
Working on an already-built product taught me to find where the system breaks down and fix it at the pattern level, inside real technical constraints. The habit this project reinforced most: understand the domain's logic before redesigning its screens.
Because development was active, I aligned with engineering early, so every pattern stayed feasible.