Case study · ~12 min

CaCa — a ride-hailing platform in Yangon

19 months as the only designer on the team. Five surfaces, three scripts, a four-month MVP — live in stores. This is the long version.

5 surfaces3 scripts19 monthsLive in stores

01 · Why CaCa exists

You can't copy Uber in Yangon

CaCa means 'taxi' in the local dialect. The project started as MyanGO — renamed after the name clashed with an already-registered company — and set out to build something the city didn't have: a complete ride-hailing ecosystem. The catch — global patterns don't survive here. Payments run cash-first, networks drop, phones are low-end Android, and the interface has to hold three writing systems that share nothing.

02 · My role

The only designer on the team

Every screen across five surfaces went through me — product design, UX structure, UI, branding support, and the website. Engineers built, operations ran the fleet; I owned how all of it looked, flowed, and explained itself. The job wasn't drawing screens. It was turning business needs into flows people could actually follow.

03 · The challenge

Not one app — one operating system

A passenger booking a ride, a driver accepting a job, an operator untangling a dispute — different users, different interfaces, one connected system. Three problems shaped everything: making fragmented needs feel like one product, designing for real conditions instead of ideal flows, and moving at MVP speed without wrecking the structure the future needed.

04 · Ecosystem map

One loop connects everything

Passenger request → driver acceptance → trip tracking → payment → backend management. I mapped the platform as a single loop before designing any screen — it showed where each role enters the system, and where information has to cross between apps and internal tools.

05a · Passenger app

Booking that explains itself

Registration, booking, location selection, tracking, payment, trip status — the flows every ride app has, rebuilt for users who may be on their first smartphone and a bad connection. Every booking state is visible and named, so the app never leaves you guessing whether a car is actually coming.

05b · Driver app

Drivers don't browse — they react

The driver app runs dark, and every screen answers one question: what happens next? Job offer → accept → pickup → trip → payment. Each state had to survive sunlight, motion, and a three-second decision window.

05c · Delivery

Same loop, different cargo

When the platform expanded into delivery — including a bicycle fleet — I refactored flows on flow diagrams before touching screens. Where the ride logic held, we reused it; where a parcel isn't a passenger (handoffs, recipients, proof), the flow forked. Diagram-first kept the refactor honest.

05d · Operator backend

The 18-module control room

Orders, users, settings, monitoring, and the rest of platform operations — 18 admin modules, bilingual EN + 中, designed so the ops team could run the fleet without manual coordination for every exception.

05e · Marketing site

cacataxi.com — designed and built

The public face: service, trust, and identity, responsive across devices. I designed and developed it myself, end to end.

06 · Design system

One language across five surfaces

Tokens, components, a shadow ladder, and type that holds EN · 中文 · မြန်မာ on the same screen — three scripts with no shared rhythm, baseline, or line height. The system is what let one designer keep five surfaces consistent while the roadmap kept moving.

07 · The unhappy paths

Designing for when it goes wrong

Network unstable, no drivers nearby, payment failed, GPS drifting — in Yangon these aren't edge cases, they're Tuesday. Every critical flow got explicit failure states, because the moment something breaks is the moment an app earns or loses trust.

08 · Local context

Designed for Yangon, not for app stores

Cash-first flows, with cashless built on a KBZPay partnership — CaCa was the first ride-hailing platform in Myanmar to integrate the wallet people actually use, rather than card rails. Tri-script interfaces over English-only. States that assume the network will drop. None of these were compromises — they were the brief. The global playbook was the thing to resist.

09 · Outcome

Shipped, and still running

A four-month MVP grew into a full platform: passenger and driver apps live in stores, delivery flows, an 18-module backend, a first-in-market KBZPay partnership, and a public site — a product foundation that still serves Yangon today.

10 · Reflection

Start with the workflow, not the screen

CaCa taught me to design ecosystems, not screens: understand how users, operations, business goals, and technical constraints connect — then turn that complexity into a flow people can actually use. Real workflow first, roles second, system map third. The interface is what comes after.