Swift Checkout
Swift Checkout
Reducing Checkout Friction on a Mobile-First Ecommerce Platform
Role
Role
UI/UX Designer
UI/UX Designer
About Swift Checkout
About Swift Checkout
Swift Checkout is a payment and shipping solution, part of SWIFT (ICUBE product), designed to provide seamless payment and delivery experiences for clients using the SWIFT platform.
Swift Checkout is a payment and shipping solution, part of SWIFT (ICUBE product), designed to provide seamless payment and delivery experiences for clients using the SWIFT platform.
Executive Summary
Executive Summary
I've successfully redesigned flow consolidated checkout into a single page, surfaced hidden content, and introduced defaults across shipping and payment, cutting time-on-task by 40 to 80 percent on every measured task and lifting the SUS score from 87.5 to 90.
I've successfully redesigned flow consolidated checkout into a single page, surfaced hidden content, and introduced defaults across shipping and payment, cutting time-on-task by 40 to 80 percent on every measured task and lifting the SUS score from 87.5 to 90.
Background Story
Background Story
Swift Checkout is a payment and shipping solution used across several client checkouts. After nearly three years in market, leadership saw the product losing relevance and pushed for a revamp. The first step was a focused round of competitor and market-leader research to identify what the new version actually needed to do better.
Swift Checkout is a payment and shipping solution used across several client checkouts. After nearly three years in market, leadership saw the product losing relevance and pushed for a revamp. The first step was a focused round of competitor and market-leader research to identify what the new version actually needed to do better.
Challenges
Challenges
The main challenge was uncovering what executives actually wanted from a goals perspective. On top of that, we needed to research how Indonesian competitors approached checkout, looking at their flows, visual design, and the principles behind their decisions.
The main challenge was uncovering what executives actually wanted from a goals perspective. On top of that, we needed to research how Indonesian competitors approached checkout, looking at their flows, visual design, and the principles behind their decisions.
Start Designing: Epic Fail
Start Designing: Epic Fail
When I first picked up this project, I jumped straight into design. I tried a few directions I thought could work, but leadership felt none of them landed. That pushed me to step back and start with competitor research instead, and here is what I did.
When I first picked up this project, I jumped straight into design. I tried a few directions I thought could work, but leadership felt none of them landed. That pushed me to step back and start with competitor research instead, and here is what I did.
Before i start my reserach, i do usability testing for exsitng Swift Checkout to know the numbers and insight form user who usually checkout the items in top 3 marketplace in Indonesia.
Before i start my reserach, i do usability testing for exsitng Swift Checkout to know the numbers and insight form user who usually checkout the items in top 3 marketplace in Indonesia.
Research Competitor: They are IDENTICAL!
Research Competitor: They are IDENTICAL!
I started with the obvious players: Shopee, Lazada, TikTok Shop, and Tokopedia. At a glance, their checkouts looked nearly identical, and that was almost the conclusion I walked away with. But once I broke them down by flow, visual design, and the principles behind their decisions, a different picture emerged.
I started with the obvious players: Shopee, Lazada, TikTok Shop, and Tokopedia. At a glance, their checkouts looked nearly identical, and that was almost the conclusion I walked away with. But once I broke them down by flow, visual design, and the principles behind their decisions, a different picture emerged.
Finding: The structure is shared, the execution isn't
Finding: The structure is shared, the execution isn't
I started by asking what actually appears on a checkout screen. Shared structure matters because it lets customers recognize a layout instantly (Jakob's Law). To get a clear read, I mapped the mental model across Shopee, Tokopedia, and Lazada (I forgot include TIktok shop) , comparing both desktop and mobile app side by side.
I started by asking what actually appears on a checkout screen. Shared structure matters because it lets customers recognize a layout instantly (Jakob's Law). To get a clear read, I mapped the mental model across Shopee, Tokopedia, and Lazada (I forgot include TIktok shop) , comparing both desktop and mobile app side by side.
I ran each platform through a three-stage mental model:
User behavior, to map out the content shown on every checkout screen
Best practice, to flag the patterns repeating across platforms
From there, I clustered the findings into the insights below.
I ran each platform through a three-stage mental model:
User behavior, to map out the content shown on every checkout screen
Best practice, to flag the patterns repeating across platforms
From there, I clustered the findings into the insights below.
Three patterns emerged across the platforms I studied:
They all separated checkout content into the same core blocks: address, products, promo, and shipping.
Wherever there was a list of choices, one option was preselected as the default, lowering the cost of deciding.
The content was always visible up front, with no critical information tucked behind a tap or expand action.
That raised the obvious question: how was Swift Checkout handling this today?
Three patterns emerged across the platforms I studied:
They all separated checkout content into the same core blocks: address, products, promo, and shipping.
Wherever there was a list of choices, one option was preselected as the default, lowering the cost of deciding.
The content was always visible up front, with no critical information tucked behind a tap or expand action.
That raised the obvious question: how was Swift Checkout handling this today?
Swift Checkout: Mapping the Choices and Steps Behind the Friction
Swift Checkout: Mapping the Choices and Steps Behind the Friction
I mapped the existing Swift Checkout as a user flow first. Putting every screen and decision in one view made the journey easier to read end to end, from the entry point all the way to order placed, and gave me a clear surface to point at when identifying friction.
I mapped the existing Swift Checkout as a user flow first. Putting every screen and decision in one view made the journey easier to read end to end, from the entry point all the way to order placed, and gave me a clear surface to point at when identifying friction.
I found the flow pattern in Swift Checkout is different based on my research
I found the flow pattern in Swift Checkout is different based on my research
First Finding: A Pattern That Breaks Expectation
First Finding: A Pattern That Breaks Expectation
The first thing that stood out was the entry point. Most checkouts move the user straight from cart into a single page showing address, products, promo, and shipping.
Swift Checkout takes a detour first: a separate page asking for phone number and OTP verification before the actual checkout content even appears.
The cost is a heavy friction barrier sitting at the entry point, before the user has even seen what they are paying for.
The first thing that stood out was the entry point. Most checkouts move the user straight from cart into a single page showing address, products, promo, and shipping.
Swift Checkout takes a detour first: a separate page asking for phone number and OTP verification before the actual checkout content even appears.
The cost is a heavy friction barrier sitting at the entry point, before the user has even seen what they are paying for.
Second Finding: A Form That Asks Too Much
Second Finding: A Form That Asks Too Much
Following the flow into the address sub-flow surfaced the next issue. Adding a new address means working through a long stack of input fields, one after another.
The sheer volume creates a sense of being overwhelmed, and that is exactly the moment a customer is most likely to abandon the address step entirely and with it, the order.
Following the flow into the address sub-flow surfaced the next issue. Adding a new address means working through a long stack of input fields, one after another.
The sheer volume creates a sense of being overwhelmed, and that is exactly the moment a customer is most likely to abandon the address step entirely and with it, the order.
Third Finding: A Payment Method Hidden Behind a Tap
Third Finding: A Payment Method Hidden Behind a Tap
Following the flow into Step 3 surfaced one more issue. The list of payment methods is not visible by default. Customers have to tap into the payment field first before the options appear, adding an extra step right at the most business-critical moment of the checkout.
Friction anywhere in the flow is costly, but friction at payment is where it converts most directly into lost orders.
Following the flow into Step 3 surfaced one more issue. The list of payment methods is not visible by default. Customers have to tap into the payment field first before the options appear, adding an extra step right at the most business-critical moment of the checkout.
Friction anywhere in the flow is costly, but friction at payment is where it converts most directly into lost orders.
The three findings from the user flow translated directly into the problem that would guide the revamp:
Pattern that breaks expectation
Form that asks too much
Payment method hidden behind a tap
Every design decision from this point forward had to answer to one of these three.
The three findings from the user flow translated directly into the problem that would guide the revamp:
Pattern that breaks expectation
Form that asks too much
Payment method hidden behind a tap
Every design decision from this point forward had to answer to one of these three.
Solution: A Pattern That Meets Expectation
Solution: A Pattern That Meets Expectation
The entry point was the loudest anomaly the user flow surfaced. It pulls Swift Checkout away from the pattern customers have already internalized from Indonesia's market leaders, and that mismatch is doing most of the friction work on its own.
The focus of this solution is to bring Swift Checkout back into that shared pattern, so customers can read the flow and layout instinctively rather than having to learn it.
One question framed the rest of the work: can we remove the phone number requirement as the entry point of Swift Checkout entirely? Check Video Below
The entry point was the loudest anomaly the user flow surfaced. It pulls Swift Checkout away from the pattern customers have already internalized from Indonesia's market leaders, and that mismatch is doing most of the friction work on its own.
The focus of this solution is to bring Swift Checkout back into that shared pattern, so customers can read the flow and layout instinctively rather than having to learn it.
One question framed the rest of the work: can we remove the phone number requirement as the entry point of Swift Checkout entirely? Check Video Below
Swift Checkout is not a checkout in the same shape as Shopee, Tokopedia, or Lazada. It is a service that other websites and mobile commerce apps embed as their checkout engine, while the market leaders run their own engines internally. That difference is why the entry points feel so different.
The deeper constraint is around authentication. Indonesian ecommerce platforms require login before checkout. Swift Checkout cannot, because customers are on the client's site, often without an account. Phone number is the only stable way to identify them, and that is baked into the platform.
Which surfaced the real question: How do I solve for the customer's experience without breaking the technical reality the platform is built on?
Swift Checkout is not a checkout in the same shape as Shopee, Tokopedia, or Lazada. It is a service that other websites and mobile commerce apps embed as their checkout engine, while the market leaders run their own engines internally. That difference is why the entry points feel so different.
The deeper constraint is around authentication. Indonesian ecommerce platforms require login before checkout. Swift Checkout cannot, because customers are on the client's site, often without an account. Phone number is the only stable way to identify them, and that is baked into the platform.
Which surfaced the real question: How do I solve for the customer's experience without breaking the technical reality the platform is built on?
After a round of discussion with the team, we landed on the simplest move: pull the phone number to the front and combine it with the email section at the top. With that change, the entire checkout flow now lives on a single page.
After a round of discussion with the team, we landed on the simplest move: pull the phone number to the front and combine it with the email section at the top. With that change, the entire checkout flow now lives on a single page.
Solution: A Form That Provide Simpleness
Solution: A Form That Provide Simpleness
The earlier finding was that the form felt long and overwhelming, and the address section was carrying most of that weight. The solution we landed on is Fill and Auto Filled.
Instead of working through every field one by one, the customer types a few keywords or fragments of the address they remember, and the remaining fields fill themselves in below. What used to take a small eternity now takes a few seconds.
The earlier finding was that the form felt long and overwhelming, and the address section was carrying most of that weight. The solution we landed on is Fill and Auto Filled.
Instead of working through every field one by one, the customer types a few keywords or fragments of the address they remember, and the remaining fields fill themselves in below. What used to take a small eternity now takes a few seconds.
Fill and Auto Filled is the fast path. The form below it is for customers who would rather fill it in themselves, and it had to feel different from the usual long form.
The first change is in how each field works. Instead of a plain input box, every field is a dropdown you can search. Type a few letters and the list narrows down on its own. Search replaces scroll, and the form starts to feel less like a checklist and more like a quick check.
The second change is in how the location fields fit together. Country, State/Province, City, and Sub District are no longer four separate fields.
They share one input that opens up step by step, the way someone would actually describe where they live. Pick Indonesia, and the provinces appear. Pick Jawa Tengah, and the cities follow. Pick Kota Semarang, and the sub districts narrow down. Once the sub district is chosen, the postal code fills in on its own. One less field to think about, one less reason to slow down.
Fill and Auto Filled is the fast path. The form below it is for customers who would rather fill it in themselves, and it had to feel different from the usual long form.
The first change is in how each field works. Instead of a plain input box, every field is a dropdown you can search. Type a few letters and the list narrows down on its own. Search replaces scroll, and the form starts to feel less like a checklist and more like a quick check.
The second change is in how the location fields fit together. Country, State/Province, City, and Sub District are no longer four separate fields.
They share one input that opens up step by step, the way someone would actually describe where they live. Pick Indonesia, and the provinces appear. Pick Jawa Tengah, and the cities follow. Pick Kota Semarang, and the sub districts narrow down. Once the sub district is chosen, the postal code fills in on its own. One less field to think about, one less reason to slow down.
Solution: A Payment Method Just a Tap
Solution: A Payment Method Just a Tap
The earlier finding was that the payment methods stayed hidden behind a tap. Customers had to open the field before they could see what was available, and that extra step landed at the most business-critical moment in the flow.
The fix follows the same principle the research surfaced: keep the content visible up front. Payment categories now sit at the top of the section as chips, and the methods inside the selected category appear right below, ready to be picked without an extra tap.
For returning customers, the last method they used is remembered and set as the default, so the next checkout starts with the choice already made for customers.
The earlier finding was that the payment methods stayed hidden behind a tap. Customers had to open the field before they could see what was available, and that extra step landed at the most business-critical moment in the flow.
The fix follows the same principle the research surfaced: keep the content visible up front. Payment categories now sit at the top of the section as chips, and the methods inside the selected category appear right below, ready to be picked without an extra tap.
For returning customers, the last method they used is remembered and set as the default, so the next checkout starts with the choice already made for customers.
The default principle that worked for payment carried over naturally to Shipping Method and Promo. A sensible option in shipping method is preselected from the start, so the customer is not asked to make yet another choice mid-checkout. The decision is still theirs to change, but the flow no longer pauses to wait for it.
The default principle that worked for payment carried over naturally to Shipping Method and Promo. A sensible option in shipping method is preselected from the start, so the customer is not asked to make yet another choice mid-checkout. The decision is still theirs to change, but the flow no longer pauses to wait for it.
Result: Time-on-Task Down on Every Task
Result: Time-on-Task Down on Every Task
The benchmark gave each design decision a number to defend. All of them held up.
Task 1 — Fill the OTP: 21 → 13 seconds. The "Pattern that breaks expectation" got smaller once OTP and email lived on the same screen.
Task 2 — Fill email and address: 46 → 13 seconds. The "Form that asks too much" stopped feeling that way once Fill and Auto Filled and the bundled location dropdowns took over.
Task 3 — Choose shipping method: 15 → 3 seconds. The default principle quietly removed the decision before the customer had to make it.
Task 4 — Complete the payment: 54 → 16 seconds. The "Payment method hidden behind a tap" stopped being hidden, and returning customers no longer had to choose at all.
The benchmark gave each design decision a number to defend. All of them held up.
Task 1 — Fill the OTP: 21 → 13 seconds. The "Pattern that breaks expectation" got smaller once OTP and email lived on the same screen.
Task 2 — Fill email and address: 46 → 13 seconds. The "Form that asks too much" stopped feeling that way once Fill and Auto Filled and the bundled location dropdowns took over.
Task 3 — Choose shipping method: 15 → 3 seconds. The default principle quietly removed the decision before the customer had to make it.
Task 4 — Complete the payment: 54 → 16 seconds. The "Payment method hidden behind a tap" stopped being hidden, and returning customers no longer had to choose at all.
The SUS score moved alongside the times, from 87.5 to 90 out of 100. Already high to begin with, the new flow lifted it further while every task underneath it got faster.
The SUS score moved alongside the times, from 87.5 to 90 out of 100. Already high to begin with, the new flow lifted it further while every task underneath it got faster.
Impact: Leaders Aligned, Users Recognized, Clients Refreshed
Impact: Leaders Aligned, Users Recognized, Clients Refreshed
The new design landed well across all three sides of the project. Leadership signed off on the benchmark principles and the way they had been carried into Swift Checkout, giving the team a clear direction to build toward.
Users got a checkout that finally lined up with what they already knew from other clients' experiences. Familiar patterns made the flow feel easier from the first tap, which is exactly what a checkout is supposed to do.
Clients got a mobile-first checkout service built around speed at the moment that matters most. The expectation is straightforward: a faster checkout means more completed orders, and more completed orders means higher revenue.
The new design landed well across all three sides of the project. Leadership signed off on the benchmark principles and the way they had been carried into Swift Checkout, giving the team a clear direction to build toward.
Users got a checkout that finally lined up with what they already knew from other clients' experiences. Familiar patterns made the flow feel easier from the first tap, which is exactly what a checkout is supposed to do.
Clients got a mobile-first checkout service built around speed at the moment that matters most. The expectation is straightforward: a faster checkout means more completed orders, and more completed orders means higher revenue.
Key Takeaways
Key Takeaways
Familiar patterns are the brief, not a creative limit. The three principles drawn from Shopee, Tokopedia, and Lazada (shared structure, sensible defaults, nothing hidden) became the spine of every decision that followed. Customers were not asking for something new. They were asking for something they already understood, applied well.
Constraints reframe the problem instead of blocking it. The phone number requirement looked like friction until the platform's architecture became clear. Swift Checkout cannot require login, because customers are on the client's site, not Swift's. Once that was understood, the question shifted from "how do we remove this?" to "how do we make it disappear into the rest of the flow?". Folding phone verification into the email section on a single page was the answer.
The biggest gains came from removing decisions, not redesigning them. The largest time-on-task drops happened where defaults were introduced rather than where new UI was added. Shipping went from 15 to 3 seconds. Payment went from 54 to 16 seconds. The fastest interaction is the one the customer never has to make.
Numbers turn design decisions from opinion into argument. Time-on-task benchmarks across four tasks gave every design decision a measurable defense, and the SUS score lifted from 87.5 to 90 alongside them. Without the numbers, this would be a story. With them, it is evidence.
