
Added over $13M ARR by leading a systematised, global checkout redesign
+$13M added in ARR from design changes
+31% team admins adding users
+16% Pro to Business upgrade conversion
MY ROLE
Product Design Lead & acting Product Manager
SCOPE
Every checkout across global markets (31m paid users)
TIMELINE
2025 - 2026 (discovery to shipping 8 experiments)
TEAM
Engineer Manager, FE & BE Engineers, Data Scientist
Context
Nearly every dollar of Canva's $4B annual revenue passes through checkout: free trials, upgrades and team invites, across every platform, in dozens of currencies and payment methods.
I led design end-to-end with no dedicated Product Manager on the project. I owned product decisions from strategy and trade-offs down to interaction details and I acted as the conduit to Finance on ARR modelling, strategy on pricing, legal on regional compliance and senior leadership for approvals. Nothing got lost between design and product because one person held both.
Checkout is where three forces collide: what users want (transparency, low friction, trust), what the business wants (conversion, higher-tier adoption, fewer failed payments), and what the platform needs (scalability, localisation, compliance). Every decision that follows is a negotiation between the three - that tension is the real subject of this case study.

But checkout at Canva isn't a flow - it's hundreds of combinations of plan, team size, country, currency and payment method, with new ones added every few weeks. So I didn't design screens, I designed the system underneath them: components that absorb a new market, language or payment type without a redesign. Build it right once and every team that touches checkout after me inherits something that holds its shape instead of breaking.
Decision 1:
Close the research gap no one had noticed
Before touching UI, I wanted qualitative signal from the markets where the numbers were worst. I planned, ran and synthesised 33 interviews across Canva's key strategic markets - scattered through the project rather than front-loaded. I used mixed methods (moderated for early generative research, unmoderated for concept testing).

There was still a gap. Canva's research process only interviewed English-fluent participants, which meant our insights in Indonesia, Brazil and Vietnam (where under 3% of people speak English fluently) were coming from an unrepresentative slice of the market. We were making decisions for hundreds of millions of users on data from the ones most like us.
I looked at four options:
Keep the current process and accept the bias toward English speakers.
Do it in-house with bilingual staff - not scalable across all key languages.
Use AI translation - not accurate enough for the cultural and language nuance.
Bring in an external vendor with skilled bilingual researchers (what I chose).
I'd worked with a company called Askable before and knew they had plenty of freelance researchers ready to take on projects (I was once one of them!). I had discussions on requirements and ran a pilot study across Indonesia, Brazil, Mexico and Vietnam. I then partnered with Research Ops to scale it and wrote the guides for other teams.

Insights gave direction to multiple teams
Insights showed that payment preferences fragmented harder than we'd modelled.
Security was the top-ranked concern when paying online, above ease-of-use and rewards. Price was real friction - an annual Pro plan is ~14.7% of monthly income in Mexico. And in some countries, the generic US testimonial actively hurt trust:
"I find it weird having an American person saying this… feels like a scam." - Vietnamese participant

The bilingual-research process is now used by teams across the company. The insights also shaped roadmaps outside Checkout - Local Payments prioritised PIX, UPI and GoPay (tens of millions in ARR each), Subscriptions added shorter-duration plans off the Mexico pricing insight, and the Editor team launched offline editing informed by the same research.
The bigger lesson: before trusting the data, ask who it's missing. The most valuable gap on this project (non-English speakers) wasn't on anyone's roadmap.

Decision 2:
Which ‘base’ concept to build
Lots of optimisations were identified but we still needed a ‘base’ layout that would be scalable enough. I designed three concepts, tested them unmoderated with differing order to avoid bias, and reviewed the build with Engineering:
Full Screen - everything at a glance, fewer clicks. Initially scoped High effort.
Immersive Dialog - kept the current flow structure with a new look. Medium effort.
Summary Step - an added review screen at the end. Low effort.
All three beat the old checkout on completion and ease-of-use. Participants gave Full Screen a slight edge for speed and transparency. On its own, that wasn't enough to justify the build cost.

Assumptions were flipped after research and feasibility
Full Screen turned out to be easier to build than we'd assumed - High dropped to Medium. Summary Step turned out to be harder - the backend work to reconcile a review step against the existing payment state pushed it from Low to Very High. And Immersive Dialog carried heavy dependencies on the Onboarding team's roadmap, which meant we'd be blocked on someone else's priorities.
The decision that had looked like a close call became obvious. Full Screen: same effort as Dialog, higher ceiling, no cross-team blockers. Summary Step: killed. I moved forward with Full Screen as the primary concept and deprioritised the others.
The bigger lesson: UX preference and engineering reality had to be scoped together. Two of the three concepts changed effort tier once we did the joint scoping - if I'd committed on preference alone, I'd have shipped the wrong one.

