Locations, locations, locations
Helping our customers find the most convenient location and method to add cash in store
When I started at Netspend (a financial company that provides prepaid debit and banking services to millions of customers), there wasn’t a system in place for designing digital products. We had a style guide which helped us make sure that we were using the correct font and brand colors, but other than that, there wasn't much. Because of that, it was easy to spot problems with consistency within the user experience. Through internal evaluation and user research it was clear that we needed to invest in a design system to give our products a unified language.
Challenges to solve
Ensure the use of a consistent user interface
Facilitate reusability
Streamline the effort involved in updating and maintaining assets
My role
Refine current patterns and identify any gaps or redundant patterns
Lead the design team in conceptualizing and defining content
Collaborate with developers to answer their questions and document their needs
Present work to team members and other stakeholders
Define the objective
The original ask from the product manager seemed pretty simple—create a way for a user to add cash to their account by using the following steps:
user opens up the Netspend app and searches for a participating retailer nearby
user generates a barcode for that retailer
user goes to the store and asks the cashier to scan the barcode
user hands the cash to the cashier
cash is instantly added to their account
The Netspend app already had a feature for finding reload locations, except the loading of money worked differently than this new approach—the cashier would swipe the user’s physical card instead of scanning a barcode on their phone. My initial thought was to just add-on to that existing feature—the problem was that not all locations would have the barcode feature available. In fact, some locations would only have the barcode load option—meaning that a store could have one of three possibilities:
only able to swipe card to load cash
only able to scan barcode to load cash
able to do both, swipe card and barcode scan to load cash
The ideas quickly came rushing to me where to simply show all types of locations on the map, but differentiate the different type by using different the pins (maybe color, icon, etc.). During the kickoff meeting, I then also learned about one other constraint: The third-party service providing these ways to reload are coming from two different providers and we would not be able to integrate both sets of data at the same time—meaning we either show barcode locations on the map or card locations on the map, but not together. This piece of information had significant ramifications on the approach I was thinking about taking—instead of dropping the user on the map and showing both types of locations, I now had to figure out how to separate the two.
Research
One of the first things I did after learning more about the project was researching the current experience of the reload locations feature. The feature had not been refreshed in quite some time and it was easy to see that there was a lot that we could improve on.
Existing flow and some initial notes.
I also started to realize that while adding on to this existing framework would work, it was not something I would recommend. Instead, I decided to go back to the stakeholders and discuss redesigning a majority of the user interface to better align with newer patterns found on many of map applications today. The extra work was estimated to add six weeks to the original scope, but they were also convinced that it was necessary to produce the best possible outcome for our customers.
Prototype & Test
After sketching out many different ideas and presenting those to the stakeholders, we all agreed to test the flow that immediately prompts the user to decide what type of reload they want to do (have the cashier at the store swipe their physical card or scan a barcode on their phone) before locations are seen on the map.
Using the sketches as my guide, I then designed all the screens necessary, built out a prototype in Figma and connected with the UX researcher to create a test plan. Our main goals were to gauge the understanding and opinions around the barcode reload concept and discover any friction points that users had in the overall flow.
We created a scenario around a real life situation that a user could potentially come across. The script went as follows:
You have some cash that you’d like to load onto your Netspend prepaid debit card account. You don’t have your physical card on you right now, but still need to add cash to it. Generate a barcode that will let you load cash onto your prepaid account at a no-fee location.
Screens from the prototype that shows the happy path of finding a nearby location and generating a barcode.
Once the user completed the task, we asked them to complete a few additional tasks and these follow-up questions:
Find the closest reload location to you—fee and type (card or barcode) does not matter, we're just looking for the closest.
What do you think about the idea of loading cash in a store using a barcode on your mobile device rather than using your physical card?
Is there anything confusing about the idea?
Talk about what you like and dislike about this feature and why.
When looking for locations to load cash onto your card, which do you prefer: the list view of nearby stores or the map view? Why?
Results
Finding and using the feature to generate a barcode is easy for all users—every user was able to complete the task.
No one used the filter; rather, they tapped through options on the map. Could be because there were only a few locations on the map (i.e. more locations might prompt them to use the filter) or they did not notice it.
List vs. Map view preferences: Most users say that they prefer list view, but their actions indicate their preferences are dependent on whether they want to browse (map) vs. find a specific known location (list). When browsing, participants tapped through the map. When they needed to find a known location or there were too many options on the map, people used the ‘List view.’
It is unclear to users what will be sent to them when they tap on ‘Send to phone’ or ‘Send to email,’ and some (4 users) think that they will be sent the reload barcode (one user's comments: "Send what to phone, though? I don't know what it's sending...maybe the barcode."). Users are clearer on what ‘Get directions’ might do, with many thinking it would open Google maps.
Overall takeaway: Almost all users like the idea of loading cash with a barcode. They said it felt more secure than using your card and was very convenient for those times that you don’t have your card on you.
Iterate
After observing user interactions with the prototype, we collected valuable feedback and insights, leading us to polish and enhance the design.
A significant problem I observed was when we requested users to locate the nearest reload spot, irrespective of fee expense and reload method. Making the change from barcode locations to card locations (or vice versa) seemed inefficient, and I disapproved of having users retrace their steps to adjust this before moving forward. Therefore, I explored ideas where the option to make that change to be placed directly within the map/list view. After conducting further testing rounds with multiple alternatives, we agreed on utilizing a toggle, permitting users to rapidly switch between the two and fixing it to the bottom for enhanced accessibility.
Initially, the design forced users to revert a step for toggling among loading choices.
Switched to a toggle method for quicker and simpler visibility of both choices offered.
Other key enhancements included:
A quick introduction of the new feature
Altering the description of the function for clearer user comprehension regarding the ultimate objective
Using a similar toggle to switch between map and list view
Pins that reenforced what type of location it was
A more prominent announcement related to the active barcode and a swift link for its access