Case Study

VEIC – Submetering Monitoring and Data Storage Platform

I designed an enterprise energy metering platform that has the ability to create project reports, store and organize past customer and project data, and monitor live metering projects for a large energy non-profit based in Burlington, VT.


UX Research, Logic Flows, Wireframes, Clickable Prototype, Developer Handoff File, & Live Platform


Vermont Energy Investment Corporation (VEIC)

My Role

Lead Product Designer (Full Stack: Research + UX + UI)


Hannah Sloan (Project Manager), Jeffrey Briner (Lead Developer)

Project Timeframe

5 weeks


Figma, pen & paper, Confluence, Coolors, and internal company UI design tool

Problem Statement

Vermont Energy Investment Corporation (VEIC) works alongside the state government of Vermont to provide companies and other entities energy use metering with the goal of reducing the economic and environmental costs of energy use. One way in which VEIC accomplishes their business goal is through their Metering department. Energy Consultants will install meters, either temporarily for a short analysis period or permanently for large organizations, to monitor energy usage and provide feedback on exactly how to reduce it.
VEIC requested a new platform that would allow Energy Consultants to upload, manipulate, report, and store meter and customer data as well as monitor live installations to improve operational inefficiencies and tooling gaps within their Metering department.

Who Am I Building For?

I travelled up to Burlington, VT along with the project manager to conduct user interviews and refine the project details. We interviewed six Energy Consultants (ECs), the main users of the future platform, to understand their pain points, in addition to the management team of the Metering department.

Previously, there was no centralized repository to store or analyze project information and usage data. At the completion of temporary installations, ECs downloaded meter data directly onto their laptops from physical meters via USB. Each EC would store their own files locally to their work computers, manipulate it on Excel, and have no way of sharing the collected information.  In addition, customers would rely on a single report with final recommendations which didn’t allow for transparency into the data collected.

Continuously-reporting meters at permanent installations broadcasted data onto their hardware providers’ portal. The Metering department had no single interface for users to view the data; this proved particularly difficult at sites with two different types of meters. Finally, there was misalignment between their meter inventory in the office and in the field due to improper reporting.

Roles & Responsibilities

I acted as the sole product designer from ideation through execution.
Our team structure for clients include a lead product designer, project manager, and developer. Each team member plays a critical piece in our “trifecta.” Product designers have a distinct role to advocate for both the needs of the end users and business. Once the project kicked off, I was responsible for all deliveries for the first 5 weeks.

Scope & Constraints

The metering platform was commissioned by Efficiency Vermont, the Vermont division of VEIC, and, once white-labeled, will be rolled out to their other subsidiaries. The project timeline at the onset of the contract writing was aggressive due to the scope of the work and agreed upon deadline. It required agile planning and hyper-diligent design work.

In addition, we learned that there would be a need to display both live and historical data after the Statement of Work was written, which needed to be considered and designed around in the same timeframe.

The Process

Understanding the User
Onsite in Burlington, I was able to meet with many users to understand their roles, needs, current pain points, and technical competencies.  To get the most out of interviews, I prepared a set of questions for both types of users.
A set of questions from my preparations for the onsite visit and subsequent user interviews
On the plane ride back, I synthesized my findings. First, I created two user personas: Jesse Walker (EC) and Loretta Kinkaid (Metering management) to reference and connect back to throughout the process. (Note: persona names changed from VEIC employees.)
User personas for one Energy Consultant and the Director of the Metering Team *note* –  names changed for client protection
After digesting the user information and reviewing my personas, I was able to identify the user goals. Many goals spoke to the need for a source of truth with their projects; they focused on accessing and organizing a variety of data in a consolidated portal. As well, they highlighted a need for actionable data, whether it was to make real-time decisions or collect recommendations. Their teams heavily relied upon the Data Analytics team outside the department to complete project reports, bottlenecking their progress.
Synthesized goals focused on the EC and Metering Leadership needs
Focusing on Features
Historic and real-time data require individualized treatment. I spent hours with the project developers to learn exactly how we would ingest all the data while accommodating four types of meters and multiple data formats, as well as updating our system in both real-time and from downloaded comma-separated value files (CSVs).

