Dream Payments

Improving the process of bulk removal of card readers by decreasing processing time and reducing likelihood of errors.
Research
Hi - fidelity UI
Accesibility
User Testing

My role

User Research, Wireframing & Visual Design.

Platform

Desktop, Mobile Responsive.

Category

Finance, SAAS

Duration

4 months
Introduction
Dream aimed to simplify payment processing for local merchants. Dream had developed a robust software infrastructure to support Trust Dominion Bank in managing merchant payments. This included a mobile application, a web application, and payment terminal devices that merchants use to scan customer bank cards for purchases.

When I joined as a UX Designer, I had the privilege of contributing to Dream’s mission. I was responsible for streamlining the process of deactivating card readers for TD operatives and redesigning the mobile application user interface to meet accessibility requirements.

Project scope

We discovered that TD clients spent significant time deactivating card readers. Payment terminal devices were often removed in bulk, sometimes up to 150 at once. This process was not only time-consuming but also error-prone, as it required TD operators to delete each reader individually.

On the customer side, there was also a clear need to enhance the design of the mobile application while ensuring it met the accessibility standards outlined by AODA.

PRoblem

Once or twice a month, an operator processes a batch of 50 - 150 payment terminal devices for removal at the TD Warehouse. This operator has to delete the devices individually making the current process is long, arduous and error prone.

This is currently done by using a scan gun to scan the payment terminal’s serial number and disabling the terminal by updating terminal information. At the end of the process, serial numbers are gathered from all of the devices processed and logged into a portal.
First Iteration :- User performs bulk removal.

Goal

Our goal was to improve the current user experience of removing payment terminal devices by ensuring all payment terminal serial numbers entered for deletion are properly removed.

Research insights

The design process began with research to prioritize user needs and find out possible solutions for them. I carried out interviews, created sketches and prototypes while iterating the user flows.

During this process we defined what a successful bulk payment terminal removal would look like. The following are key insights which guided our thought process in creating a solution.
  • The limit of the number of batches to be removed.
  • The best way for our users to receive feedback after the action has been carried out.
  • We explored the possibilities in the event things did not go according to plan.
User flow for the bulk removal process.

Solution

We had designed an interface which enabled the user to perform basic validation and sanitization of input. The input field will accept whatever default copy/paste output you would get from a column of 0 - 150 numbers in excel or a plain-text file.

After the remove button is clicked, the user is still made to confirm action before card reader numbers are finally deleted for precautionary purposes.  After deletion, emails confirming the action is sent to both the author of the action and the TD admin group
First Iteration :- User performs bulk removal.

Handling input validation errors FOR THE CARD removal process

Handling Input Validation Errors.
We addressed edge cases involving input validation errors when
  • the user enters no serial numbers,
  • the user enters more numbers than the maximum number required,
  • the user enters an invalid serial number in the list.
Handling Input Validation
Handling Server Errors.
When a user is not able to carry out the bulk card removal process due to unforeseen server issues. The user gives an input of a list of serial numbers, proceeds to delete the numbers. During this process, an error comes up with the corresponding error code.
First Iteration :- User performs bulk removal.

Feedback

After creating the prototypes for the bulk card removal process and testing it out with our clients, we realized we did not account  for a scenario in which a user would carry out the bulk deletion action by mistake. Considering this, it was important for a user to receive information on the nature of deletion that had taken place after the bulk of card readers had taken place.

After a user successfully carries out a bulk removal, they should be able to retrieve it directly from dream payments via an e-mail containing :
  • The user that made the deletion,
  • The approximate time of the deletion,
  • At least one serial card number included on the deletion,
  • Success status of the card readers after deletion.
Handling Input Validation
Handling Input Validation

COnclusion

We were able to significantly reduce the time used to carry out bulk removal by TD operators with significantly less time. The project was in beta and it highlighted the importance of robust user testing, as it allowed us to anticipate and address potential errors and edge cases.

The overall user experience was improved and the system implemented was not only efficient but also reliable and easy to use. Moving forward, these learnings will be applied to future projects with a strive to create user-centric solutions that meet the needs of our clients.