View all resources

Designing for energy and renewables: what makes it different

Designing for energy and renewables: what makes it different

Note: Two users who want opposite things, data that arrives ugly, and software that has to still work in ten years. What changes when the product controls something physical.

Most energy software was built by engineers for engineers, then sold to people who are not engineers. That gap is where the design work is, and it is a different job from designing a SaaS tool, because the thing on the other side of the screen is physical. A button curtails generation. A number is what a regulator will audit. A missed alert is an engineer driving two hours to a site.

Here is what changes.

Two users who want opposite things

Almost every energy product serves an operator and an owner. The operator is in it every day, knows the system better than you do, and wants density, keyboard shortcuts and nothing in the way. The owner opens it monthly, wants to know whether the asset is performing and whether to worry, and will not learn your interface.

The common failure is building one interface and compromising in the middle. Everyone gets a dashboard that is too shallow to operate with and too dense to read casually. Separate the two views properly. The same data, two different questions, two different designs.

Time series is the whole product

Generation, consumption, price, forecast, curtailment, state of charge. Nearly everything in energy is a number over time, often at fifteen-minute or five-minute resolution, across many assets. A design that treats this as "put a chart on it" produces the thing you see everywhere: a wall of line graphs that shows everything and answers nothing.

  • Decide the default time window per user, not per product. An operator wants today. An owner wants this month against last.
  • Comparison beats absolute numbers. Against yesterday, against the same month last year, against the forecast, against the other site.
  • Make the anomaly the thing you see first. Most of the chart is normal, and normal does not need attention.
  • Aggregate by default and let people drill down. Fifteen-minute data at portfolio level is noise.
  • Respect units. kW and kWh get mixed up constantly, including by people who should know better. Label everything, every time.

The data arrives ugly

Inverters, meters, SCADA systems and half a dozen vendor APIs, several of them returning XML that has not changed since 2009. Readings go missing. Timestamps arrive in local time with no offset. A sensor fails and reports zero, which looks exactly like a site producing nothing.

Design for that rather than around it. A gap in the data needs to look different from a genuine zero, because those mean opposite things and confusing them destroys trust in every other number on the page. Show data freshness somewhere visible. And when a feed is stale, say so on the chart rather than in a settings screen nobody opens.

Field conditions are the real conditions

A meaningful share of energy software is used on a roof, in a plant room, in a substation or in a van. Direct sunlight, gloves, one hand, hard hats, and connectivity that drops the moment someone walks behind a transformer.

  • Offline is not an edge case. Let people record work and sync later, and make the sync state obvious.
  • Contrast has to survive sunlight. Grey on grey is a desk decision.
  • Touch targets sized for gloves, not thumbs.
  • Anything requiring a long form in the field will be filled in later, badly, from memory. Design it for photos and short entries instead.

Actions have consequences that are not undoable

In most software the worst case of a misclick is an annoyed user. In energy it can curtail a site, trip equipment or send a crew somewhere. That changes how destructive actions should be designed: confirm with the consequence written out in plain language, not "Are you sure?", and make the confirmation name the specific asset and what will happen to it.

It also changes alerting. An operator who gets forty alerts a day stops reading alerts, which is worse than having none. Alert design in energy is mostly an exercise in suppression: grouping, thresholds that account for normal variation, and a clear line between something to know and something to act on now.

The output is often a document

Regulators, auditors, lenders and offtakers all want reports, on their schedule and in their format. In a lot of energy products the report is the deliverable and the interface is just how you get to it. That deserves proper design attention rather than a print stylesheet added at the end.

Ask early what has to leave the product, who reads it, and whether they will accept a PDF or need a specific template. It changes the data model, not just the layout.

It has to still work in ten years

Industrial and infrastructure software has a long life. Assets are financed over fifteen or twenty years and the software that monitors them is expected to last. A trend-led interface ages badly and gets expensive to maintain, and the people using it daily will resent a redesign that moves everything for aesthetic reasons.

Build on a design system with restrained, durable choices. Save the personality for the marketing site, where it belongs and where changing it costs nothing.

What we would do first

  • Split the operator view from the owner view, even if it is the same data underneath.
  • Fix the units and labelling everywhere. It is the cheapest credibility you will ever buy.
  • Make missing data visually distinct from zero.
  • Audit the alerts and cut them until every remaining one means act now.
  • Test the field screens outdoors, on a real phone, with gloves on.
  • Design the report properly, because someone is going to be judged on it.
Energy products are dense, regulated and long-lived.

That is the kind of work Anyday does best: complex product surfaces made clear enough that the people who did not build them can use them. If your energy or renewables product is powerful and hard to read, that is a fixable problem.

Key takeaways
  • Design the operator view and the owner view separately. Compromising in the middle fails both.
  • Everything is time series. Default windows, comparison and anomalies matter more than more charts.
  • Missing data must look different from zero, or nobody trusts any of the numbers.
  • Field conditions mean offline, sunlight and gloves, not a phone breakpoint.
  • Confirmations should name the asset and the consequence, and alerts should be cut until each one means act now.

Want this applied to your product?

Book a call and we will get into the specifics.