Helping energy teams query market data with confidence

I designed the MVP interface for EMPRIS, ElectraLink’s energy data platform, helping technical and non-technical users discover, query, verify, and visualise complex market data.

Context

Background

EMPRIS launched as an MVP for exploring UK energy market data, bringing dataset discovery, query creation, results, and visualisation into one product. ElectraLink owned the platform, and its users included analysts, business users, and institutional energy stakeholders working with large-scale datasets around consumption, generation, and market behaviour.

I was the only designer on the project, contributing across a 6-month period and responsible for wireframes, UI design, prototyping, stakeholder review sessions, a component library, and developer handoff.

Challenge

Users needed powerful data tools, but not every user was confident writing queries or interpreting raw outputs without support. The product had to give technical users enough control while giving less technical users clearer context, safer paths, and fewer opportunities to make mistakes they could not easily spot.

The MVP also had to work within existing technical architecture and stakeholder requirements, so the design needed to be useful, understandable, and realistic to build.

Research

Discovery was shaped through stakeholder interviews, product walkthroughs, and around 12 design review sessions with ElectraLink’s product, data, and technical teams.

Those conversations showed that users needed to know which dataset to trust, how to query it correctly, and how to explain the result afterwards. Query creation emerged as the riskiest point in the workflow, especially for less technical users who understood the business question but struggled to turn it into a reliable data output.

Highlights

Helping users resume recurring analysis faster

Users often returned to repeated reporting tasks, ongoing analysis, or datasets they had already worked with. I designed the dashboard around recent activity, relevant datasets, alerts, and unfinished work so users could recover context quickly. Stakeholder feedback suggested this helped users restart common analysis tasks with less support.

Helping users choose the right dataset before querying

A poor dataset choice could make every later query or chart unreliable. I designed dataset cards and catalogue views that surfaced descriptions, data status, access cues, refresh information, and supporting metadata before users entered the query flow. This made dataset selection a visible decision point, helping users check relevance before investing time in analysis.

Giving users enough context to trust the data

Users needed to understand what a dataset contained, how it was structured, and where its limits were before using it. I designed dataset detail screens that brought together documentation, schema information, sample data, known issues, and query examples. This gave technical users enough detail to work accurately while helping less technical users judge whether the data matched their question.

Making query creation safer for less technical users

Query creation had to support SQL-style flexibility without assuming every user wanted a blank technical workspace. I kept relevant fields, dataset context, and examples close to the query area so users could build queries without constantly switching back to documentation. In early prototype walkthroughs, stakeholders estimated the revised flow reduced time to a first usable query from around 12–15 minutes to around 6–8 minutes.

Keeping raw results visible before visualisation

Charts helped users spot patterns, but users still needed to inspect the records behind those patterns. I designed the results experience so query outputs could be reviewed as raw data before being turned into visualisations. This supported confidence because users could move between the insight and the evidence behind it.

Creating reusable patterns for a buildable MVP

The platform included dashboards, dataset pages, query tools, tables, charts, account states, and error states, so one-off screen design would have made the product harder to build and maintain. I created a component library of around 25–35 reusable components across cards, tables, forms, navigation, chart controls, empty states, and error states. This gave the development team clearer handoff material and reduced the number of isolated UI decisions they had to interpret during build.

Impact

Results

EMPRIS launched as an MVP and was adopted after delivery, moving the work beyond prototype into a real product environment. Stakeholders reported that users could start analysis faster and needed less guidance for common query workflows. I did not personally own post-launch analytics, so this should be read as directional evidence rather than a verified product metric.

Reflection

This project taught me that simplifying a technical product is less about removing complexity and more about placing context where decisions happen. The hardest balance was giving non-technical users enough guidance without turning the platform into a limited reporting dashboard for analysts. If I were measuring the product now, I would track first-query success, query error rates, time to reusable insight, support requests, and repeated use of saved analysis workflows.

Summary

EMPRIS needed to make complex energy data usable without hiding the technical depth that made it valuable. The design work balanced guidance with flexibility, evidence with interpretation, and stakeholder ambition with the constraints of an MVP build. The result was a launched interface that gave users a clearer way to discover, query, verify, and visualise UK energy market data.