ATM Map
How I designed ATM search in a mobile app from scratch
About the project
Context
ATM Locator finds ATMs worldwide right inside the app. VRL Locator shows where a Visa prepaid cardholder can add funds through a cashier terminal at partner stores.
The product was built in a startup. There was no time or people for separate research, so features were built from scratch. That’s why I tested every decision against one question: does it reduce risk for development?
The product was built in a startup. There was no time or people for separate research, so features were built from scratch. That’s why I tested every decision against one question: does it reduce risk for development?
Problem
The request came from the business and pointed at a specific gap. The app let users neither top up their account nor withdraw cash
Project goals
Before starting, we aligned with the business on what the app had to cover first
Top-up and withdrawal
A cardholder should be able to find a place to add funds or withdraw cash
200+ countries
ATM and VRL search in 200+ countries
Detailed point info
For each point, the user should see the key data needed to make an informed choice
Research
Stakeholder meeting
I ran a working session. We broke down the problem and defined the feature roadmap
Writing the URD (User Requirement Document)
I wrote the document as a separate task. I studied the Google Maps API, the Visa API and the business requirements. From them I pulled together the data, functionality and map elements. Filters and entry points I described separately.
I chose to pull point data straight from the Visa API, with no database of our own. The information updates instantly, and the team doesn’t have to build and maintain a point storage.
I split the functionality into the current and future versions. For now, VRL only handles top-ups and ATMs only dispense cash. Top-ups through ATMs, address search, pin clustering and working hours I postponed
I chose to pull point data straight from the Visa API, with no database of our own. The information updates instantly, and the team doesn’t have to build and maintain a point storage.
I split the functionality into the current and future versions. For now, VRL only handles top-ups and ATMs only dispense cash. Top-ups through ATMs, address search, pin clustering and working hours I postponed
User Requirement Document
Google API
Competitor analysis
I reviewed competitors and noted where their solutions don’t fit our product. I collected the map behavior patterns separately and relied on them during design
Competitor analysis
What about metrics
The startup had no product analytics, and the feature had no target metrics. Readiness was measured against the goals from the brief: top-up, withdrawal, 200+ country coverage and point data
Design phase
JTBD
I identified four situations in which a person opens the app and designed the feature around them
When I’m in an unfamiliar country
I need cash. I want to quickly find the nearest ATM that accepts my card
When I need to add funds to my account
I want to see VRL points near me on the map
When I’ve found the ATM I need
I want to see right away how to get there on foot or by car
When I’m choosing between several ATMs
I want to see the fee percentage and the types of operations
User flow
I defined the entry points into the feature and built the user flow for implementation on top of them
User flow
Main screen
I designed the main screen. Every element either helps find an ATM or makes working with the map easier. All elements are built with Google Maps tools, with no separate frontend development in the client apps
Map
The core of the screen. The user sees their location, nearby ATMs and VRL points
Bottom sheet
A list of found ATMs and VRL points with key information
Toggle
Splits top-up and withdrawal into separate flows
ATM pins
They mark ATM and VRL points on the map and stand out from other objects. Standard Google pins would have saved time. But the map will also show businesses and landmarks, and ATMs have to look different from them. I went with custom pins
Challenges
Questions about map behavior piled up. I looked for answers in quick user interviews and in a review of similar apps
Default zoom level
It determined whether users would see themselves and nearby points right on opening, without extra scrolling
Map behavior on zoom and swipe
I had to choose: load points on the fly or only after the gesture stops
Map behavior on device rotation
The user pin has to stay a clear landmark and keep its direction
Zoom change on double tap
A double tap zooms in, as users expect. I defined how far
Number of points in the bottom sheet
A long list overloads the screen. A short one hides the points people need
Behavior without location permission
The map can’t center on the user, and the screen must not look empty or broken
What was released
Project result
The design went through several iterations. The visual solution was approved and released to production
I wrote the development spec
I prepared a spec for the development team: all flows, screen states and the interaction logic of the elements
Спецификация
What happened next
The startup shut down before we could collect data on the feature’s performance