1
Scope — a new marketplace and a new buying behaviour
Bidding touched almost every page in the app — end-to-end design, not a feature
Designing the end-to-end proxy bidding experience for Collect2Day
JDirectItem Auction is an external Japanese auction marketplace. Behind every bid sits a web of payment, bid and refund states. I designed it so users only ever see one clear status and one next step, and can bid on Japanese collectibles without leaving the app.
Background
Collect2Day (formerly Buyandship One) is a cross-border ecommerce platform that lets users access international marketplaces from one place. To expand the catalogue for users hunting Japanese goods, we integrated JDirectItem Auction, a major Japanese C2C auction marketplace.
The integration had to handle two purchase modes that behave very differently. Buy-out items follow a standard add-to-cart flow. Auction bidding demands real-time state, fast confirmation windows, and recovery flows when users get outbid.
Defining success with PM and engineering
Key contributions
- Partnered with PMs and engineering to turn a complex auction state machine into a flow that feels like a standard checkout: one upfront payment, pre-filled bids, and 6 clear statuses in place of 9 backend combinations
- Defined the shared bid status model with backend, adding a dedicated Outbid status that every downstream team now uses
- Led design across the full bidding lifecycle, scoping PDP, checkout, order management, notifications, and refunds into one coherent experience
- Designed the full bidding experience: dual-currency flow, pre-filled Place Bid screen with real-time conversion and cost breakdown, and a bid management system where each status card surfaces only what the user needs at that moment
The challenge
This wasn't a single feature — it was a new commerce model layered onto an existing eCommerce app. Bidding reached into PDP, checkout, order management, notifications, and refunds.
2
Case complexity — auction state explodes into edge cases
Payment timeouts, failed payments, repeated raises and outbids can overlap. Each one needed a defined system behaviour and a clear way back for the user.
3
API constraints — design bounded by what the API returns
The external API defined what data was available. The design had to work within those limits, while still giving users everything they needed
4
Confidence — easy to lose when multiple actions run at once
A user can have a bid pending, a refund in progress, and an outbid notification — all at the same time. Every unresolved state is a chance to feel something's gone wrong.
Bidding flow design
Designed to create a consistent experience across bidding and shopping
Most proxy bidding platforms split payment across two moments. I designed the bid flow to consolidate all fees into a single upfront payment, so it's like a standard eCommerce checkout.
Design highlights
Highlight #01Taking the maths out of placing a bid
I designed the Place Bid screen to pre-fill the minimum bid and offer two one-tap increments— removing calculation from a time-sensitive decision. A full cost breakdown alongside eliminates checkout surprise.
- 1Pre-filled minimum bid — pre-filled minimum valid bid JP¥85,000
- 2Real-time HKD inline — auto-converts at platform rate, no currency switching needed
- 3Three quick-select increments — confirm minimum or step up in one tap
- 4Full cost breakdown — bid + tax + domestic shipping, itemised before you confirm
1234One primary currency per screen
Context
Two currencies in one flow
JDirectItem Auction is a Japanese platform; bid increments are in JPY. But Collect2Day users pay in HKD.
Risk
Confusion under pressure
Two currencies in one flow leads to confusion, especially under auction time pressure.
Decision
One currency per screen
JPY while bidding, HKD at checkout — one primary currency per screen.
Making bid statuses easy to understand
I mapped 9 backend combinations across payment, item, and order layers into 6 user-facing statuses, each with its own fields, urgency, and next action.
- Bid order created, awaiting payment
CREATED - Payment failed or cancelled, retry allowed
PAYMENT_UNSUCCESSFUL
Pending payment
- Payment authorised, bid queued
CONFIRMED - Payment authorised, bid placed
IN_PROGRESS
Bid in progress
- Bid rejected, auction still live, hold releasing
LOSE_BID
OutbidNew status, adopted by backend
- Won, payment being captured
WIN_BID - Payment captured, order created
COMPLETED
Won
- Auction ended, hold released
LOSE_BID → CLOSED
Lost
- Not paid within 5 minutes, bid never sent
CANCELLED / CLOSED
ClosedSame backend end state as Lost, but no bid was ever placed
Adding "Outbid" to the shared status model
I pushed for Outbid to become a dedicated backend status, not an app-side label, so every team downstream works from the same definition. When edge cases in the API surfaced, a quick patch on the app side would have shipped fastest, but every other surface would still have treated the same situation as "Lost." I made the case to backend with concrete user-flow evidence, and together we agreed on the new status.
Design decisionOutbid is designed to keep users informed without misleading them. A state the experience needed, and the backend eventually adopted.
Principle 01
Clear
"Outbid", not "Lost". The auction is still running.
Principle 02
Actionable
Current price vs their max, with a direct path to bid again.
Principle 03
Reassuring
Refund confirmation shows immediately. Every past bid and its refund stays traceable in bid details.
Showing only what matters for each status
Each card shows only the fields that drive the user's next move, and names that move. The card's shape adapts to the state rather than forcing every status into one layout.
| Status | Info shown | User action |
|---|---|---|
| Bid in progress | Max bid · Current bid · Time remaining | Keep watching — raise max if outbid |
| Bid in progresswhen max − current ≤ bid increment | Raise prompt as current bid nears Max bid | Raise Max bid before being outbid |
| Outbid | Max bid · Current bid · Time remaining | Raise max bid — or accept the loss |
| Won | Max bid · Won bid | View orders for parcel status |
| Lost | Max bid · Winning bid | Check refund — no further action |
| Pending payment | Max bid · Current bid · Time remaining (alert) | Pay before timeout to keep the bid |
| Closed | Max bid · Reason: payment not completed | Place a new bid while the auction is open |
A fallback pathway for every edge case
For each edge case I defined what the system does, what the user sees, and how they get back on track. Where possible, the design prevents the problem instead of recovering from it: the price is checked again before payment, so users aren't charged for a bid that's already been beaten.
| Situation | User sees | Recovery | System behaviour |
|---|---|---|---|
| Payment times out before the bid is placed | Closed, with a "Bid order closed" notification | Place a new bid while the auction is open; the coupon can be reused | Order closes after 5 minutes; bid never sent |
| Payment fails | Pending payment, with the time left to pay | Retry payment before the timeout | Order stays open for retry |
| Current price passes the max bid before payment | A prompt to raise the max bid | Raise the max bid, or leave without paying | Price re-checked before payment |
| Outbid while the auction is live | Outbid, with current bid next to max bid | Bid again from the Outbid card; the old hold refunds automatically | Bid rejected; payment hold released |
| Raising a bid several times | Every past bid with its own refund status, in bid details | Automatic, no action needed | New order per raise; old hold released |
Making every refund easy to track
Most recoveries end in a refund, so every bid on an item can be tracked. Tap any entry to see its payment record, refund status, and exact amount.
- Bid history — every bid placed on this item, in order
- Payment record — tap any bid to see its payment detail
- Refund status — in progress or completed, with expected date
Outcome
Bidding launched first in HK, MO and SG, followed by MY and PH. In the first three weeks, 451 users placed 1,528 bids, and many of them came back to bid again.
0
Active bidders in the first month
0%
Came back to bid again
0
Bids per bidder on average
Losing is the normal outcome, not the edge case. 65% of bids end lost and only about 1 in 10 wins, so most bidders see a refund far more often than a win. That backs the decision to make every refund traceable, bid by bid.
People bid at hours when they can't watch. A third of all bids arrive between midnight and 5am HKT, peaking at 4am. Few people sit up to watch an auction close, which is why setting a max bid once and the Outbid notification matter. It may also be part of why 27.2% of orders miss the 5-minute payment window.
What's next
Fix unpaid bids
27.2% of bid orders go unpaid. Study the payment step and test saved payment methods
One-tap rebid from Outbid
Raise the max straight from the notification, with the next bid pre-filled
A next step after losing
Suggest similar live auctions on the Lost card to keep users hunting