B2B pricing calculator redesign concept

The short version

The problem

A public pricing calculator leaned on a long country list, with the next step far from the decision.

What I did

Redesigned it as four steps with search, a live summary, and a mobile pattern that works. A design hypothesis, built without inside data.

What it was worth

A concept that shows the reasoning, including when I would ship directly and when I would test first.

The call

For a low-risk public flow, I would ship it directly and monitor, rather than queue an A/B test.

I created this concept while researching a company I had applied to. The pricing calculator was one of the few public product-adjacent flows available, so I used it as a focused product and UX exercise.

I did not have access to analytics, customer feedback, sales context, or internal priorities. This is not a claim that the existing flow was business-critical or wrong. It is a design hypothesis based on observable friction.

The original flow appeared to rely heavily on browsing a long country list, with the next action separated from where the user made their selection. For users selecting multiple countries, it could be harder to keep track of what had been selected and what to do next.

These were the areas I wanted to explore.

• Faster country selection through search and shortcuts
• A clearer summary of selected countries
• A more obvious next action
• Plan volume as its own focused step
• A contact step that felt connected to the calculator
• A mobile pattern that did not depend on a desktop-style sidebar

I redesigned the flow around one main principle. Main content is where the user makes the current decision. The summary area shows progress and helps them continue.

The final flow became four steps.

1. Countries
2. Plan volume
3. Contact details
4. Confirmation

On desktop, the right sidebar acts as a live summary and progression area. On mobile, the same role is handled by a sticky bottom summary and bottom sheet.

I would not automatically A/B test a redesign like this. If this were a repeated workflow used by existing customers, I would be more cautious. But for a public pricing and contact flow aimed mostly at new visitors, a simpler and clearer design may be reasonable to ship directly, provided the team monitors completion, lead quality and sales feedback afterwards.

In a real product context, I would first check traffic, funnel data, sales usage, and risk before deciding whether to ship directly, run a test, or validate qualitatively.