Mobile Apps & Webs

In 2023–2024, Traveloka planned a market expansion into Japan and South Korea, both seen as potentially fast-growing markets. However, Traveloka had neither a design or research team based in Japan or Korea, nor a registered business entity there yet. Rather than wait and lose momentum, the team looked at an alternative: researching the behavior of international audiences it already had, to get an early insight into what the expansion might mean for payment flow. That existing data showed a clear pattern: most international users purchased through desktop rather than the app, yet the desktop payment flow had not been redesigned since 2017. That gap became the starting point for the project: redesigning the desktop payment flow.

As part of the Payment team, we wanted the desktop flow to be similar to the app's usability. At the same time, the core design team was still finalizing a new visual brand guideline. That left a decision to make: use the old design system, or use the new one while it was still evolving. I chose the new design system, even without a fully established guideline. There were two reasons: the scope of payment page redesign could grow unpredictably the longer we waited, risking a clash with the expansion's launch timeline, and the interface design of payment in desktop was already outdated with the existing brand. Together, these decisions made the scope and complexity larger than a usual redesign.

We also gathered requirements from every products that exists on Traveloka, since they all flowed through the same payment page. One of the more complex requirements came from the Accommodation team, which covers hotels, apartments, villas, and similar stays. As Traveloka's largest revenue driver, they wanted to show tax apart from the product price and simplify the discount terminology, hoping it could help Accommodation prices appear more competitive.

Business Goals

Maintain the desktop conversion rate through the redesign.
Longer term, aligning desktop and app payment flows aims to reduce friction at checkout across platforms.

My Role

As UI/UX Designer, my core responsibility was translating the wireframe concept into visual design. I also took the initiative to involved in research, synthesis, and design principle creation that conducted with the Interaction Designer. This collaboration helped reduce misalignment later in the process. Beyond design, I facilitated communication across close to 30 stakeholders from different divisions in one room, while also being the only visual designer on the payment team handling smaller ad hoc requests alongside this project.

Timeline

The original plan was 4 weeks that consist of exploring the interface, running the design critique, testing, and finalizing for handoff. I negotiated an extra 2 weeks upfront as a buffer, because of the shift to international audiences and the lack of existing data on the desktop flow. That buffer proved necessary: usability testing ran longer than planned, and two rounds of alignment, first with Payment Engineering, then with the accommodation team, added more time than expected.

Research

Learning The New Visual Brand Guideline

Instead of visualizing the wireframe into user interface directly, I stepped back and applied Double Diamond approach to avoid inheriting bias. Exploring alternatives early made space for critique and stronger design decisions.

I also learn to understand the new Design System Principles which derivative from Traveloka’s New Brand Guideline. The challenge is how to apply without breaking existing Payment Guideline Principles (Clarity, Credibility, Accessibility).

Breathable

01.

Breathable → applied by increasing spacing and grouping information so the page feels lighter without hiding critical details (price, method, time).

Purposeful

02.

Purposeful → ensure every element had a clear justification. I also tried to use conservative color usage in a high-stakes flow to avoid distraction or misinterpretation.

Immersive

03.

Immersive → applied subtle motion/imagery to reflect the travel brand, only where it didn’t add friction to completing payment.

Component Exploration

Payment Options
Payment Timer (Urgency Segment)
Coupon Redeem

Payment Options
Payment Timer (Urgency Segment)
Coupon Redeem

Scarcity
Product Details
Price Details

Scarcity
Product Details
Price Details

The Interaction Designer had already divided the page into several components. So, I explored each of them from balance, usability, and scalability before combining into a full page. Explored per section helped to stress test the text, icon, color, and shape choices with more confidence, and it built a solid foundation for the next stage.

Ideation

Shaping the full page experience.

After exploring components, I reassemble in one payment page. The purpose is to stress-test each of component to balance principles, visual and usability. Two decisions stood out:

Using lime green as the background for the Payment Time component can read as urgent, but it distracted from the user's main task of choosing a payment method.

I removed the breadcrumb because it was not self-explanatory. It just added cognitive load without helping users complete payment faster. Removing it simplified the flow and aligned it with the clarity principle.

Design Critique with Other Products Teams

To catch blind spots outside my own perspective, I conducted an offline design critique using FigJam with designers, product manager, and engineers from other product teams. I explained the project context and the design decision that I had made. Participants were grouped with their teams and wrote comments on sticky notes under three categories: what worked well (compliment), what needed improvement (feedback), and what felt unclear (questions). After that, they voted the three most interesting comments and I used those as a hook to open discussion so other participants could weigh in. When the same concerns came up across multiple groups, it signaled the level of critical to iterate it before moving to usability testing.

Some of components that has a critical usability issue and need to iterate before test:

The Price Details component that carried too much informations which caused confusion.
The Scarcity component was easy to miss because the location is hidden.

The images above show comments from Acommodation product team.

