Building a Recurring Buy feature people keep using
The first release barely converted and few plans stayed active. I led the research and V2 redesign that improved sustained usage, then used the same evidence to explore how recurring plans could support more advanced strategies.
- Role
- Lead Product Designer
- Company
- OKX
- Scope
- Research, product strategy, end-to-end design
- Platform
- iOS · Android
- Team
- Partnered with 2 PMs and 3 engineers across iOS, Android, and backend
- Regions
- US · EU · SG
Results after V2
~99.6%
ACH order success
5×
Plans set up
+22%
More active plans
We launched it, but almost nobody kept using it
Recurring Buy let people buy on a schedule instead of placing every trade. In the first release, about 23% of people who entered setup created a plan, and about 5% kept using it.
The numbers told us the experience was not working. They did not tell us why.
Was the problem discovery, understanding, or the product itself?
A low conversion rate can point to very different problems. I designed and ran the study myself, framing three hypotheses and matching each to the evidence that could test it.
Could people find it?
I added entry points before and after the instant buy flow to test whether stronger discovery moved more people into setup.
Did they understand it?
I reviewed where people dropped out and whether setup explained the value and the commitment.
Did the product fit their needs?
I surveyed users about payment methods, plan visibility, performance detail, and trust after setup.
Before redesigning, I tested what was holding Recurring Buy back
I used A/B tests and product behavior to see which hypotheses held up, then surveyed users when the data could not explain why.
Interest was there. The bigger problem started after users committed.
Discovery experiments increased entry into the flow, but not sustained use. The product was asking people to delegate future purchases without supporting them afterward.
40%
Order failed due to funding issue
36%
Couldn’t see what the plan is doing
52%
Wanted more control over the recurring buy
The redesign needed to support the plan after creation, not just help users finish setup.
V2 — Make it easier to start, fund, and understand
V2 addressed the full plan lifecycle, not just the setup flow.
Make it easier to start
Recurring Buy moved into the familiar buy flow, where users chose to buy once or buy on a schedule in context.
Support how people already fund purchases
ACH and stablecoin funding shipped with V2. The constraint was the missing payment options, not the copy explaining them.
Make plans easier to find and understand
Recurring plans surfaced in Portfolio, Activity, and Transaction History. The plan view added average purchase price, current price, total invested, performance, and order history.
When users delegate an action, the product has to keep them informed
Repeated low-balance failures pause the plan and explain what happened. Removing a payment method shows which recurring plans it affects before the user confirms.
Give users full control over an active plan
People could edit the amount, frequency, and payment method on a running plan, or pause and cancel it without contacting support.
The product changes showed up in sustained usage
After V2 launched, Recurring Buy became more reliable and more people kept their plans active.
~99.6%
ACH order success
5×
Plans set up
+22%
More active plans
The redesign did more than improve setup conversion. It supported the plan after the user had delegated it.
I saw a way Recurring Buy could be useful to more people
As a trader, I liked automation but not buying at any price. I treated that as a hypothesis rather than a requirement, and tested whether other users felt it too.
The research showed the need was bigger than my own behavior.
47%
wanted more control over timing
52%
stopped when market conditions changed
Users understood the value of automation. A fixed schedule just could not respond to their view of the market.
Design direction
Buy on a schedule, only within your price range
The first direction added one condition to the schedule. Users set the range where they were comfortable buying, and the plan placed the scheduled order only when price was inside it.
The plan captures the intent. Strategy changes how it executes.
Keep the amount page simple. Let strategies grow separately.
A price range added decisions to a setup page that had to stay easy for first-time users. So I separated the recurring plan from the strategy applied to it.
A recurring plan stays the foundation. Strategies become optional layers on top.
One model that can grow beyond Price Range
The amount page stays focused on creating a standard plan. Users who want more control add a strategy afterward from Plan Details.
- The base plan holds the amount, asset, payment method, and schedule.
- Price Range becomes an optional strategy that changes when the plan executes.
- The same structure can support future strategies.
Design principle
Simple does not mean basic
A simple default protects the main job. A scalable structure gives experienced users more control without making everyone learn the complexity upfront.
