Problem - 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
A tariff rule editor without relying on IT
To test a new tariff offer, business teams had to go through IT, even for the most common cases.
I designed a rule editor where business teams could create an offer, see when it applies and verify its effect on the bill, without relying on a developer.
Context
I led
No-code framingUX architectureInteraction modelRule logicBusiness validationPrototyping
Team
Product - Engineering - Backend - Equipe métier client - Sales
Challenge
Make offer creation simple enough for business teams, without losing the precision required for billing.
Year
2019
Timeline
12 months
Tools
Figma, Notion, Zeplin
Understanding the problem
Exploration and Solution
One form per offer
Create a dedicated screen for each tariff logic, with simple fields for standard cases.
Promise
Very easy to read / Fast on simple cases
Reasons for dropping
Not very flexible / Too many variants
One advanced editor
Expose logic close to the rule engine to cover the most complex tariff scenarios.
Promise
Very flexible / Covers rare cases
Reasons for dropping
Too technical / Risk of errors
A guided, advanced and temporal mode
Combine readable business blocks, an advanced mode for complex rules and a timeline to see when each rule applies.
Promise
Accessible to business teams / Visible periods
Accepted risk
Harder to design / Model to explain
Key decisions
Make rules configurable
Because each new offer could not remain dependent on a specific development.
Avoided cost
Coding every new offer
Avoided cost
Constantly depending on developers
Defining which rules were configurable
Accepted cost
Limiting some specific cases
Accepted cost
Separate guided and advanced modes
Because a tool that was only simple would have been too limited, and a tool that was only powerful too difficult to use.
Avoided cost
A tool that was too technical
Avoided cost
A form that was too rigid
Two modes to connect
Accepted cost
A model to explain
Accepted cost
Put time at the center
Because an offer rule only made sense if the team could clearly see when it applied.
Avoided cost
Invisible periods
Avoided cost
Conflicts that were hard to spot
A more complex visualization
Accepted cost
Overlaps to manage
Accepted cost
Verify before billing
Because a rule error became costly if discovered only at the billing stage.
Avoided cost
Discovering errors too late
Avoided cost
Sending unverified results
Designing validation views
Accepted cost
Explaining generated results
Accepted cost
The impacts
The tool made offers faster to create, easier to test and verifiable before billing.
Offer teams gained autonomy
common cases became configurable without specific development
Variants became faster to test
less back-and-forth with IT to adjust a rule
Bill effects became verifiable
rules could be controlled before reaching billing
Time to complete key tasks
The same tasks became faster once configurable inside the tool.
8/12
Configurable scenarios without IT
Common scenarios now covered independently by business teams, without specific development.
Retrospective
Create one screen for every case
Design a system that absorbs variants
Hide all complexity
Make it readable and manipulable
Validate only the interface
Verify what the interface actually produces
