Case Study
Sublium
Reducing WooCommerce subscription setup from 6 hours to 4 minutes
| The challenge | WooCommerce merchants were abandoning subscription setup after hours of failure. Existing tools required developer-level knowledge to do something merchants expected to take minutes. |
| My role | Lead Product Designer, end-to-end: research, strategy, interaction design, usability testing, launch |
| Team | 1 PM, 3 Engineers, 1 Marketing Lead |
| Timeline | 6 months, Aug 2024 - Jan 2025 |
| Tools | Figma, Maze, Hotjar, Amplitude |
My design philosophy: The gap between how users think and how systems are built is almost always the real problem. Close that gap and complexity becomes invisible. Miss it and no amount of good design saves you.
The Problem
I watched Sarah's Hotjar recording on a Saturday afternoon. She was setting up monthly tea deliveries. She started at 2:14 PM. By 8:47 PM, she'd closed the tab.
Six hours. Zero subscriptions launched.
I recruited 11 more merchants who'd attempted and abandoned similar setups. Every session had the same shape, long stretches of confusion, followed by giving up.
"I just want customers to get tea every month. Why do I need to understand billing synchronization?"
The problem wasn't that the tools lacked features. It was that the tools spoke a different language than the people using them.
Merchants think in customer outcomes: "deliver coffee monthly with 10% off." Plugins demand system fluency: "create a variable product with 30-day billing intervals, configure a subscription coupon with renewal conditions, and set a day-1 synchronization anchor."
That translation gap was where everyone got lost.
From 12 user interviews and 847 support ticket reviews, the failures clustered into three categories.
Setup complexity: Average time to first working subscription: 4-6 hours. 47% of that time decoding terminology, 31% trial-and-error, 22% debugging why the subscription wasn't appearing.
Architectural inflexibility: Physical products with "Subscribe & Save" couldn't coexist with digital memberships without custom workarounds.
Customer self-service failures: When subscribers wanted to pause, skip, or swap products, existing portals were confusing enough that most just cancelled instead.
"When Sarah's first subscriber tried to pause deliveries for vacation, there was no pause option. The customer cancelled. Sarah lost $2,000 in annual recurring revenue because of a missing button."
What We Were Building Against
FunnelKit had 50,000 WooCommerce merchants using its checkout tools. Our support data kept surfacing the same pattern, merchants trying and failing to add subscriptions. 32% searched for "subscription" in our docs within their first week. Most never got there.
The market leader, WooCommerce Subscriptions at $199/year, was technically capable but built for developers, not store owners. We had a distribution advantage (50K merchants), a trust advantage (they already used our checkout), and a clear gap to fill.
I installed every major competitor and ran identical setup tasks in each.
| Plugin | Setup time | Settings | The moment that told me everything |
|---|---|---|---|
| WooCommerce Subscriptions | 4h 37m | 212 | I searched for "monthly subscription." It doesn't exist. Only "billing period" and "synchronization interval." The vocabulary assumed I already knew how billing systems work. |
| YITH Subscriptions | 3h 52m | 187 | Better labels, but settings still organised by system component rather than merchant goal. |
| Subscriptio | 5h 18m | 160+ | The wizard asked me to configure the payment gateway before I'd defined what I was selling. |
Every competitor had optimised for technical completeness, not for the moment a first-time merchant tries to get something working.
Research: From Observation to Diagnosis
Twelve interviews and 847 support tickets gave me raw material. But raw material isn't a diagnosis.
I ran two rounds of affinity mapping. In the first pass, I grouped observations by where in the setup flow merchants got stuck. I expected failures distributed across steps. Instead, 71% of breakdowns clustered in the first 20 minutes, before anyone reached pricing or trial configuration.
That pointed to a foundational problem, not a feature problem. Merchants weren't failing because a particular setting was unclear. They couldn't establish basic orientation at all.
I stress-tested three explanations: poor onboarding copy, missing in-app documentation, and a mental model mismatch. Prototyped fixes for each, tested with 5 merchants each. Better copy reduced setup time by 11%. An in-app help sidebar: 14%. Neither was significant enough. Only the mental model reframe, restructuring the entire flow around how merchants think about their business, produced the step-change improvement the data indicated was possible.
Outside WordPress, Shopify and Stripe showed what the right direction looked like: smart defaults over configuration, plain language throughout ("Deliver monthly" not "30-day billing interval"). The best tools let users think in their own terms.
Three Attempts
Attempt 1: The settings panel
Tabs organising different configuration areas. Five merchants tested it. Same reaction: "Where do I even start?"
I'd organised the complexity. I hadn't removed it.
Attempt 2: The setup wizard
A guided five-step flow: product type, frequency, pricing, trial, review. All 8 participants completed setup. Average time: 8 minutes.
Then I asked them to change one setting.
The wizard forced them back through all five steps.
"This is great the first time, but now it's in my way."
Wizards optimise for first use at the expense of ongoing use. Since merchants edit subscription plans constantly, this was the wrong trade-off.
Attempt 3: The settings panel with better labels
Before committing to a new architecture, I tested whether better labelling alone could fix the problem. I replaced every technical term with plain-language equivalents. "30-day billing interval" became "Monthly." "Synchronization anchor" became "Billing start date."
It helped. Setup time dropped to 2h 40m on average. Still nearly 40 times longer than our target.
The labels were better. The structure was still wrong.
The Architecture That Worked
During one session, I noticed a merchant wasn't just setting up one subscription. She was defining options, monthly, quarterly, annual, then deciding which products each applied to. Two separate activities. The plugin treated them as one.
Before building on this observation, I validated it. I asked the next 6 merchants in research: "When you think about your subscription business, do you think about your pricing options first or your products first?" Five of six described subscription options as a distinct business decision, "my pricing tiers," separate from the product catalogue.
Tier 1, Plan Library: Merchants create reusable plans once. Edit one plan, updates cascade to every product that uses it.
Tier 2, Product Application: On any product edit screen, one toggle. Select plans. Done in 30 seconds.
I built a prototype in 3 days and tested with 8 merchants. All completed setup in under 5 minutes. Asked to add subscriptions to a second product the next day, every one did it in under 30 seconds without prompting.
The PM pushed back at the design review: "Merchants with one product type won't need a library, this adds steps." She was right to challenge it. I ran a stress-test on single-product-type merchants and came back with data: even single-product merchants created an average of 2.4 subscription tiers. The library was always simpler, even in her edge case. That challenge made the architecture stronger.
Accessibility built in from the start: Before wireframing, I audited the three competitor plugins for keyboard accessibility. All three had failures, radio groups not announced by screen readers, modal dialogs not trapping focus. I used this as a checklist for Sublium, and tested with VoiceOver during the prototype phase, before engineering picked up the work.
Why radio buttons over dropdown for billing frequency: Dropdown users took 4-8 seconds to scan options. Radio users: 1-2 seconds. For a small, fixed option set, radio buttons are always faster, and navigable by arrow key without the two-step "open then select" interaction.
Why trial period is collapsed by default: 18% of WooCommerce subscriptions include trials. Showing trial options open confused the 82% who didn't want them. They'd spend time "turning off" a setting that was never on.
The customer portal, two approaches tested: I tested action-first (pause immediately, confirm after) vs. preview-first (show outcome before commitment). Action-first: 23% "I didn't mean to do that" rate. Preview-first: 2%. The extra step wasn't friction, it was confidence.
The live preview panel: Merchants were tabbing between settings and their live store to verify configuration. I added a real-time preview panel, configuration errors dropped 67%.
Navigating the engineering constraint: Our lead engineer flagged that global plan management would add 12 weeks. I designed the V1 interface to accommodate global plans while shipping product-level plans first, identical UI components, different data source. When global plans shipped, zero merchants needed to relearn anything.
What I'd Do Differently
What I underestimated: brand diversity
45% of merchants post-launch wanted to customise copy, colour, or positioning. My "smart defaults" philosophy produced something average that served neither fitness brands nor luxury brands well. I'd add a brand personality preset at setup. (Shipping V1.5, March 2025.)
The feature I cut that we needed
I pushed back on a "subscription notes" field for merchant-side notes on individual subscribers. It became the third most-requested feature post-launch. I'd filtered genuine operational needs through a simplicity lens that was too narrow.
What I'd test differently
I tested with merchants who'd failed setup. I didn't test with merchants who had working subscriptions with competitors. Migration friction was higher than expected, merchants with 500+ active subscribers wouldn't recreate plans manually, even for a better product.
What I'd keep
The two-tier architecture held under real-world pressure. One merchant needed to change pricing across 34 products simultaneously, she edited one plan, 30 seconds. Two edge cases tried to break the model (product-specific pricing variations, global plan pausing), both extended it cleanly rather than contradicting it. And the V2 migration proved the constraint decision right: zero re-onboarding when a new data architecture shipped.
Results
FunnelKit's previous product took 6 months to reach 1,000 installations. Sublium reached it in 90 days.
What's Next
- Global plan management (Q1 2025)
- Churn prediction and win-back automation
- Multi-currency support
1,000+
Installs in 90 days
4.8 / 5
Rating, 127 reviews
$120K+
Combined merchant MRR
4 min
Average setup time
94%
Setup without a support ticket
12%
Setup tickets (down from 45%)
More Projects