← Back to work
SaaS Checkout Growth Experimentation

The company was betting on the next product. I made the current one earn more.

Jimdo was busy building what came next. I was the designer on checkout, which meant I was sitting on the part that was already paying for all of it, and that almost nobody was looking at. So while the company built the new thing, I spent eight months making the current one earn more.

Role: UX Product Designer, Checkout & Growth Company: Jimdo Timeline: 8 months Based in: Munich, remote
The short version

Improving something that already works is harder than fixing something broken. There is no villain and no broken step to point at, so every change has to be argued for. I found the changes with the best ratio of effort to return, and then argued for them.

My role

I was the designer on checkout, and because checkout is where the money changes hands, that stretched into growth. We also spent long stretches without a PM, so I picked that up too: I pulled and analysed the funnel data myself, wrote the hypotheses, prioritised them, and stayed through dev handoff and A/B results. I saw opportunities everywhere in that funnel and did not wait for them to reach a backlog. I put them there.

The problem

Everyone agreed checkout needed to change.
Nobody could say where to start.

Most of the company's attention, correctly, was on the new product. Which left the funnel that was taking money that week with nobody watching it closely.

The catch is that it was converting above industry average. When a flow is beating benchmark, "it feels dated" is not an argument, it is a risk, and rightly nobody was going to spend engineering time on it. I ran a design critique with the design team over the whole flow, to turn a shared hunch into something written down by more than one person. Every note on that screen has an author who is not me, which is what made it usable in the next conversation.

It confirmed what I suspected about the flow and about pricing, but a wall of notes is not an order to work in. So I took it to the data: Mixpanel and Tableau for where people were leaving, usability testing in Maze for what they hit on the way.

The billing options screen covered in sticky notes from the design critique: comments about the red prices, the loud green save bars, whether VAT needs to be shown, the inconsistent order summary and misplaced trust elements

There was a lot to do.

A detour I went on

I did not know Mixpanel when I started. I asked the data team to teach me, and then started building my own boards, simple ones first and harder questions as I went. A question you can answer yourself is a question you ask more often, and a good half of what ended up on this page came from questions that were only worth asking once they were cheap.

What it all pointed at

Too many steps

A long, multi-step checkout, adding screens to a flow whose job is to collect a payment.

Nothing being offered

No upsell strategy at all, and not one add-on prompt anywhere in the flow.

Pages with no owner

In-product landing pages, each with its own UI and a weak hierarchy.

Missing payment methods

No Apple Pay, and none of the options people now expect to find.

Weakest on mobile

Higher drop-off on phones, and few trust signals to hold anyone there.

The constraint

Five problems, and nowhere near the engineering time to take on all five. Rebuilding a checkout that was outperforming benchmark was never on the table, and it should not have been. So the question was never what would the ideal flow look like. It was which of these moves the number for the least effort, and how do I prove it before anyone spends a sprint on it. Everything below comes out of that question.

What I did

Four fronts, and one thing every one of them had in common

Every problem on that list had been sitting there for a long time, and the reason was always the same: somebody had decided it once, and nobody had checked since. So the job was less about having better taste than the people before me, and more about being the one willing to go and look.

Three of the four came with something we could not agree on. Each one was settled by evidence rather than by where people sat on the org chart.

01The pricing page

A marketing restyle was already scheduled. I used it.

A visual refresh was already planned for other reasons, so engineering time was allocated. That is the cheapest moment in the year to change anything, and I took the brief further than a restyle: clearer prices, plan highlights rewritten around value instead of feature lists, and consistency with the rest of the flow. Plan cards were reordered highest to lowest, left to right, from an A/B test rather than a preference.

Red countdown, red badges, red prices, and prices small enough to miss.

The Jimdo pricing page before the work: a red countdown bar across the top, a red BESTSELLER tag, red struck-through prices and red discount badges on every plan, with small type and cramped cards
The Jimdo pricing page after the work: the countdown bar and the bestseller tag in purple, prices set much larger, plans reordered from highest to lowest, and plan descriptions rewritten around what each one is for
The sticking point

