top of page
Search

How We Build User-First Products for Energy Traders at ennrgy.ai

  • Writer: Michael Conolly
    Michael Conolly
  • Oct 12
  • 3 min read
How We Build User-First Products at ennrgy.ai


Over the past 15+ years leading UX design, research, and front-end teams across the energy and enterprise software space, we’ve learned that what matters most isn't just what we build, but who we build it for, and how early we bring them in.

At ennrgy.ai, we’re building our products from the ground up with one core belief: Energy Traders aren't validators, they're collaborators.

This post outlines how we’ve approaching early-stage UX research and co-design at ennrgy.ai, and how it’s already helping us uncover blind spots, shape roadmaps, and remove the risk from major investments before writing a single line of production code.


Start with the person, not the problem


When we begin exploring a product idea, we don’t start by sketching a UI or gathering feature requests. We start by getting in the trenches with the people who’d use it. That means spending hours in deep listening mode. Understanding not just what users do, but why they do it that way, what they’re compensating for, and what they’ve come to expect won’t work.


In recent sessions, for instance, one energy analyst walked us through a spreadsheet they update daily with 88 tabs, thousands of rows, updated by hand just to see how their generation portfolio is tracking against budget. "This is the page that ends up in front of our executives," they told us. "It’s how we keep from flying blind."


That moment crystallized something for us. In this space, clarity is currency. Users don’t just want charts, they want answers.


Immerse before you ideate


We believe the best product ideas come after the quietest moments. That’s why we run customer immersions and shadowing sessions before planning. These sessions aren’t about feedback, they’re about observation. Two ears, one mouth - listen twice as much as you speak. We watch people work, ask what’s changed since last quarter, and study the tools they bolt together to make up for what software can’t do.

One operator showed us how they scrape data from three separate systems into Excel, manually group it by fuel type, and visually scan for discrepancies. What they wanted was automation, but they needed to trust it was doing what they want it to do.

"Do you currently have a product or a standard application that tells you something is out of balance without having to click all over the place?"

Prototype with purpose

From those sessions, we don’t walk away with requirements, we walk away with hypotheses. Can we help this user avoid switching tools 5 times a day? Can we build a system that tells the story instead of dumping raw numbers?

We use rapid prototyping to test these hypotheses early. We’ll often bring back clickable prototypes in under a week and ask, does this feel like how your day works? Not, do you like the colors?

One early partner told us a prototype screen jumped their internal tool’s usefulness from "maybe 25% to about 90%", just by surfacing the right assertions and allowing drill-downs with visual context. That kind of shift doesn’t come from UI polish. It comes from deeply aligning with mental models.

Build around the question, not the query

Our users aren’t asking, "How do I pull this report?" They’re asking:

  • "Are we over budget today, and if so, why?"

  • "What changed since yesterday?"

  • "What’s our risk exposure if this unit goes offline?"

We design from those questions outward. Our goal isn’t to reduce clicks. It’s to reduce uncertainty.

What this looks like in practice for energy traders

Here’s how our user-first process plays out:

  1. Kickoff conversations to understand user roles, daily pressures, and decision loops.

  2. Customer immersions to observe real workflows and pain points in the wild.

  3. Workflow capture using maps, diagrams, and firsthand walkthroughs.

  4. Rapid prototyping to test how well we’re modeling users’ reality.

  5. Ongoing feedback loops to refine, not just validate.

We prioritize clarity over cleverness, patterns over features, and outcomes over optics.

Closing thoughts

Putting users first doesn’t slow us down. It’s how we move faster with confidence.

We’re not just building ennrgy.ai for the industry, we’re building it with them. And if we do it right, they’ll stop thinking of it as "software" altogether.

They’ll just call it how they work.

===================



 
 
 

Comments


bottom of page