These notes come from assessment and workshop work. Names are shortened where teams asked for discretion.
“The layer notes on our bill-pay confirmation made the debate concrete. Design owned the celebration animation; engineering owned the receipt fetch. We stopped blaming the API for both.”
“We booked a single-journey deep dive for onboarding only. Farah still flagged that our permission sheet arrived before the first useful tip — that one change cut support tickets more than the timing wins.”
“I wanted a simpler scorecard. What we got was more narrative than I planned for, though the prioritised list was fair. Budget another afternoon for internal digestion.”
“The follow-up compare showed our empty-state skeleton still lagged even after API work. Without that second pass we would have closed the ticket too early.”
Extended story: transit tickets after a visual refresh
A Klang Valley ticket utility refreshed its home and purchase flow in the same release. Store ratings held, but session recordings showed hesitation on the fare selection screen.
Our full assessment timed six primary screens on three devices. The fare grid’s decorative map layer was decoding late and blocking taps even though the price list had already painted. The team deferred the map to a detail screen and kept the grid interactive first.
A compare pass six weeks later showed tap readiness on fare selection improved on the older Android profile under throttled data. Marketing overlays were left in place but scheduled after first ticket selection rather than on cold home entry.
We use essential cookies to run this site and optional analytics cookies to understand visits.
Read the details on our cookies page.
