Powering Better Decisions: Industrial Energy Intelligence Dashboards

Keeping just one warehouse-sized freezer at food-safe cold temperatures meant energy bills in the tens of thousands of dollars a month, and our client ran 250 of them. I joined an early-stage company that installed IoT sensors inside client warehouses, then built the Energy Management System meant to turn all that data into real savings.

KiloWatt^* had four goals riding on this rebuild: drive adoption of the new product, prove out real ROI on energy savings, use that traction to raise more funding, and grow past their three existing accounts. Of the four, adoption was squarely mine to move. Sounds simple enough, right? It wasn’t.

*Company name changed for confidentiality. ↩

With no existing research to point to, I started with the basics: Who are our users? Are we building the right thing? Are we building it right? Every method I chose traced back to one of those questions. The team was skittish about anything that felt risky, so I moved carefully, watching for the right moment to propose testing instead of pushing it as one big ask.

I started with an ethnographic study inside a live cold storage facility, then moved into in-depth interviews, then usability tests as designs took shape. Two frameworks helped me make sense of what I was seeing: UTAUT, to understand what actually drives someone to adopt new technology, and the Receptivity Gradient, to track how ready different users were for change.

Alpha and Beta testing gave me real, specific findings instead of guesses. Users looked at the KPI charts first, then flagged real friction: they couldn’t tell what date range they were looking at, they didn’t know where budget numbers came from, and they wanted to compare similar facilities to each other, not just get ranked against everyone. Every finding got logged the same way, what I observed, a screenshot or recording of the problem, and a suggested fix, so my PM could hand any ticket straight to a developer.

With a growing list of possible fixes, I built an Importance/Difficulty Matrix to prioritize what actually mattered: features rated by real user and stakeholder input on one axis, and actual development effort on the other. That mix of user testing and market research is what separated a genuine “high value, easy win” from a “want to have.”

The biggest thing I learned: performance and effort expectancy, how well the product worked and how much effort it took to use it, were the real barriers to adoption, more than trust or interest.

The devs were split on whether mobile views were worth building. So I pulled up Google Analytics: about 2% of sessions came from phones. In interviews, users told me why. They’d much rather be out on the warehouse floor than at a desk, but their phones were nearly useless out there. Spotty or no cell service, and gloves that made tapping a screen almost impossible. Seeing those conditions firsthand on a site visit drove it home. So we put mobile on hold.

Early on, one developer was ready to build exactly what users asked for, whether or not it made sense, and leave it at that. That was the mindset the team had drifted into over years without a UX designer. By the time I left, that same developer was asking, “But how will this impact the users?”

The product had been built one page at a time, with no one stepping back to look at the whole experience: what people were doing, where they were headed next, and why. I mapped that out through task flows, first at a high level, then down into the specific decision points and edge cases. Sitting stakeholders in front of these flows turned abstract debates into concrete ones. We could finally point to the exact moment in someone’s day where the product was helping, or getting in the way.

Knowing people would need real support to get there on their own, I ran live onboarding webinars and started building a certification program, so people could actually learn the system instead of stumbling through it.