Myki Mate — a top-up that survives a moving tram

Topping up a myki should be a 20-second task. Instead it sits behind a login, a card-number lookup, and a payment flow that forgets everything you told it last week. Auto top-up — the actual fix — is buried three screens deep and explained in tariff language.

My hypothesis going in: people don't want more features, they want certainty — did it work, and is the money there yet?

A caveat I want to be upfront about: this is a self-initiated concept. Real constraints — a legacy back-end, concession fare rules, offline readers — would complicate everything I drew here. The point was to practise a tight loop: observe, design, test, repeat. And to work out my frustrations constructively.

I did nine five-minute intercept interviews at stops on the 86 and 96 tram lines, and read two years of r/melbourne myki threads (a rich seam of pain). Then an affinity mapping session to stop myself from cherry-picking the quotes that agreed with me.

The finding that changed the design: everyone described the balance check and the top-up as one task. The existing app treats them as separate destinations. I had them in different sections too, until the affinity map made that untenable.

My first wireframe was a dashboard — pass history, zones, offers, the lot. Classic beginner's abundance. Walking through it with two commuters (paper prototype, tram stop, slightly awkward) made clear that everything except balance and top-up was noise. Iteration three is almost empty, and it's the first version nobody got lost in.

Visually I stayed close to the myki green — it's the one piece of brand equity commuters actually trust — but flattened the decoration and pushed type sizes up, because this app gets used in glare, at arm's length, while moving.

Six participants, moderated, tasks completed on a moving 86 tram (yes, really — the environment is the point). Two findings stung:

Final round: 6/6 task success, average completion 22 seconds — I timed the real flow at 1 minute 41 on the same route. Small sample, self-initiated, so I hold those numbers loosely.

What I'd do differently: talk to concession users first. I designed for full-fare commuters and bolted concession logic on at the end, and the fare rules are genuinely hard — my 'simple' flow quietly assumed them away. A real version of this project starts there, not with people like me.

What I'd keep: testing in the actual environment. Two of my three big findings only happened because the tram lurched at the right moment.