EMPRIS
EMPRIS
Transforming complex energy data into instant, usable insight.
EMPRIS is a web application developed by ElectraLink for energy professionals. It was created to replace dense spreadsheets and clunky processes with a clear, self-serve interface that makes electricity-market data easier to explore. The goal was to help analysts and non-technical users alike find trusted insights quickly, without needing to wade through raw files. The challenge was making something powerful enough for data scientists, but simple enough for wider teams. EMPRIS had to inspire confidence in experts while also lowering the barrier to entry for newcomers.
Transforming complex energy data into instant, usable insight.
EMPRIS is a web application developed by ElectraLink for energy professionals. It was created to replace dense spreadsheets and clunky processes with a clear, self-serve interface that makes electricity-market data easier to explore. The goal was to help analysts and non-technical users alike find trusted insights quickly, without needing to wade through raw files. The challenge was making something powerful enough for data scientists, but simple enough for wider teams. EMPRIS had to inspire confidence in experts while also lowering the barrier to entry for newcomers.


My Role
As the UI designer on this project at Xanda, I led interface design during a six-month sprint, working closely with ElectraLink’s data team. My focus was on creating layouts that could handle complex datasets without overwhelming users, establishing a visual hierarchy that made sense at scale, and ensuring the product felt approachable from the very first login. The tension throughout was between clarity and complexity. Analysts wanted full SQL control; newcomers wanted simple filters. I learned quickly that the solution wasn’t to pick one audience but to design for both.
My Role
As the UI designer on this project at Xanda, I led interface design during a six-month sprint, working closely with ElectraLink’s data team. My focus was on creating layouts that could handle complex datasets without overwhelming users, establishing a visual hierarchy that made sense at scale, and ensuring the product felt approachable from the very first login. The tension throughout was between clarity and complexity. Analysts wanted full SQL control; newcomers wanted simple filters. I learned quickly that the solution wasn’t to pick one audience but to design for both.
Access the Platform
When users logged in, they landed on a customisable dashboard. Key widgets could be pinned for quick reference, while the left-hand navigation kept orientation simple. A “Recent Queries” widget linked straight back to SQL, allowing analysts to resume work without retracing steps. Our first versions overloaded the dashboard with every dataset at once, which only created noise. By focusing on personalisation and shortcuts, the experience became both leaner and more useful.
Access the Platform
When users logged in, they landed on a customisable dashboard. Key widgets could be pinned for quick reference, while the left-hand navigation kept orientation simple. A “Recent Queries” widget linked straight back to SQL, allowing analysts to resume work without retracing steps. Our first versions overloaded the dashboard with every dataset at once, which only created noise. By focusing on personalisation and shortcuts, the experience became both leaner and more useful.




Browsing Datasets
Licensing data had to feel less like procurement and more like exploration. We introduced a Marketplace of dataset cards, each showing price, refresh cadence, and a plain-language summary. Filters for owner, geography, and date came directly from user testing, while a streamlined one-screen checkout helped prevent drop-offs. One misstep here was underestimating how much users wanted context in plain English. Early cards leaned heavily on technical labels, which proved confusing outside specialist teams. Adding short summaries made the Marketplace far more accessible.
Browsing Datasets
Licensing data had to feel less like procurement and more like exploration. We introduced a Marketplace of dataset cards, each showing price, refresh cadence, and a plain-language summary. Filters for owner, geography, and date came directly from user testing, while a streamlined one-screen checkout helped prevent drop-offs. One misstep here was underestimating how much users wanted context in plain English. Early cards leaned heavily on technical labels, which proved confusing outside specialist teams. Adding short summaries made the Marketplace far more accessible.






Building Queries
The SQL Builder was designed for flexibility without intimidation. A clean editor supported syntax highlighting and a library of saved queries for repeat work. Results appeared instantly in a filterable, exportable table, and a “Visualise” tab allowed quick charting without leaving the flow. At first, we blurred too many steps together, trying to keep everything on one screen. Testing showed this overwhelmed newer users. By separating query building, results, and visualisation into distinct stages, the tool became much easier to follow while still keeping power in the hands of experts.
Building Queries
The SQL Builder was designed for flexibility without intimidation. A clean editor supported syntax highlighting and a library of saved queries for repeat work. Results appeared instantly in a filterable, exportable table, and a “Visualise” tab allowed quick charting without leaving the flow. At first, we blurred too many steps together, trying to keep everything on one screen. Testing showed this overwhelmed newer users. By separating query building, results, and visualisation into distinct stages, the tool became much easier to follow while still keeping power in the hands of experts.





