YCLIENTS case study

Improving the payment flow in the mobile app

A shipped improvement of the mobile payment flow for service business administrators, focused on helping more users complete payments inside the app instead of switching to web.

Role

Product Designer

Product

B2B business management platform

Platform

Mobile app

Focus

Payment flow and workflow completeness

57%

payments processed in app before release

70%

payments processed in app after two months

+13 pp (+23%)

increase in app payment share

Context

YCLIENTS supports everyday operations for service businesses.

YCLIENTS is a B2B platform for appointment scheduling and business management, used by service businesses in their daily operations.

I worked on the mobile product team as a Product Designer. Our team's goal was to improve the administrator experience in the mobile app.

Research focus

Research and analytics pointed us toward payments.

To identify the biggest friction points, UX researchers conducted JTBD interviews with administrators. The research pointed to payments as one of the key problem areas.

We then looked at product analytics and saw that only 57% of users processed payments in the app, while the rest switched to the web version to complete the task.

Research signal

Payments stood out as a recurring pain point in administrator workflows.

Product signal

43% of app users still switched to web when processing payments.

JTBD mapping helped frame payments as a set of real operational scenarios, not just a single checkout action.

Problem

The mobile payment flow felt incomplete as an operational tool.

After narrowing the focus to payments, we reviewed the existing mobile payment flow in detail. We found that the app did not support all key payment scenarios needed in everyday work.

This made the mobile app less reliable for administrators: they could manage the appointment in the app, but still had to switch to web when the payment scenario became more complex.

Not all payment scenarios were available in the app
Unclear cash register selection
No QR code payment from the phone
No option to copy the payment link
No partial loyalty payment
Unclear split payment UX
Payment UI took too much space
Some actions and statuses were not obvious enough
The audit of the current flow surfaced both functional gaps and smaller UX issues that made payment less predictable.

My role

I was responsible for designing the payment flow improvements.

I analyzed the current flow, identified UX issues, explored design directions, created prototypes, iterated through usability testing, and refined the final solution.

I collaborated with a product manager and two UX researchers. Researchers led the interviews and usability tests; I participated by observing sessions, asking follow-up questions, and translating findings into design decisions.

Approach

The process moved from discovery to a focused payment redesign.

The work combined JTBD interviews, product analytics, a detailed review of the current payment flow, design exploration, prototyping, usability testing, and UX refinement.

  1. 01

    JTBD interviews

  2. 02

    Product analytics

  3. 03

    Existing flow audit

  4. 04

    Design exploration

  5. 05

    Prototype testing

  6. 06

    UX refinement

First direction

My first concept made mobile checkout closer to the web version.

The web version already supported more payment scenarios, so my initial concept was to make the mobile payment flow closer to web: more robust, more structured, and more functionally complete.

The web payment interface became a reference point for the first mobile direction.
Entry point
Quick payment
Detailed payment

Testing and turning point

Testing showed that the new structure added too much change.

Usability testing showed that although the concept added useful functionality, it made the flow feel more complicated. Users were already familiar with the existing interaction model, and the redesign introduced too much change for a high-frequency task.

The turning point was clear: users did not need a completely new payment model. They needed the existing flow to support more scenarios with less friction.

The first prototype validated several functional ideas, but also showed that the redesign felt heavier than the familiar flow.
The team decided to preserve the current flow and fix payment issues inside it.

Revised direction / Final solution

Improve the existing flow instead of replacing it.

After testing, I shifted the approach. Instead of redesigning the flow from scratch, I focused on improving the existing one: preserving familiar patterns while fixing the issues that blocked people from using the app for payments.

  • Added missing payment scenarios
  • Improved the existing flow without rebuilding it
  • Improved loyalty usage
  • Improved split payment handling
  • Added QR code payment support
  • Added clearer cash register selection
  • Reduced friction while keeping the experience familiar
Entry point
Quick payment
Register selection
Loyalty options
Split payment
QR payment

Outcome

More app users completed payments without switching to web.

After release, the share of users processing payments in the app grew from 57% to 70% in the first two months: a +13 percentage point increase, or +23% relative growth.

57%

of users processed payments in the app before release

70%

of users processed payments in the app after two months

+13pp

increase in app payment share

The second round of usability testing confirmed that the updated flow felt more convenient and easier to use.

Learnings

In mature B2B workflows, familiarity is part of usability.

In mature B2B workflows, targeted improvements often work better than a full redesign. For high-frequency operational tasks, familiarity matters.

The strongest solution was not to reinvent payment. It was to keep the interaction model users trusted, then carefully add the missing functionality where it naturally belonged.

Team

A cross-functional product effort.

Product Designer
Product Manager
2 UX Researchers