Red is a very good marketing colour, and we had already given it a job

Prices, discount badges and the countdown bar were all red. Everybody knew exactly why: red creates urgency, and marketing had an A/B test from three years earlier where it had won. That is a real argument, not a habit. It was also colliding with the design system, where red is what an error looks like, on a subscription people are meant to keep for years.

Marketing

Red sells urgency, and we have the test that says so. Nothing since has suggested otherwise.

Me

That test is three years old and red already means something else here. One week to re-run it, and I take the hit if I am wrong.

02The checkout flow

Faster, and worth more per customer

Customize your plan with Add-ons: a step inside the Jimdo checkout offering Google Workspace email, Bookings, Legal Text Generator and Business Listings, each with its monthly price

Add-ons moved inside the flow instead of living somewhere you had to go and find.

We removed redundant steps, added Apple Pay, and connected Stripe. That last one is less boring than it sounds: Stripe has its own opinions about how payment inputs look and behave, and the work was balancing what it insists on against a design system with its own rules. Neither side gets everything.

Then we embedded add-ons into the flow and tested where they landed best. Adoption went up, which turned checkout from a step people get through into a place the business earns.

The more valuable thing it bought us was a place to ask questions. Once add-ons live at the moment of payment, you can put a feature that does not exist yet in front of people who are actively spending money, and find out whether anyone wants it before a single sprint goes into building it. That is a far better signal than a survey, because the person answering has their card out.

We ran those honestly. Clicking told you "thanks for your interest, we'll let you know when it's ready" and put you on a list, so the click bought you something. A door that opens onto nothing returns the same data and spends a little of your customers' trust to get it.

The sticking point

Which number a person should see first, and where the detail belongs

This one starts on the pricing page and ends here, which is exactly why it mattered. The business wanted the price shown before tax, with an asterisk, because it is the smaller number and our customers are businesses who can reclaim VAT. The problem is what that does to the order summary: you advertise one figure and then charge another, and the difference turns up at the last step of a flow you have spent months smoothing out.

The business

The lower number wins more clicks, and the asterisk covers us.

Me

Show the total, say it includes VAT, and break it down in the order summary where someone is actually checking the maths.

03The in-product landing pages

Pages nobody had claimed

The feature landing pages inside the product had been waiting a long time for a team to pick them up. There were even designs already drawn. They belonged to nobody, so nothing happened. I pushed to take Business Listings, and my team ran it even though it was not our area.

One interface

The same UI across every feature page, instead of one per team that touched it.

Value, not features

Content rewritten around what the feature does for you.

One call to action

Standardised CTAs, so every page asks for the same thing the same way.

Upsells in pattern

Upsell flows streamlined into the shape used everywhere else.

Pages made dynamic

A starting point if you already have the feature, a selling point if you do not.

A page that explained a feature without ever asking for anything.

The Business Listings page inside the Jimdo dashboard before the work: a flat block of text, a small link as the only action, and a checklist below with an Upgrade button competing for attention
The Business Listings page after the work: a clear headline, a single primary call to action, a supporting image, and the same layout every other feature page now uses
Why this one mattered

It moved conversion on that feature by 2%. Not spectacular on its own, but it came from about a week of work on a page that had been ignored for a long time, and it was the proof that the rest of the pages were worth claiming too. A whole surface went from dead weight to a growth touchpoint because somebody finally put their name on it.

04Strategic upsells

Name the amount, do not promise the value

Our engineering lead had seen how WordPress handled long-term plans and brought it to the team, which is worth saying because good ideas do not only arrive from the people whose job it is to have them. We took it, researched it, and landed on a banner at the final step: the exact amount you save by switching to yearly or two years, not a vague promise of value. Copy across the flow carried the same idea, so the saving came up more than once.

It worked. More people moved to yearly and multi-year plans, which lifts lifetime value and retention together. And then we spent a surprising amount of time on what colour it should be.