Decision 3:
When to fork the experience
The Full Screen concept shipped as a series of controlled experiments across global markets and hundreds of scenarios. As it rolled out, one question kept coming back in different forms: should every checkout look the same? I decided: only where the user's need was genuinely different.
Fork by the user's moment? Yes.
Full Screen won as the base, but "always full screen" was wrong. The right weight of the checkout depended on why the user was there.
Mid-task - when someone was in the middle of a design and hit checkout (like adding a teammate), a subtle in-and-out dialog doubled the success rate of a large screen. A heavy screen punishes an interruption.
Deliberately upgrading - when someone had set out to move their team to a paid plan, a full-screen checkout was twice as effective. They had committed, so I gave them the full, transparent screen.
Same product, forked on intent: checkout as an interruption gets out of the way; checkout as the destination earns the whole screen.

Fork by user type? Yes.
A second experiment tested full screen against a smaller dialog, and the result split hard between paid and free users.
‘Paid’ users saw huge gains eg: +16% in upgrades from Pro to Business, +31% more admins expanding their team
‘Free’ users came back neutral at first: the new flow caused a drop at the top of the funnel that was offset by better conversion once users reached the checkout step.
That told me the downstream gain was real and worth protecting - the problem was purely the entry point for free users. So I forked there, introducing a 'Big Dialog' entry for free users that fixed the top-of-funnel drop while preserving the later conversion. I worked with the strategy team to model the pricing impact and with finance to size the ARR upside before committing to the fork.
The fork by user type turned a neutral result into $3M+ ARR without touching the paid-user flows.
The bigger lesson: "Should we fork?" is never one question. Fork where the user's need is genuinely and permanently different - their moment (interruption vs intent) and their segment (free vs paid) are worth building for. What I refused to fork on was everything that only looked different on the surface: market, language, payment method. That is a maintenance cost that compounds forever, and it is the subject of Decision 4.

Decision 4:
Build for scale, not for one market
A checkout built for the US broke in three ways as it globalised: long languages like German blew out layouts and pushed key info out of view, LPM-dominant markets like Indonesia met a checkout that didn't offer how they actually pay, and generic US testimonials made the whole thing feel less trustworthy in-market.
I could have fixed each with one-off market experiments. I built for scale instead:
Layout - flexible, systematised components that absorb long strings and reflow without hiding key info. This also drove 30+ copy changes across 6 languages.
Payment - surfaced LPMs first and structured the flow so new methods could be added without a redesign each time.
Trust - worked with International teams to source local testimonials that matched each market, rather than defaulting to US voices.
To make the complexity legible, I built interactive prototypes that render any scenario live - pick plan, team size, country, currency and payment method, and the prototype shows that exact checkout. Every row of a hundreds-long scenario spreadsheet became visible and clickable. I also built prototypes to visualise complex billing timelines where pro-rata, delivery and grace periods all interact.
Result: checkout stopped being a bottleneck and became a platform. The systematised components landed in the Canva Design System, and the Payments, Local Payments and Subscriptions teams now ship new methods and markets on top of the flow without a redesign or fresh testing. The scenario prototype became their source of truth, so they add features fast and with confidence they won't break the flow for someone in another market.
The clearest proof came from a purchase type that didn't exist when I designed the system. AI top-ups let Business users who hit their monthly AI limit buy a one-off, non-recurring top-up and keep working - a different shape of purchase from the subscription upgrades checkout was built for. I designed the flows, and they shipped across 8 markets on the platform I'd built: no redesign, no fresh checkout testing. The limit moment now offers three clear paths - keep generating with cooldowns, move to an AI Pass, or top up - and team admins can top up their members from the same flow. A new way to pay became a configuration, not a project.
The bigger lesson: designing for scale means designing for the next team, not just the next user. The highest-leverage thing I shipped wasn't a screen - it was infrastructure that lets people who aren't me ship confidently.
My key learnings
Work connections essential on big projects
Owning both design and product let me move fast between strategy and the pixels - but it also made me the main check on my own product calls. What made that workable was the relationships I'd already built across Canva: bringing teams into workshops, getting ad-hoc input, having the hard prioritisation conversations, and clearing approvals were all easier because the trust was already there.
Ask who isn't in the room.
The most valuable gap I found - non-English speakers being left out of research - wasn't on anyone's roadmap, and closing it changed our insights in exactly the markets that mattered most. I'd start the next discovery there: before trusting the data, ask who it's missing.
A feature is never really finished
In 12 months I took a flow that touches every market, platform and plan and made it easier to use, easier to trust, and easier for the next team to build on. The design changes added over $13M in revenue but there are still improvements to make.
That's the work I want more of: complex, high-stakes systems where good design shows up directly in the numbers.
Latest Projects