HIFI ITERATION

Prototype & Usability Testing

The prototype was tested with three participants based on Indonesia and three participants based in Singapore with at least purchased anything once via desktop. As an early step, we used the Singapore group to gather insight into how international users' behavior differed from Indonesia-based users. Sessions conducted offline for Indonesia-based and over Zoom for the international group. Designers and the Product Manager joined as observers to gather insight from their own perspectives.

One of the biggest concerns raised in the design critique was that the page felt too long before reaching the total price, especially in the Indonesian flow where the number of payment methods varied. To test this hypothesis whether participants actually needed final price upfront before complete their payment, I added a new component called Price Floating that stayed fixed on screen while scrolling, and tested it across both groups.

Based on the testing, we got insight for the Floating Price component:

Indonesia-based participants found Price Floating nice to have, but not essential. Seeing the full price breakdown to confirm there were no hidden fees mattered more to them. They also had no issue scrolling a bit longer to check it.

International participants found Price Floating distracting. Credit card already felt like the simplest choice for them, so seeing the total price quickly did not require a floating component either.

This showed that payment methods should be tailored to each country's demands rather than standardized. Neither group showed a strong need for Price Floating: Indonesia-based participants found it nice to have but not essential, while international participants found it distracting and risky to keep, since they were already unfamiliar with having multiple payment options. So, I removed Price Floating, but left it open for future iteration, with a note to adapt it to each country's payment behavior.

Re-iterating Design

Two components needed major revisions after usability testing: Scarcity and Price Details.

Scarcity Component

The problem was the placement was hidden and too contrast visual, making assumptions if it was an advertisement. The scarcity encourage participants to complete their payment faster before the product availability is run out. So, I refined visual cues and change the proper position near the Product Details component. This placement made to urgency component more visible trustworthy without overwhelming users.

Price Details Component

Usability testing focused on three problems that led to misunderstanding:

The "Traveloka Price" terminology was not self-explanatory.
A standalone tax line that added cognitive load,
The way the breakdown was calculated caused confusion.

These issues caused hesitation that some participants abandoned their purchase over doubts about price accuracy.

To explore how to fix this, I reached out individually to visual designers from other product teams and worked through the problem together in a cross-product design sync. The session gave me several ideas, and I combined them into an iterated design that included the accommodation team's request to show tax separately and merge the discount terminology into a single line.

ALIGNMENT

With Payment Engineering

Payment Engineering had already seen the concept early, during the design critique and again when I shared the prototype. From there, they started their own assessment, which took about two weeks since many other products touched the payment flow and needed to be checked.

That assessment ran in parallel with the usability testing and the design iteration described above. By the time I brought the iterated design back, Payment Engineering had finished their assessment separately. At first, the new Price Details design looked simple to them, since they were only considering the front-end changes. After the full assessment, though, they found it would also affect the database and the fraud detection system, not just pricing. The change was more complex than it first appeared, so they proposed keeping the existing design instead.

With Acommodation Team

After hearing Payment Engineering's proposal and weighing the risks and benefits of the new Price Details design, this became a real dilemma. Rejecting the Accommodation team's request outright was not a real option to begin with.

So I discussed it closely with my team on how to present this as an open decision for the Accommodation team to explore, rather than pushing them toward one design. I brought both options to the Accommodation team: the Price Details design with their requirements, and the existing design Payment Engineering suggested, along with the risks and benefits of each, to keep the discussion open.

The Accommodation team ultimately kept the existing pricing logic. They did not have the resources or time to pursue the new design without breaking the release timeline Payment Engineering had already planned. But the door was left open for them to revisit the idea with the payment team in the future.

FInal design

Outcome

The final design, reflecting the decision to keep existing pricing logic while improving how the breakdown was presented.

Handoff

I prepared detailed design documentation in Figma, aligned with Traveloka's design system and existing engineering constraints, including component mappings, spacing rules, states, and interaction notes. I worked closely with Payment Engineering during handoff to ensure:

Visual hierarchy translated accurately into implementation
Edge cases were identified early to avoid regressions

REFLECTIONs

What I'd do differently

Clarity beats complexity in high-stakes flows like payment. Even a well-intended addition, like showing a new price breakdown only on the payment page, created friction because it was not introduced earlier in the user journey.
Aligning engineering, product, and design in large forums takes a clear, well-prepared strategy, not just good intentions.
Knowing how many iterations a project actually needs, based on what previous rounds of feedback already resolved, avoids redundant discussion in later sessions.
A payment page should prioritize trust and reassurance over expressiveness.
Using Singapore-based research as an early proxy did not answer which payment methods Japan and Korea would actually prefer, or how copywriting should adapt for those markets. Both remained open questions for local teams to research once feasible.
This project sharpened how I navigate ambiguity, balance technical constraints against design intent, and still deliver a solution the whole team could stand behind.