Product design case study

Energobilling

An enterprise energy management platform for a large telecommunications operator. I helped translate complex business logic into scenarios and interfaces, connecting large tables, entity detail views and their historical states into one system.

Role UX/UI Designer · Period 2024–2025 · B2B / Enterprise

Energobilling interfaces: initiatives, a consumption chart and a meter table

Context and role

From requirements to scenarios the whole team could understand

The platform brought together consumption and cost calculations, contracts, facilities, meters and energy management. Each area needed to account for related data, access permissions and exceptions.

My contribution

I proposed supplementing user stories with use cases for key processes, and designed interfaces and interactive prototypes. Working with analysts and developers, I clarified states, constraints and the handoff to engineering.

Team collaboration

Business rules and priorities were developed together with the Product Manager, analysts and the client. We checked the implementation with developers and QA.

Before

User Story

As arole
I wantan action
To gainvalue

What the team understands

Who

participant

What

need

Why

value

Questions remain

  • conditions
  • alternatives
  • errors
  • system responses

Clarification needed at handoff

After

+ Use Case

Contextconditions
Scenariomain flow
Alternativesalternatives and errors

What the team understands

Who

role and goal

What

need and actions

Why

value and system response

Also documented

  • conditions and constraints
  • states
  • completion criteria

Fewer questions from analysis through QA

To introduce the approach, I wrote the first 16 use cases as examples and gathered feedback from the people involved. There were fewer questions about user stories and prototypes when tasks were handed over to development.

Historical records · Initiatives

Showing how data changes over time

For calculations and verification, users needed to see a record as it stood on a selected date, distinguish historical values from current ones and understand the effect of initiatives. The interface had to keep the period in context and protect closed-period data from accidental edits.

01

Change history

The user selects a saved period and sees the detail view as it stood on that date. Edits are only available for the previous month; earlier values are separated from current ones and locked against editing.

A meter detail view in change history mode
State on a selected date. The detail view shows values that applied in the selected month, without risking changes to current data.
01 / 02

I helped design the historical-record mechanism and proposed a solution that became the basis for an interactive prototype. It linked date-specific views with the temporary effects of initiatives while preventing edits to closed periods.

Detail views · Tables

Keeping context in information-dense interfaces

Detail views contained dozens of fields across several sections, while tables combined related metrics and actions. Users needed to reach the relevant section quickly and inspect details without losing the original list.

01

I proposed dividing a long detail view into meaningful sections and keeping their names alongside the content. This helps users reach the data they need and stay oriented in a large interface.

A long detail view before and after division into sections
Detail view structure. One long screen becomes a set of compact, meaningful sections; section navigation stays alongside the data.
02

A single table with expandable rows

Initially, each meter had its own expandable table: few meters fitted on screen, and repeated information took up much of the space. I proposed one table with expandable rows. After discussion with developers and the Product Manager, the solution was adopted as the basis for implementation.

The original list, with a separate expandable table for each meter
Before. Each meter occupied a separate block with repeated headers, so only a few records were visible at once.
01 / 02

Takeaway

Solutions designed for the wider product

I designed solutions beyond a single area of the platform. Use cases became a way to capture and pass on important information between development stages, while the interface patterns could be used elsewhere in the product.

For the team

Use cases supplemented user stories and reduced questions about scenarios and prototypes during handoff to development.

For the product

Section navigation and expandable rows were implemented in code and later reused in other areas. Historical records and initiatives were developed as an interactive prototype and planned for future releases.