03 /2026 · in progress
ConceptVolta — from energy use to clear business decisions
An electricity cost monitor for small businesses: how much will I spend this month, where is the leak, and what to do about it. Work in progress.
- #Product Design: all cases with this tag
- #Data UI: all cases with this tag
- #UX Research: all cases with this tag
- Product Design
- UX Research
- Data UI
- Design System
A personal project in progress: it grew out of my own problem and is designed to scale to small businesses. The prototype of the main flow is already live.
Process depth
- Competitors
- 8
- Research
- 2
- Observations
- 8
- Insights
- 4
- Pain points
- 5
- Opportunities
- 5
- Flows
- 1
- Screens
- 7
- Decisions
- 6
How many records of each stage the project's workbook holds. It is the amount of documented work, not a score.
- screens in the clickable prototype
- 7screens in the clickable prototype
- roles with different access rights
- 3roles with different access rights
- failure cases: meter offline, new location, no tariff set
- 3failure cases: meter offline, new location, no tariff set
- visual directions, 1c Signal chosen for the prototype
- 6 → 1visual directions, 1c Signal chosen for the prototype
Decision trail
Records and links from the workbook. Hover or tap a record to see what it rests on and what it leads to.
36 records · 39 links. Hover a record to see its chain.
Observations · 8
Insights · 4
Pain points · 5
Opportunities · 5
Flows · 1
Screens · 7
Decisions · 6
Record titles are kept as written in the workbook, in Ukrainian.
01 /10
VOLTA — energy under the business’s control
Volta is a concept for a digital platform that helps small businesses monitor, analyse and optimise what they spend on electricity.
The project started as a personal problem. I kept running into the same thing: the electricity bill arrives as a fact, with an amount but no explanation of where it came from or what to do about it. I built Volta for myself first, but from the start I designed it to grow: the same problem is sharper for a small business, where equipment runs around the clock, there are several locations and different people look at the numbers.
Most energy monitoring tools focus on technical metrics: kilowatt-hours, consumption charts, peak loads. But the owner of a café, bakery or shop cares more about what it costs and whether the cost can come down.
With Volta I set out to explore a different approach: build the interface around the financial consequences of energy use, not just around meter readings.
The product serves three kinds of users: business owners, location managers and accountants. Each role has its own tasks, access level and need for detail.
The core idea of Volta is to turn complex energy data into clear business decisions.
- Category
- B2B SaaS · Energy monitoring · Small business
- Product
- Mobile overview + desktop dashboard
- Roles
- Owner · Location manager · Accountant
- Status
- In progress: research and a prototype of the main flow
- My role
- Product Designer, self-initiated concept
02 /10
Not kilowatts, but money
The starting problem looks obvious: a business needs a tool to keep electricity use under control.
The simplest answer is a dashboard with charts, kWh figures and usage history. But I questioned how useful that really is.
A chart on its own doesn’t tell the user whether the spending is normal or what to do if it goes up.
For example, a bakery owner sees that electricity use went up 18% over the last week. That number doesn’t answer the questions that matter: how much extra money it will cost, what caused it, and whether the cost can be avoided.
So I framed the design problem differently: how can a small business owner assess electricity costs, spot a problem and understand the next step in 30 seconds?
That decision shaped the information architecture, the priorities of the main screen and the principles of data visualisation. Instead of showing as many metrics as possible, I focused the concept on the information that helps make decisions.
- 01
Owner
wants the amount in hryvnias and one main problem, in 30 seconds on a phone.
- 02
Location manager
sees their location's usage but not the company's finances.
- 03
Accountant
needs a table for a period and an export, not charts.
03 /10
Three questions, in this exact order
While shaping the product concept, I defined three questions the interface has to answer in sequence. My core product principle is Data → Insight → Action: the user should get from data to understanding the problem and to a concrete decision with minimal effort.
- 01
01. How much will I spend?
The user should immediately see current spending and the forecast to the end of the month. The main unit is the hryvnia. kWh figures stay available for detailed analysis, but the user should never have to do the money maths themselves.
- 02
02. Where is the problem?
The system should help spot deviations from the usual level of consumption. It is not enough to show that costs went up: the rise should be tied to a specific location, piece of equipment or time period, when the available data allows it.
- 03
03. What can I do?
Every important alert should come with a clear recommendation. For example: check the refrigeration equipment, look at night-time consumption, or consider moving energy-heavy work to another tariff period.
04 /10
Constraints that shape the design
When designing Volta, I considered not only ideal usage scenarios but also the technical constraints typical of energy monitoring systems. They decide how honest and reliable the interface can be.
These constraints shape the messages, charts, forecasts, system states and role model. The principle: the interface must not hide technical limitations when they affect how reliable the information is.
- Data updates. Meters report roughly every 15 minutes, and readings can arrive late.
- Incomplete measurement. Not every appliance has its own meter, so part of the consumption has to be estimated.
- Complex tariffs. The price of electricity depends on the tariff model, the time of day and the specific site.
- No history. For new users the system may not have enough data to forecast.
- Unstable connection. The internet can be slow or temporarily unavailable.
- Limited user time. A business owner may look at the numbers on a phone for just a few seconds.
- Different access rights. A location manager should not see all of the company’s financial figures.
- Need to export. The accountant needs structured data for a chosen period.
05 /10
How I research the problem
I organised the work on Volta as a sequential product process in which researching the problem and forming hypotheses come before visual design. The aim is to ground design decisions before moving to the final UI.
- 01
01 — Problem Discovery
I started with my own experience and wrote down what exactly confused me in bills and consumption charts. Then I separated the technical task of monitoring electricity from the real need, keeping costs under control, and checked whether it applies to small businesses too.
- 02
02 — Desk Research
For research I chose open sources: user reviews, help centres of energy products, technical documentation and tariff information. This lets me study the problem without made-up interviews or a non-existent client.
- 03
03 — Competitive Analysis
I listed products to analyse: Sense, Emporia, Tibber, Shelly, EcoFlow and Home Assistant Energy. The main criteria are information hierarchy, financial metrics, device pairing, error handling and how understandable the analytics are.
- 04
04 — User Scenarios
I defined three main roles: business owner, location manager and accountant. For each I described key tasks, information needs and possible access limits.
- 05
05 — Information Architecture
I built a conceptual product structure around the main scenarios: cost overview, consumption analysis, alerts, tariffs, reporting and settings.
- 06
06 — Design Exploration
Then I moved on to the product’s visual language and prepared six interface directions to compare approaches to information density, typography and visual hierarchy.
06 /10
Finding a visual language
Volta is a product full of numbers, charts, tables and system messages. So the visual style has to do more than look modern: it has to help the user find their way through the information quickly. Instead of picking one reference, I explored six different directions.
Instrument: an interface inspired by professional measuring instruments, focused on precision, contrast and clear readouts.
Ledger: a restrained financial interface focused on numbers, cost comparisons, tables and structured information.
Signal: a visual system built around important changes and messages. Colour highlights anomalies, warnings and states.
Console: a dense professional interface for large amounts of data, aimed at analytical tasks and detailed control.
Calm: a minimalist approach with plenty of white space to reduce cognitive load.
Editorial: an interface with a strong typographic hierarchy, where large figures, clear headings and a consistent structure guide attention.
To compare the directions I set four criteria: how fast the key information is read, how easy it is to work with numbers, how well the interface scales, and how well it suits mobile. This way the design is judged by how it fits the product’s tasks, not by looks alone.
For the clickable prototype of the main flow I chose the Signal direction.
07 /10
States I design separately
In complex analytical products the interface has to stay clear even when the system doesn’t have complete information. So for Volta I set aside a separate design track: System States & Edge Cases.
The key decision: reliable information matters more than a visual illusion of a flawless system.
- 01. First Use / Empty State. The user has just signed up and hasn’t connected a meter yet. Instead of an empty dashboard, the system explains where to start.
- 02. Insufficient Data. There isn’t enough history to forecast. The interface shows what is available and explains when a forecast can appear.
- 03. Missing Data. Some readings for the period are missing. The chart shows the gap instead of joining the points artificially.
- 04. Device Offline. A meter has temporarily stopped reporting. The system shows the device status and the time of the last update.
- 05. Estimated Values. Some figures are estimated. The user can tell estimates from measured values.
- 06. Missing Tariff. Consumption is known but no tariff is set. The system shows kWh without inventing an amount in hryvnias.
- 07. Restricted Access. The user opens information their role can’t see. The interface explains the restriction without revealing confidential data.
- 08. Loading / Slow Network. Data loads slowly. There are loading indicators and whatever data is available appears step by step.
08 /10
What I plan to rule out and test
While designing, I identified several popular approaches that don’t necessarily fit Volta’s tasks. They need to be assessed before the final interface choices. The aim is not just a good-looking solution but understanding which approaches actually help the user.
- 01
01. Gamifying energy use
Ratings, points and achievements can raise engagement but don’t necessarily help a business owner cut costs. Hypothesis: financial recommendations will be more useful than an abstract energy-efficiency rating.
- 02
02. Kilowatts as the main metric
Technical data matters for analysis but may need extra interpretation. Hypothesis: showing costs in hryvnias will shorten the time it takes to understand the situation.
- 03
03. Faking real-time monitoring
If meters report every 15 minutes, a constantly animated chart can give the wrong impression. To test: show the time of the last update and the actual reporting frequency.
- 04
04. A single efficiency index
A score like an Energy Score can look convenient but hides complex calculation logic. Hypothesis: concrete financial figures with explanations will be clearer.
- 05
05. AI chat as the main interface
Conversation can help with complex questions. But for a quick look at costs, having to phrase a request adds steps. To test: ready-made insights as the main flow, with chat as a possible extra.
09 /10
What will become the design system
For Volta I planned a component architecture that keeps one visual language across every screen. The design system has to cover not only standard UI elements but also components specific to energy data.
Every component gets the states Default, Hover, Focus, Active, Disabled, Loading, Empty and Error, and separately the data quality states Measured, Estimated, Missing and Outdated. Mobile and desktop share one component system with different information density: on mobile the priority is fast reading, on desktop detailed analysis.
The aim is a scalable design system where new features can be built without breaking the consistency of the interface.
Design Foundations
- Color Tokens
- Typography Scale
- Spacing System
- Border Radius
- Shadows & Elevation
- Layout Grids
Core Components
- Buttons
- Inputs
- Selects
- Dropdowns
- Tabs
- Navigation
- Modals
- Notifications
Data Components
- Energy Consumption Charts
- Cost Forecast Cards
- Usage Comparison
- Tariff Timeline
- Anomaly Alerts
- Confidence Indicators
- Data Status Badges
- Financial Data Tables
Documentation
- What each component is for
- Usage rules
- Variants and states
- Responsive behaviour
- Accessibility principles
- Developer specs
10 /10
What’s next
Volta is a self-initiated product concept in which I explore designing complex analytical interfaces for small businesses.
So far I have shaped the product idea and defined the target audience, key scenarios, technical constraints and directions for the visual language. I have also prepared visual language concepts, defined the architecture of the future design system and built a clickable prototype of the main flow.
Next steps. 01 — Research Validation: finish the competitor and review analysis, test the main hypotheses and document the findings. 02 — UX Architecture: detail the user scenarios, navigation and information architecture. 03 — Interface Design: design mobile and desktop screens for the main scenarios and the edge-case states. 04 — Design System: build the component library, design tokens and documentation. 05 — Interactive Prototype: extend the existing prototype to all key scenarios. 06 — Usability Testing: check how quickly people understand the financial figures, find problems and decide on the next step.
The main takeaway: a good interface doesn’t just show information. It helps the user understand what it means and make a decision.
For me, Volta is a chance to show a systematic approach to UX/UI: from defining the product problem and working with constraints to shaping a visual language and a scalable interface architecture. Even though it is only a solution for me today, I design it as a product that can grow: with roles, several locations, a design system and honest handling of data.
Next case · 04 / 06
Restaurant booking app
Tell me briefly about the product and the timeline — I'll reply within a day.