EduBridge BD: I rewrote a UK brief for parents on Android phones

The result: four screens from the booking flow I designed. The Figma file holds all of them, in a 390px mobile version and a desktop version for screens from 768px up. The story of how I got here follows.

The brief asked for a desktop-first, English-only booking and payment flow built around students as the primary user, using the same Stripe card checkout already live in the UK and Australia. EduBridge runs one shared platform across all markets.

A separate PM thread said something different: parents pay, mobile is the default, and Bangla matters.

The task was "build a booking screen". The real problem was that two of the brief's core assumptions would have made the client's 15% conversion target nearly impossible in this market.

The brief targeted students in English, but parents decide and pay, and most are not comfortable in an English interface the way their kids are. It assumed card checkout, but most parents here pay with bKash, which is a different flow with its own app switch, OTP and error states.

I read the two documents together and found five contradictions: device, checkout, language, who the user is, and video calling. I took a side on each. Parents first, mobile first, Bangla from day one, bKash as the primary path, video calling out of scope. I wrote these down before any screen existed.

Before any screen, I locked the design tokens in a tokens file, so Claude could not invent its own colors, spacing or type scale. Then I directed Claude Code screen by screen, checked each render against what I intended, and called out spacing and type that drifted from the scale.

The screen is the parent-facing Booking Request, a single mobile card capped at 400px. A navy header carries the title in two languages: "Booking Request" with "বুকিং অনুরোধ" beneath it. The body opens with the rate, "৳ 800 / hour", before anything about the tutor. Below it sit the tutor summary and qualifications, and a "Verification pending" badge that I deliberately did not color green, because who issues the badge was still an open question. A full-width "Send booking request" button is pinned at the bottom, with the note: "No payment is charged until the tutor confirms the booking."

The file also holds three more states: an empty state, a loading state that says "Checking this tutor's details…" instead of showing a spinner, and an error state for a mismatched bKash transaction ID that tells the parent their booking is still held while they retry.

• "Payment verified" as the confirmation headline. That is a payment fact. The parent at that moment needs to know the booking succeeded, so I changed it to "Booking confirmed".
• Tutor summary above the rate. The brief required cost to be visible before payment method is chosen, and the rate is the commitment decision on this screen. I moved it above the tutor's identity.

This is a course project, so it did not ship to real users. I ran the checkout through three structured review passes: a confused user, a shipping engineer and a skeptical PM. They found real gaps: no way to cancel or go back once a parent leaves for bKash, no defined verification step behind "Confirm payment", and an error-handling gap between the two payment paths. I ranked the findings and put the bKash hand-off fixes first.

A second mistake: I went straight to high-fidelity screens and drew the wireframes afterwards, from the build. They recorded where the build disagreed with my information architecture instead of shaping it. On the next project I wireframe first.

The mistake above, in pictures. bKash has five error screens. The card path had none until the review. The last screen here is the one I added.

I got the boundary in writing before designing: four numbered questions to the PM about the payment flow. Video calling was excluded from this phase. Nagad was left out of this pass. Revision rounds were defined as one consolidated batch of feedback per screen, and anything beyond three rounds is billed separately.