Customer Mobile
The Brief
Customer Mobile is Bytemark’s customer-facing mobile app that is used by riders to purchase and use passes within their local transit system. Recently, we established a partnership with Incomm, a leading payments technology company, to enable cash payments as an option for riders.
The Problem
Customers prefer paying in cash for mass transit rides because they feel that cash is the most secure payment method, but having a cash system drives up the operating costs for transit agencies.
“Cash, which mass transit riders vastly prefer over other payment types, typically costs mass transit agencies twice as much in overhead as non-cash payments.”
—Mike Braatz, Chief Product Officer of ACI Worldwide
The Solution
A mobile app that has cash as a payment option for riders when they purchase their passes, allowing them to complete transactions at local retail stores. Our partnership with Incomm made this solution possible, providing benefits for both riders and transit agencies.
With so many transit agencies interested in this solution, we took this opportunity to quickly come up with designs to present this new feature as part of our offerings to different transit agencies.
Brainstorming
Before diving into the wireframes, I sat down with the team and reviewed the criteria list to better understand the requirements and limitations. We also looked at a similar company that offers a cash payment option to view their user journey from checking out to completing the transaction at a local retail store.
Criteria
User can choose cash to purchase passes
User can search for retail stores by entering the zip code or by using their current location
User can filter the store list by distance up to 25 miles
Wire Frames
Creating the wireframes seemed to be pretty straightforward, but during this process, there were different ideas for the retail search screen, which we addressed by revisiting the technical specifications document. I ended up coming up with three iterations with changes in small details affecting how the user could search and filter the retail store list.
wireframe 1
The first iteration of wireframes was based on the initial criteria list and the user flow we came up with. In this flow, the user is able to search for a retail store by entering the ZIP code or by using the current location, and apply the distance filter to both types of searches.
wireframe 2
After looking through the first iteration, the developers came back to me with some concerns, pointing out that:
The backend did not support the distance filter when the user searched with a ZIP code
The current location button placed on the search field would be a significant amount of development work
The user needs to be able to enlarge the barcode when scanning it at the retail store
I created the second iteration to address these points by removing the distance filter when searching with a ZIP code and enabling searching by distance radius when the user taps the button next to the search field.
wireframe 3
The developers wanted to continue with the second iteration, but my product manager and I agreed that the user should be able to apply the distance filter with any searches. So, we revisited the technical specifications document and found that the backend did support the distance filter with a ZIP code search as long as there was ‘USA’ after the ZIP code. We really pushed for this direction because it would be a better user experience for a wider range of cases (i.e., when a user is in a concentrated area like New York City, it would be helpful to be able to narrow down the distance filter to 0.5 mi). We were able to justify our decision and decided to allow the user to search with ZIP code with the distance filter by appending the ‘USA’ in the backend every time the user entered a ZIP code.
Final Design
Once we finalized the search feature, I went ahead and created the final designs using existing components and styles to minimize development time. I also created a simple click-through prototype to help communicate the flow to our clients.
I added additional screens to show how the user could get back to the search retailer screen in case the user loses connection or navigates out of the screen. When the user goes back to the store screen, there would be a banner reminding the user that there is an incomplete transaction, which then would take the user back to the search retailer screen. Another way to return is through the order history screen, which lives in Settings.
Final Thoughts
This was a high-priority project based on our clients’ needs and wants, so we had to work quickly to deliver this feature on the Customer Mobile app. Overall, this project was a great learning experience for the team because we realized the importance of communicating all concerns and technical specifications early in the process.