Remote doesn't mean detached.

In 2022, I was working from Buenos Aires on the redesign of a parking app for one of New York City's largest parking operators.

I was the lead product designer on the project. My role included research, defining user personas, setting part of the product vision, building wireframes, and eventually translating all of that into a new experience.

The problem seemed relatively straightforward at first.

People needed a place to park.

Some were commuters looking for a reliable garage near their office. Others were driving into Manhattan for dinner, a Broadway show, or an appointment. Some used apps for everything and expected to book and pay with a few taps. Others simply wanted to know where they could leave their car.

Different users, different needs — but ultimately, we were helping all of them answer the same question:

Where can I park my car?

And I was trying to answer that question from 8,500 kilometers away.

Designing New York from Buenos Aires

Remote work wasn't particularly new to me. Buenos Aires and New York also share some characteristics that made the problem feel familiar: dense neighborhoods, heavy traffic, people in a hurry, and the constant negotiation between cars, pedestrians, public transportation, and limited space.

Through research, stakeholder conversations, competitive analysis, and user personas, I could understand the parking business reasonably well without being physically there.

But understanding a system and experiencing it are two different things.

A few months into the project, I traveled to New York to visit family.

One evening, I was going to see a show on Broadway and needed somewhere to leave the car.

Suddenly, I wasn't looking at a user flow in Figma.

I was in it.

Parking isn't just a search problem

Until then, I had mostly thought about the core experience as a search problem.

Where are you going?
When do you need to park?
What's available nearby?
How much does it cost?

Then you choose a garage and book it.

Being in the city made that model feel incomplete.

Parking near Broadway before a show is very different from parking near your office every morning.

If you're heading to a theater, you probably don't know the garages around you. You have a fixed starting time. You're navigating traffic. You're checking the clock. Walking an extra five blocks might matter much more than saving a few dollars.

A commuter has almost the opposite problem. They know the neighborhood. They might use the same garage several times a week. Speed and predictability become more important than discovery.

Go farther downtown or toward the Upper East Side and the context changes again.

The map might look the same.

The user's situation doesn't.

That made me start thinking less about parking locations as points on a map and more about the context surrounding each parking decision.

Convenience doesn't mean the same thing to everyone

There was another assumption that became less obvious once I started visiting garages myself: that removing human interaction automatically creates a better experience.

For some people, that's absolutely true.

They want to reserve a space, arrive, park, and leave with as little friction as possible. The phone should handle everything.

For others, having an attendant there is part of what makes the experience feel reliable. They're leaving an expensive object in the middle of Manhattan. Knowing that there's an actual person available can be reassuring rather than inconvenient.

Then there are needs that don't fit neatly into either group.

Electric vehicle owners need to know whether charging is available. Frequent customers care about speed and consistency. Occasional visitors care more about instructions and confidence that they're going to the right place.

A feature that feels like convenience to one person can feel like uncertainty to another.

Price changes the experience

And then there was the price.

Parking in New York is expensive.

That's obvious when you read it in research. It feels different when you're standing on a Manhattan street deciding where to leave your own car.

Price, distance, time, and confidence become connected.

Would I walk another six blocks to pay less? Is the cheaper garage actually convenient? Will my reservation be recognized when I arrive? Am I sure this is the correct entrance?

Those questions aren't secondary details around the booking experience.

They are the experience.

That realization influenced how I thought about hierarchy throughout the product. Finding parking wasn't enough. We needed to give people enough information to make a decision quickly and feel confident about it.

Getting closer from far away

I don't think this experience taught me that remote design doesn't work.

Four years later, I still work remotely.

If anything, it taught me something more useful: physical distance and product distance aren't necessarily the same thing.

You can sit next to your users and still misunderstand them. And you can work thousands of kilometers away and build a deep understanding of their problems.

Research helps. Data helps. Personas help. Stakeholder conversations help.

But every once in a while, you need to stop looking at the journey on a screen and find a way to experience the context around it.

For me, that happened while trying to park a car before a Broadway show.

I had been designing that journey for months.

It took being inside it to see what the boxes and arrows couldn't show me.

Remote doesn't have to mean detached.

-

If you find this article interesting, please don't hesitate in visiting this project on my portfolio.