Friction at the gate

Scanners are everywhere. Supermarkets, airports, train stations. A barcode, a ticket, a fingerprint, a face. The technology has become so normalized that people barely think about it anymore.

Designing a scanner

A couple of years ago I worked on a project to design a scanner for a ticketing platform. I was the sole designer and worked with one engineer and a business owner. It would be an app on a phone and would support scanning via camera and NFC. At first glance this seemed straightforward. Plenty of people and companies have solved ticket scanning before.

Once I started listing out the constraints and dug into customer feedback from our previous scanner, the variables added up quickly.

Apart from the technical challenges, what stood out was the users operating the scanners. They were from different age groups and skill levels, ranging from young adults to retirees with disabilities. Motor skills, familiarity with the device, and finger reach all became things i had to figure out.

My early prototypes were too focused on the technical challenges and optimizing for quick development. User feedback and observations made it clear that this wasn't enough.

Friction

Taking a step back, the real issue wasn't even the scanner, it was the queue the operators were dealing with. People waiting are impatient. Operators feel that pressure. Every second a scan takes is a second the line isn't moving, and a stressed operator under social pressure from a crowd is more likely to make mistakes, skip instructions or improvise on the spot.

So the scanner had to be fast and verbose enough that the operator never has to think about it, and things will surely go wrong: a duplicate scan, an invalid ticket, an ID check, it has to tell the operator exactly what to do next.

Decisions

From a technical standpoint the main challenges were energy conservation, network instability (an event with 5000 people will impact the network), and performance.

The user experience mostly had to do with finger reach, I spent quite some time figuring out how to make the scanner usable with just your thumb, as well as legibility across different environments, a sunny day versus a totally dark nightclub. High contrast and large touch targets were essential from the start, given the wide range of ages and abilities we needed to support.

For haptics, I took inspiration from Apple Pay, using distinct vibrations for success, warning, and error. It's a pattern some people are already familiar with and is easy to intuitively understand once you've used it. Tip, on an iPhone you can prototype this easily by recording custom haptic patterns under Sound & Haptics in Settings.

The technical constraints made a really solid case for also having an idle state. Reducing battery drain was the main reason, but it also offered a "home" view to access the scan modes, guestlist and activity log. I landed a 2×2 grid of oversized buttons, loosely inspired by the MPC drumpad. Large labels, large targets, everything within thumb reach.

The space above the grid wasn't wasted either. It would display a countdown until gates opened or warnings / permission errors. The ample space meant errors could stay on screen without interrupting other operations.

I tested numerous variations of the scan result itself. Many scanners I looked at turned the entire screen red or green to communicate the scan result. In practice this felt harsh, especially in dark environments. Imagine getting a red full-screen image in the middle of a dark nightclub. Besides, color as the main visual cue isn't always the best way to convey it.

I opted for a simple border around the screen instead, spelling out the result of the scan and if there's an action the operator should take.

What rounded out the application was a list management system and an auditable log of scanner activity, available on the device and synced to a web dashboard. Even relatively small event organizers want visibility into what happened at the gates, even more so once multiple scanners and operators are involved.

One thing we did skip was on-device reports. Partly because of development cost, but mostly because exposing statistical data directly on scanning devices introduced additional concerns. There was also an unexpected dynamic I noticed while brainstorming what metrics to include, surfacing scans per minute would create a competitive behavior between operators that would be unintended.

The app has been running at events for about 2+ years now. Operators don't have to think about it, which was kind of the point from the start. Haven't tested it with my own grandma yet but our business owner said he had success with both his kids and parents.