The way in which data populates the platform depends on whether a project is live or historic. Live data can report directly to our servers, while historic data must be manually uploaded after uninstalling temporary meters. The main feature that addresses a significant portion of user goals involves a clear walk-through process of setting up project spaces to match the physical systems.

It became clear that, to customize projects to the extent VEIC requested, we needed users to define each type of reported value on the interface and link it to the correct data channel from the meters. This would allow for extensive tailoring of dashboards and reports appropriately for the method and time of data ingestion.

There would also be a need for user management with different levels of access so clients would have a secure view into their own project data on top of VEIC access.
Workshop with developers to lay out data and and create list of needed functionality
Architecting the Data
After reflecting on the feature work and our developers’ system knowledge, I created the product’s information architecture diagram. Understanding VEIC’s client base played a significant role in this process. Many of their clients have projects running across multiple sites, some spanning across the state of Vermont. Designing for tidiness, flexibility, and searchability, each project nests into customer and site data.

Another key choice was to create a separate tab to house alerts; this central repository allows users to access known issues promptly without wasting time diving into client data. These alerts can also be accessed within project data.
Final information architecture – kept up-to-date throughout revisions and changes to the product design
Navigating the Product
Utilizing my Information Architecture, I designed detailed logic flows to help distill where internal and external feeds, forces, and logic come into play to accomplish a task. I built logic flows for each stage of adding a user, customer, site, project, or a project feature (i.e. setting up channels, alerts, and dashboards) in addition to flows for simply viewing these same items. This gave me confidence that all required screens would be included.
Example logic flow detailing how to add a new "meter plan" (in technical terms, the digital twin) to the platform
I moved on to wireframing the prototype to understand where data would exist and in what format it's most usable. Our team utilizes an internal design system which accelerates the shift from low-fi to high-fi designs, allowing me to rapidly iterate and view a more complete picture at any given point in time.
Hi-fidelity wireframes utilizing our base wireframe design system
I worked closely and frequently with our project’s front end developer while wireframing. It is important to have occasional scrutiny on too-complicated layouts and features from the eyes of a developer. At the end, it leads to a dev-compliant and user-centered solution.

One of the features I iterated on repeatedly during the wireframing phase was the project creation walk-through. To get to the granular customization they requested, users of all technical backgrounds would need to be able to create digital twins of their physical metering systems, set alerts, and build dashboards to make data actionable. After many attempts, I decided on a wizard which labels the steps and allows for more user support for the most technically-complex area of the platform.
Testing the Prototype
As with all of my designs, I built out a full prototype to walk some test users through tasks. I did not get access to employees so I used local manpower. Since I designed with well-tested UX patterns in mind, I found users flowed through the prototype relatively easily.

With the platform in development, I am currently preparing documentation for the project manager to test with real users on-site with our first released version to find any problem areas and future roadmap requests.
Applying Visuals
Keeping consistent with our internal design system, I applied VEIC brand colors and some new auxiliary options where appropriate. At this stage, I judge visual weight on each page. Where needed, I swap primary and secondary buttons, tone down shadows, adjust graphs, and much more.
I felt it was important to make the platform visually stimulating, applying a slightly darker hue of their brand blue to the fixed sidebar to deepen the color palette and anchor the page.

The Finished Product

Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs

Project Takeaways

One critical lesson I learned as a designer of IoT applications was to tie myself in closer at the Statement of Work phase. We only learned of the historic data storage and manipulation need during the onsite, far after the agreement on the timeline and work. To avoid deadline-killing scope creep, it's critical that a knowledgeable designer or product manager is included in the Statement of Work drafting and editing.

How Could I Improve This Project?

Testing, testing, testing. With clients, it can be difficult to get access to end users to validate whether designs will soar or crash. I would love the privilege of applying incremental updates as we learn more about real-time usage to improve the product.

This is also my first attempt designing a dashboard builder. When first attempts occur, so follow learnings and improvements – a truth that holds weight in the product design world. The first deployed iteration will likely never be perfect, and seeing it in practice will shape my future designs.

See My Next Case Study

Lot Vision