Coordinating 6 teams across 3 countries to ship one product

The product

Level Up was a short-term loans app targeting low-income Thai families — a segment typically underserved by traditional banking and overcharged by informal lenders. The product's central insight was that financial behaviour could be shaped through incentive design: reliable repayment behaviour should be rewarded, not just punished when it breaks down.

The gamification system was directly tied to financial outcomes. APR decreased with consistent repayment behaviour — the more reliably you repaid, the less you paid to borrow. Milestone rewards were built into the onboarding flow, recognising customers at each stage: sign-up, KYC completion, approval, first loan, first repayment. This turned a typically anxious process into a progressive experience with clear markers of progress and reward.

For the target user — someone who may never have had a formal loan before — these design decisions had real financial consequences. Getting the UX right wasn't just about conversion rates. It was about whether someone understood what they were signing up for and whether they felt equipped to manage it.

The coordination challenge

The structure was deliberately parallel: six teams, each comprising designers, developers, and a product owner, working on separate features of the same product simultaneously. The theory was velocity — more teams, faster delivery. The reality was that without tight coordination, you'd end up with six features that didn't fit together.

I was responsible for the Palo IT designers across all three offices, working alongside SCB TechX's internal design principal to align on goals and standards across all six teams. That meant operating at two levels simultaneously: managing my own team's output and ensuring the full product remained coherent.

How it worked

The sprint model

Each 2-week sprint followed the same pattern: teams worked independently on their assigned feature, with daily standups within each team and regular cross-team syncs to catch divergence early. At the end of each sprint, output from all six teams came together in an integration review — where the design consistency work either paid off or didn't.

Design system as coordination tool

The design system was the primary mechanism for keeping six teams aligned. Two designers were dedicated full-time to system ownership — not building features, but maintaining and evolving the component library and auditing new components as teams created them.

The process was deliberate: lo-fi wireframes were not held to strict component standards — they were for thinking, not building. But once a feature moved to hi-fi, it had to be built from the shared library. Any new component a team needed went through the system owners for review before being added to the library and made available to all teams.

This meant the system evolved with the product rather than being a constraint on it. Teams weren't blocked by missing components — they could propose and build them — but the quality gate ensured the library stayed consistent and the end product felt like it came from one place.

Alignment across organisations

The structural complexity wasn't just geographic. Palo IT designers were agency staff. SCB TechX had their own internal design team with their own standards, culture, and priorities. Getting those two groups aligned — without either side feeling like they were being overruled — required working closely with SCB's design principal to establish shared goals and a shared language before the sprint work began.

My role was bridge: representing the Palo IT team's approach upward to SCB, and representing SCB's requirements and standards back to my own team. That dual accountability is what kept the work cohesive.

What this demonstrates

This project isn't a showcase of interface design. It's a demonstration of design leadership at scale — coordinating a distributed team across time zones and organisational boundaries, maintaining quality standards without slowing delivery, and keeping a product coherent when six teams are simultaneously building it.

The same principles apply at any scale. Clarity of goals, a shared design language, quality gates at the right points in the process, and someone whose job it is to see the whole picture — that's what makes parallel teams work.