Stackfusion
2024
Frictionless parking payment experience
Designing a real-time parking payment display for gate environments, balancing fast QR scanning, vehicle information, payment states and a 50% advertising requirement.
Overview
Designing for a user who can't stop and read
At Stackfusion, I designed a parking payment LED TV display for client parking sites, with the goal of making entry and exit transactions faster while reducing manual operator involvement. Unlike a conventional digital interface, the display had to work in a physical environment where users were inside vehicles, had limited time to act, and could be viewing the screen from different distances and angles.
The system needed to support different parking scenarios involving Fastag detection, RFID site passes and camera-based vehicle number detection, while providing a clear payment path when a transaction required visitor action. The experience also had to satisfy a strict business requirement: 50% of the screen needed to remain available for advertising. The challenge was therefore to make the payment action immediately understandable without sacrificing the information users needed to trust and complete the transaction.
Context & constraints
One screen. Multiple scenarios. Seconds to act.
The display had to respond to different real-time parking scenarios while remaining understandable at a glance.
The key constraints were:
Users were viewing the interface from inside vehicles.
Actions needed to happen quickly at the entry or exit gate.
The system needed to accommodate Fastag, RFID site-pass and camera-based vehicle-number detection scenarios.
A QR code needed to be large enough to scan from within the vehicle.
Essential payment and parking information needed to remain visible.
50% of the display had to be reserved for advertising.
The experience had to work reliably on a large LED display rather than a conventional desktop or mobile screen.
The system needed to handle failure states, including Fastag payment failures.
These constraints meant that traditional dashboard-style information density would not work. Every element on the screen had to earn its space.
The user journey
The display formed one part of a larger automated parking flow.
When automatic payment methods such as Fastag or site passes could not complete the transaction, the display needed to make the alternative payment path immediately understandable.
Design decisions
Making the QR payment action impossible to miss
The QR payment screen became the primary interaction point for visitors who needed to complete payment manually. I prioritized the information and interactions around the user's immediate goal: understand what is being charged, scan the code quickly, and complete payment before the transaction expires.
01 — Make the QR code the visual anchor
The QR code was placed prominently at the center of the screen and sized for scanning from inside a vehicle. The surrounding area was reserved for the information most relevant to the immediate payment decision: Vehicle number, Amount to be paid, Parking duration, Entry and exit time, Payment countdown, and Reason for Fastag/ sitepass payment failure, when applicable.
02 — Make time visible
The payment window had a limited validity period, so I designed a visual countdown around the QR code. A loader ring provided a continuously visible indication of the remaining payment window. The timer initially used a green state and transitioned to red when only 10 seconds remained, creating a clear urgency cue without requiring the user to read a separate countdown message.
03 — Show more information without adding more clutter
Because half of the display was reserved for advertising, there was limited space for operational information. Instead of displaying every detail simultaneously, I designed a flipping information bar.
The first state prioritised: Vehicle number + Parking duration
The second state showed: Entry time + Exit time
The information continued cycling until payment was successfully completed. This allowed important details to remain accessible without competing with the primary QR payment action or the advertising area.
Real-world validation
The biggest usability problem appeared after deployment
The initial design worked in controlled conditions, but deployment exposed a problem that wasn't obvious during screen-based design reviews. In low-light conditions, glare from the LED display made the QR code difficult to scan, particularly for mid-range phone cameras. Because the issue involved the interaction between the display hardware, ambient lighting and different phone cameras, I treated it as a real-world usability problem rather than simply changing the interface based on assumption.
Recreating the parking environment
I conducted office-based simulations to reproduce the low-light conditions and tested QR-code variations using 10 phones with different camera megapixels. I tested different foreground and background colour combinations to identify which treatment produced the most reliable scanning conditions. The final design used a blue background treatment instead of white, improving contrast and reducing the glare that interfered with scanning.
Design doesn't end at deployment
The QR-code problem reinforced an important principle from the project: A screen can appear usable in a design file while behaving differently when it interacts with real hardware, lighting conditions and physical environments. The deployment environment became part of the interface. That meant observing the experience in context, reproducing the problem, testing alternatives and iterating based on what actually happened in use.
Impact
Reducing manual intervention at the gate
The redesigned payment experience helped move parking operations toward greater automation. The system:
Reduced operator intervention at parking gates.
Increased automation across the parking journey.
Reduced cash-ticket issuance as QR scanning improved.
Became part of the live parking experience across Stackfusion's client sites
Balancing business and user needs
The project also demonstrated that business requirements do not always have to compete directly with usability. The requirement to reserve 50% of the display for advertising could have made the payment experience feel crowded. Instead, prioritizing the QR code, payment information and countdown while using the remaining space strategically allowed the display to support both the business objective and the user's immediate task.
Reflection
Designing for physical environments changes what “usable” means
This project changed how I think about interfaces that exist outside conventional screens.
01
Hardware is part of the UX
Lighting, screen glare, viewing distance and camera capabilities directly affected whether the digital experience worked.
02
Real-world testing reveals problems prototypes cannot
The QR scanning issue only became apparent after deployment. Recreating the environment and testing with different devices revealed what screen-based evaluation could not.
03
Business constraints can become design constraints
The 50% advertising requirement forced careful prioritization rather than simply adding more information to the interface.
01
Design for the moment, not just the screen
A driver at a parking gate does not interact with a screen like a desktop user. The experience needs to communicate the next action immediately, with minimal cognitive and physical effort.
Where the system could go next
The next stage of the system could move toward centralized control-room management, allowing a single operator to monitor and manage multiple parking gates remotely. For scenarios that still require human assistance—including Fastag or site-pass issues, payment errors, and coupons for free or discounted parking—a companion mobile experience could allow operators to intervene without disrupting the overall automated flow.
