Designing for a Driver With One Free Hand

Most of the products I design are tested in comfortable conditions. A quiet room, a good laptop, a participant who has scheduled thirty minutes to focus. That's fine for a dashboard. It's almost useless for a parking app.

When I started working on a parking and mobility product, the first thing I did was stop designing at my desk. I went to parking lots. I watched people pay at meters, fumble with phones, juggle shopping bags, and squint at screens in direct sunlight. The real context of use was nothing like the clean mockups I'd been looking at.

That context became the foundation for every design decision. This post is about what it taught me.

The real user#

The person using a parking app is rarely sitting down and rarely relaxed. More often they:

Have just parked and want to get somewhere quickly.
Are holding something — a child's hand, groceries, a coffee, a phone charger cable.
Are outdoors, in glare, rain, or the dark of an underground garage.
Have patchy connectivity, especially in multi-level car parks.
Are slightly anxious about getting a ticket.
Are using the app for perhaps thirty seconds before putting the phone away.

None of that shows up in a typical persona document. All of it should shape the design.

One hand, one thumb#

The single most important constraint was one-handed use. If someone is holding a bag or a child, they're operating the phone with one thumb — usually on a large phone where the top of the screen is a stretch.

This shifted the layout dramatically:

Primary actions live at the bottom. "Start parking," "Extend," and "End session" sat within easy thumb reach, never in the top corners.
Big tap targets. We went well beyond minimum target sizes for the key actions. A mis-tap that starts a session in the wrong zone is costly.
Fewer steps, fewer screens. Every additional screen is another precise tap in an awkward position. We collapsed the start flow so that returning users could start a session in two taps from opening the app.
No precision gestures. Small sliders, tiny steppers, and long-press interactions were avoided in the main flow. Duration selection used large, preset chips with an option for custom time.

Glare and darkness#

Outdoor and underground use creates extreme lighting conditions. A subtle gray-on-white design that looks elegant in Figma can be literally invisible in midday sun.

We tested key screens outside, on real phones, at different brightness settings. That led to higher contrast across the board, heavier type weights for critical information, and avoiding meaning conveyed only through light tints. We also made sure dark mode was genuinely usable rather than an afterthought, since it's often what people use in dim garages at night.

The clock is the product#

In a parking app, the most important piece of information is time. How long is left? When does it expire? How much will it cost to extend?

We put the active session's countdown front and center — large, legible, and readable at a glance. A user should be able to pull their phone out, see the remaining time from arm's length, and put it away again without unlocking further or tapping anything.

We also designed for the moments around expiry:

Reminders before expiry, with the extension action available directly from the notification.
A clear expired state that told users exactly what had happened and what they could still do.
Honest cost previews for extensions, so nobody was surprised by the final charge.

That notification-based extension turned out to be one of the most valued features. Many users never opened the app mid-session at all; they extended directly from the lock screen while sitting in a meeting or a restaurant.

Location is helpful, until it isn't#

Automatic location detection seems like the obvious answer to "which zone am I in?" And most of the time it is. But GPS is unreliable in exactly the places parking happens: dense city streets, between tall buildings, underground.

So we treated location as a suggestion, not a fact. The app proposed the most likely zone, made it obvious which zone was selected, and made changing it effortless. We also supported entering the zone code printed on street signs, because that's what people fall back on when they don't trust their phone.

The key insight was that a confident wrong answer is worse than an uncertain right one. Silently starting a session in the wrong zone could lead to a fine, which is the exact outcome users were trying to avoid.

Offline and patchy connections#

Underground parking and connectivity don't mix. We designed for the case where a user parks, walks to the elevator, and only then tries to start a session — with one bar of signal or none.

That meant clear indication of connection status, retrying in the background where safe, and never leaving the user uncertain about whether a session had actually started. A confirmation that the session was active needed to be unambiguous, ideally with a reference they could show if challenged.

Anxiety as a design input#

Parking is a surprisingly emotional experience. People are worried about fines, about running late, about whether they've done it correctly. That anxiety colors every interaction.

Some of our most impactful changes were about reassurance rather than features:

A clear active-session screen that functioned like a digital receipt.
Confirmation messages that restated the key facts: zone, end time, vehicle.
Gentle, specific reminders instead of alarming ones.
Easy access to a history of past sessions, which helped when disputing fines.

None of these are complex to build. They make an enormous difference to how the product feels.

Testing in context#

The biggest process lesson was the value of testing in the real environment. Lab sessions caught some issues, but field testing caught the important ones: buttons too small to hit with a cold thumb, text washed out by the sun, flows that broke when the connection dropped mid-step.

We ran short guerrilla sessions in actual parking areas, asking people to complete a task with our prototype while we watched. We kept them brief — a few minutes — because that's how long the real interaction lasts. The findings from a single afternoon of this were more valuable than a week of desk research.

What generalizes#

This project was specific, but the lessons apply far beyond parking:

Design for the worst realistic context, not the best. If it works one-handed in the rain, it'll work at a desk.
Find the one piece of information that matters most and make it readable at a glance.
Treat automation as a suggestion when being wrong is costly.
Design for interrupted use. People will put the phone away mid-flow, lose signal, and come back later.
Reassurance is a feature. In anxious moments, clarity is the most valuable thing you can offer.
Leave the building. The context of use is data, and you can't gather it from a desk.

The best mobility experiences are almost invisible. You park, you tap twice, you put the phone back in your pocket and forget about it. Getting to that kind of invisibility takes a lot of very visible attention to the moments people actually live through.