01
Friction
For offer teams
They knew how to imagine new tariffs, but not always how to translate them into reliable rules.
Variable schedules
Consumption thresholds
Application periods
B2BComplex UXRule BuilderEnergyBilling
Creating complex energy offers without writing code
In 2019, our platform helped energy suppliers manage their tariff offers. Offer teams wanted to create new tariffs without going through IT. I designed a visual editor to define rules and see their effect on the bill.
Challenge
My role
OwnedContributedUX architectureVisual designPrototypingDiscoveryUser testingDelivery
Year
Timeline
Tools
Understanding the problem
Methodology
Business expert interviewsWorkflow mappingScenario testingEdge-case analysis
Components of a tariff rule
34%
Application
periods
27%
Threshold
conditions
22%
Contract
types
14%
Special
events
9%
Customer
exceptions
Creating a new offer meant translating a business idea into technical logic
Understand
See when the rule applies
Offer teams needed to manipulate schedules, thresholds and conditions themselves
Observed in business expert interviews
Offer teams needed to manipulate schedules, thresholds and conditions themselves
How can we turn an offer idea into understandable, configurable and verifiable tariff rules?
02
Friction
For the business
Each offer variant required too much back-and-forth before it could be tested or launched.
Slower launches
Difficult tests
Limited differentiation
03
Friction
For IT
The billing system was too critical to replace, but too rigid to absorb every new request.
Legacy to preserve
Migration risk
Technical dependency
Exploration and Solution
01
One form per offer
Create a dedicated screen for each tariff logic, with simple fields for standard cases.
Very easy to read
Fast on simple cases
Not very flexible
Too many variants
Explored
02
One advanced editor
Expose logic close to the rule engine to cover the most complex tariff scenarios.
Very flexible
Covers rare cases
Too technical
Risk of errors
Explored
03
A guided and advanced mode
Combine readable business blocks with an advanced mode for rules that go beyond common cases.
Accessible to business teams
Flexible when needed
Harder to design
Model to explain
Selected
Check out the 4 key decisions I made
Productization
Make rules configurable
Instead of coding every new offer, we made rules creatable from a business interface.
Comparison between a rule engine coded by technical teams and a business interface for creating energy offers.
Avoided cost
- Coding every new offer
- Constantly depending on developers
Accepted cost
- Defining which rules were configurable
- Limiting some specific cases
Accessibility
Separate guided and advanced modes
Common cases remained simple, while experts kept an escape hatch for complex rules.
Two-level tariff editor combining a guided mode with business blocks and an advanced mode for complex rules.
Avoided cost
- A tool that was too technical
- A form that was too rigid
Accepted cost
- Two modes to connect
- A model to explain
Time
Put time at the center
Rules depended on dates, seasons or schedules, so their application had to become visible over time.
Timeline showing the application periods of several tariff rules over time.
Avoided cost
- Invisible periods
- Conflicts that were hard to spot
Accepted cost
- A more complex visualization
- Overlaps to manage
Trust
Verify before billing
Teams had to see what a rule produced before it reached the billing system.
Workflow showing the verification of a tariff rule on real data before sending it to the billing system.
Avoided cost
- Discovering errors too late
- Sending unverified results
Accepted cost
- Designing validation views
- Explaining generated results
The impacts
The tool made offers faster to create, easier to verify and less dependent on specific development.
Offer teams gained autonomy
common cases became configurable in a business interface
New offers became faster to test
less back-and-forth with IT for each variant
Rules became verifiable before billing
simulation, bill preview and control of generated results
Time to complete key tasks
Before / After
2 wks
< 1d
3d
< 1h
3h
20 min
Tasks that depended on IT became configurable inside the tool.
-60%
Specific requests
Estimate on common scenarios that could be covered by configurable rules.
-70%
Implementation effort
Estimate compared with a heavy evolution of the existing billing system.
Retrospective
Create one screen for every case
DON'TDesign a system that absorbs variants
INSTEADHide all complexity
DON'TMake it readable and manipulable
INSTEADValidate only the interface
DON'TVerify what the interface actually produces
INSTEAD