Jimdo checkout final step: a green banner offering to switch to a yearly plan and save 63.50 euros a year, above the payment details and the itemised order summary

The banner as it shipped. Not the colour I wanted.

The sticking point

Green already meant something, and we were about to make it mean two things

Green was our reserved colour for positive system feedback: it confirmed, it never sold. Purple was the upsell colour. Using green to sell something bends a rule the whole product relies on, and once it bends in one place it bends everywhere. The VP of Product wanted green.

The VP of Product

Green. It reads as a good thing, because it is a good thing.

Me

Purple, or green stops meaning anything anywhere else.

Behind all four

Everything above was cheap to ship because of something I built in the first weeks

Order summaries, billing cycle selectors, payment method logos, add-on cards, legal footers, success and error screens. None of it existed. Checkout was the only place in the product that used any of it, and the design system was not structured to hold it, so none of it lived anywhere reusable.

So the first thing I did at Jimdo was build the library. One master file where the specifications live, changed there and flowing down: variants covering every breakpoint and state, naming agreed with engineering so a component means the same thing in Figma and in the code, each set documented with where it is used and when not to use it.

That is the whole reason the eight months above look the way they do. A test is only worth running if the variant is cheap to build, and after the library existed most of them were an afternoon. The investment is what made the experiments affordable, and it is the practice I had learned to build at BlackRock, brought into a team that did not have it.

The Master Checkout Library file in Figma: named component sets for Order Summary, Billing Cycle, Billing Details Atoms, FAQ, Page Title, Legal Footer, Add-ons and Success Screen, each with a description and published components

The master file. Every set named, described, and published for the team.

The pattern

Measuring is what made disagree and commit actually work

Everyone says they disagree and commit. It only holds if the disagreement has somewhere to go. Without that, committing means the quieter person stopped talking, and the same argument comes back in three weeks with the same people and the same opinions, because nothing ever answered it.

Agreeing in advance how each one would be settled is what made it work. A week of traffic for the red. A round of research for the price. Committing costs you nothing when you know the question is going to get answered, and you can back something you argued against without it being a defeat, because the decision belongs to the evidence rather than to a person.

The saving is not the conversion points. It is the months nobody spent arguing about things nobody could settle.

What actually shipped, over eight months
  • Rewrote and restructured 4+ in-product landing pages
  • Redesigned the full checkout experience
  • Restyled the pricing page
  • Added Stripe and Apple Pay
  • Introduced upsell banners, modals and pricing highlights
  • Created prompts for yearly and two-year plans
  • A/B tested add-on flows and placement
  • Maintained the team library and design documentation in Figma
Impact

On a funnel that already worked

+2%

conversion on Business Listings, from a facelift on a page nobody owned

30%

faster checkout, from removed redundancy and better payment integrations

−10%

drop-off through the checkout flow

Moved, but without a clean number on it

Higher long-term plan adoption

Savings messaging that names the exact amount pushed people toward yearly and two-year plans, which lifts lifetime value and retention together.

More add-on revenue

Upsell points built into the checkout itself rather than bolted on afterwards, and tested for where they landed best.

Better design ops

A checkout and upsell library in Figma, standardised across breakpoints and states. This team did not have that practice before.

What I took from this

Where the value was hiding

The whole company was looking forward, which was the right call and left the present unattended. Nothing in this case was a discovery. It was all sitting in plain sight, in the flow customers were paying through that week, waiting for somebody to spend a quarter on it instead of on the next thing.

Looking after what already exists is not a lesser job. It is frequently the cheapest quarter a company has, and it is the one nobody volunteers for, because there is no launch at the end of it and no story to tell unless you go and write one.

Product Design Growth Design UX Research Usability Testing Experimentation A/B Testing Checkout Optimization Pricing Design Systems Stakeholder Management
Lucila Di Vanni Frick

Hola, I'm Lu. Senior Product Designer, 8+ years across different industries. I start with the real problem, make complexity understandable, and stay close to the outcome.
More about me →