01 / Context
A powerful product built around an aging interface.
EnTrade is a mature energy trading and risk management platform used across commodities including natural gas, crude, coal, metals, and shipping. Traders, schedulers, risk managers, accountants, analysts, and operations teams work inside complicated, interconnected workflows where bad information or missed dependencies have real consequences.
The product was powerful, but much of the experience was built in WinForms and organized around grids and individual forms. Using it could feel only a step removed from editing database records: find the right screen, locate the correct row, edit the right fields, then know which other form needed attention next.
Experienced users learned that structure. Everyone else had to become a power user before becoming productive. Meanwhile, prospective customers increasingly expected a web experience, and the desktop architecture was harder to maintain and scale. The company knew it needed to move to the web. The harder question was where to begin.
Powerful software. Expert-only navigation.
02 / My role
Designing the product—and introducing design itself.
I joined Enuit as its only product designer. There was no established product-design function, mature design system, or strong precedent for involving design early. The organization had historically been driven by engineering expertise and deep domain knowledge.
I was responsible for defining what the web version of EnTrade should become while also establishing the tools and practices needed to design it consistently. Because I was the only designer, the work had to scale beyond me.
03 / The real problem
The problem wasn’t just moving from desktop to web.
Rebuilding the existing WinForms screens in React would have solved the technology problem. It would not have solved the product problem. Workflows were fragmented, relationships between screens were implicit, and navigation depended on already knowing the system.
How do we preserve the sophistication of an ETRM platform while making its complexity more legible?
Start with the most valuable workflows.
A full rebuild would have created enormous technical and organizational risk. I recommended a progressive migration: sidecar the legacy application, move high-value and frequently used workflows first, and let the web platform reach critical mass over time.
This gave customers value sooner and gave design the opportunity to reconsider workflows rather than simply reproduce screens.
04 / Design principles & patterns
A data table had to earn its place.
The legacy application had trained the organization to think in grids. That exposed information quickly, but often made users interpret raw data rather than helping them understand what it meant.
A data table had to earn its place.
The question changed from “What fields belong on this screen?” to “What is the user trying to understand, decide, or accomplish?” Sometimes the right answer was still a table. But it stopped being the default.
Bringing information to the user.
A trader, scheduler, risk manager, or accountant could arrive at a role-relevant dashboard that surfaced signals from across the product: what needed attention, what changed, where risk might be developing, and what should happen next.
From navigating the database structure to navigating the work.
05 / Design infrastructure
Building a system, not a collection of screens.
Multiple web microservices meant individual screens could not be designed in isolation. I created the visual language and design system used across the web platform, reusable structural and interaction patterns, and helped create the shared template project used as the foundation for Enuit’s web microservices.
The design work became infrastructure. New teams inherited decisions around application structure, navigation, layout, visual hierarchy, dashboards, and reusable interface behavior.
One system → many products
Guardrails rather than gates.
The traditional model often placed design at the end: client request, developer implementation, then a designer asked to “make it pretty.” But with one designer, requiring every interface decision to pass through me would create a new bottleneck.
Smaller problems could rely on established components, templates, and patterns. Larger workflows earned design and workflow thinking before implementation.
Scale design through systems, not approvals.
06 / Production & commercial validation
From prototype to production.
The work did not remain conceptual. The design system and visual language are used across Enuit’s web applications. The shared template became the foundation for multiple web microservices. Role-based dashboards, trade search, navigation, contract viewing, deal entry, and other workflows moved into production.
“Can we have that?”
Prospective customers did not treat the new web interface as a future concept—they wanted it available from day one. Sales and marketing finally had a modern product experience they were excited to put in front of customers.
07 / The larger impact
The foundation is different.
Enuit almost certainly would have created a web application without me. What would have been different is what kind of web application it became. It would have been easy to recreate the same forms, grids, and fragmented workflows through newer technology.
My contribution was helping use the transition as an opportunity to rethink the product itself: a coherent visual language, shared design system, role-based dashboards, clearer information architecture, intentional workflows, a practical migration strategy, and a stronger role for design within development.
The goal was never to remove the complexity inherent in energy trading. It was to turn that complexity into software people could actually understand and use.