Ticket validation in the app
The app serves two different people. Buyers use it to access the tickets they have purchased. Staff use it to validate those tickets at the door — and the validation section only appears for users assigned as validators for a specific event.
Validation has to keep working when the venue's connection doesn't, so the device downloads the event's ticket data in advance and uploads the records once it's back online. I redesigned both halves of that: the scanner itself, and the screen where operators manage their offline data.
Where this came from
No one filed a complaint about these screens. I opened them, found them confusing, and noticed they had drifted away from the platform's UI patterns — different colours, different components, different logic from the rest of the product. Design judgement was the trigger here, and consistency across the platform was part of the goal.
The scanner
The problem
The camera lived in a small viewport inside a scrolling modal, with no framing guidance for where to point it. Manual ID entry sat directly beneath it with equal visual weight, competing with the primary action rather than backing it up. The screen showed the date, and nothing else: not whether the device was online, not how many tickets had been validated, not which session was being checked.
The buttons used colours that appeared nowhere else in the product.
What I changed
The scanner became full-screen, with corner brackets marking where to aim. Operators work fast, one-handed, often in low light and often with a queue in front of them — the interaction had to survive that.
The header now carries what the operator actually needs to trust the tool: which session is being validated, its hours, whether the device is online, and how many tickets have been validated today. A torch control sits within thumb reach.
Manual ID entry stayed, but as a secondary action. It is a fallback for a damaged or unreadable code, not a parallel way to work.
The offline data screen
The problem
This is where an operator confirms the device has what it needs before the gates open. The screen didn't answer that question. It showed records split across numbered pages, a search field, and three category tabs, in a palette that mixed bright yellow, green, red and orange in a single view. Nothing said whether the local database was actually ready, or what would happen to scans made without a connection.
What I changed
The state of the local database moved to the top, as the first thing on screen: whether it is synced, when it last synced, and two explicit actions — sync, or download data. Below it, one line explains the model in plain terms: validation works offline, and records upload when a connection returns. That sentence removes the operator's main anxiety before they have to feel it.
Records became a single list with a load-more control instead of numbered pages, searchable by code, split across downloaded, scanned and synced. The screen also states that each read records date, time and operator for auditing — relevant to producers who need to account for who let whom in.
The palette came back in line with the rest of the platform.
Where it stands
Both screens are live and in daily use at clients running recurring dates, amusement parks among them. The clearest signal is a complaint that stopped: nobody reports trouble scanning any more, which was a recurring one before.
What I'd check next
I want to give the operator a way to look back at the last tickets they scanned, without leaving the scanner.