Modular Pricing System: from cross-product inconsistency to a scalable design system

On the TIM Portal, pricing is the module where conversion happens. It's where customers compare plans and decide what to buy. The problem is that this module wasn't a single one. Four product squads recreated and applied their own version, each with a different layout and structure.

The effect was cumulative. Users struggled to compare offers across products, especially in natural transitions like migrating from Pré to Controle. Global conversion stayed below expectations out of sheer cognitive overload. And the UX and engineering teams reinvented the wheel on every page, generating constant rework.

Add to that a detail that set the tone of the project: the environment had low design and testing maturity. Validating with users wasn't routine — it was something to be built from scratch alongside the solution.

Each product had its own non-negotiable business rule. Imposing a single layout top-down wasn't an option, because each squad was solving a real, different need.

The challenge wasn't picking one rule as the right one. It was finding a structure that respected all four at the same time.

The first step was looking at what the analytics tools already said about how the different applications of the module impacted results. Four patterns kept repeating.

Browsing the product pages on mobile, I found the most serious issue. The card's sizing pushed the CTA below the first fold, compounded by information overload and little perceived difference between neighboring offers.

With the learnings synthesized, I formulated a hypothesis together with the PO to guide the solution.

Rework the module's information structure, ensuring it serves the different business rules and makes it easier for users to understand the offers. With that, we expect to reduce the rejection rate and increase interaction with the module.

Before designing, I analyzed competitors and references from other markets to understand how to simplify the card without losing relevant information.

benchmarking · market references

Since the module had to serve all four squads, deciding alone made no sense. I facilitated a co-creation session with each squad's UX team, so the solutions would be born already accounting for everyone's demands.

figjam · co-creation

Refining the most-voted suggestions from the session, I assembled the first version of the card. It already featured the highlight for the most advantageous offer, more weight for data and price, the payment-method choice inside the card, supporting text to differentiate the offers, and benefits simplified into a collapse.

To capture the business view, I took this version to a critique with the POs of the four squads. The main concern was about the benefits that would be hidden in the collapse — precisely what each squad considered its strategic differentiator.

Here is one of the points I'm most proud of in this project. In an environment with low testing maturity, structuring a formal evaluation was, in itself, a demonstration of the value of testing: catching and anticipating problems before anything goes to production.

I ran a moderated remote test with 5 users to evaluate the new module's efficiency. I also used it to validate which factors they consider when purchasing an offer. Data and price were the most cited, confirming the hierarchy I had been reinforcing.

figma · usability test

At the end, participants answered the SUS questionnaire to measure perceived ease of use.

The high score didn't blind me to the problems. During the sessions, two critical issues surfaced on the card, highlighted below.

1

2

1Benefit as plain text: required extra effort for users to perceive the value

2Toggle with unclear action: did not communicate that it would trigger an action

I restructured the visual hierarchy into two blocks. The first highlights the offer's main differentiator, now with service logos instead of plain text. The second gathers the complementary benefits. In place of the payment choice came the option to add an extra service, with a more explicit toggle.

The answer to the four rules wasn't a single, closed card. It was a modular system. The validated best practices stay fixed and guarantee consistency; the content that changes from product to product stays configurable.

With that, each squad assembles its own variation without breaking comparability across products or reopening decisions already validated. The modules switch on and off according to each product's rules, from the full card to the leanest one.

tim.com.br/planos

The role was cross-cutting, connecting four squads that used to work in isolation.

To validate the improvements, the TIM Controle squad was the first to implement the new pricing.

The leaner formatting raised the average view rate along the page, and the vertical navigation on mobile made exploring the offers easier, with an increase in click-through rate to purchase. More than the numbers, the project left behind a system all four squads adopted and a precedent: that it pays to test before shipping to production.

Methodology: view and click gains measured in the TIM Controle implementation, the first squad to adopt the module. These are directional indicators, not yet consolidated cross-product.