Redesigning a payments platform for accessibility and modernization
We took a legacy payments platform used by over 400 companies across the USA and revamped it using a React-based design system tested for accessibility to help users take payments easier.
My role
Lead UI/UX Designer, UX Research Assistant
Timeline
4 months
Disclaimer
Some project details were omitted to protect client confidentiality.
The purpose
This financial institution's product is a legacy software that has an outdated UI, which has not kept up with both user needs and market trends.
Our team decided to find what is causing pain points among users to create a plan and implement a modern design system that makes navigation better.
The main problems we found were: web accessibility violations, confusing interactions, and a high amount of users calling the customer service line because they could not figure out how to process payments.
This redesign is meant to address these issues and provide users a way to take payments without having to deal with interruptions caused by a bad user experience.
Constraints
We had little information in terms of KPIs and user behavior, so we had to do lots of digging to find the data we needed to sell our proposed redesign to stakeholders. Working with little data meant having to liaise with researchers and subject matter experts to come up with solutions.
Results
Our work helped the company remediate all of the usability and accessibility problems for this software. The interface is currently being modernized and will launch by 2025.
Tools used for the redesign
Heuristic Evaluation
Studying the software
User interviews
Wireframing
Prototyping
Usability testing
Our process
1) Discover the problems
2) Define the problems
3) Develop solutions
4) Test the solutions
Discover
We began the process by analyzing user feedback gathered by short interviews and some additional feedback we received from our customers in the past.
User interviews
For this, we used a survey to ask five existing clients of our merchant services platform questions about their experiences and feelings. The survey questions were:
How would you describe your experience with the software?
Would you recommend this software to someone else?
What would you change about the software?
To sum up the results of this qualitative survey, we observed the following patterns:
Users felt that the software is outdated. One of them described its UI as "clunky."
They felt like taking payments using the web pay version could be easier.
They would not recommend this software. We were given various reasons, but the common ones were having to constantly call customer service to solve a problem due to the confusing navigation, and the visual design being too outdated.
"There are better options out there in the market that I can use to process payments and manage transactions. I wish this software wasn't so outdated."
Studying the software
I was in charge of studying the product and discovering usability problems to remediate. It's clear that our clients have issues with the product, but I wanted to take a look at what is going on to see what is holding us back.
Usability problems I found
Misrepresentation of fields: There are several instances where a field that allows users to write text on it appears to be not editable at all. They look like regular text. However, when you click on it, you find out that it does allow you to write text.
Confusing interactions: Overall, the software is confusing to navigate. Once you create a promotion here, it's applied to all products automatically, and it lasts forever until the user manually deletes the promotion.
Complex interface: This is not a product any user can navigate seamlessly. The learning curve is excessively time-consuming because of the high amount of cognitive load this software produces.
Processing payments: There's too many steps to process a payment using the Web Pay versionOther payment platforms do not require so much clicking and guessing.
Web accessibility problems I found
Because it's an outdated UI, I noticed most of the elements are not WCAG compliant. My findings include:
Buttons: Buttons do not have states (active, hover, focused, pressed, and disabled). The buttons always have the same color no matter what, and it's hard to determine the state of the button. There's also no distinction between primary and secondary buttons.
Only using color to convey information: In lots of pages, color is the only way used to tell the user they left a required field in blank. This is confusing for color blind and visually impaired users, as they won't be able to tell why the error happened nor guess a way to fix it. The fix is adding an error message below the required fields explaining what went wrong.
The text on buttons are barely visible due to their contrast.
Words like "processor" and "WildCard" are too technical for users. It's best to use simpler words in both cases to ensure users can understand the language.
There isn't text explaining the errors in several instances. Users have to practically guess. If there is a visual cue, there has to be text to accommodate users with sight impairments and blindness. The ideal solution is to combine both text and visual cues in this case.
Define
Given our analysis, the problem with this software is that users believe it has not kept up with the latest trends, and they are aware of other payment platforms that offer a more seamless experience.
They feel like they are not getting a UI that is easy to navigate and they can just pick another platform that offers it.
That being said, we need to modernize the UI as well as make it easier to navigate, especially the flows in which a payment is to be submitted, which is the main task our users perform using the software.
Problem statement
Our payments software hasn't kept up with modern technology, which is affecting our users' perception of the product and running into confusing interactions when performing basic tasks like taking payments.
User personas
Car dealership owner user persona
Car dealership manager user persona
Heuristic analysis
Before starting to prototype, I conducted a heuristic evaluation. This helped us uncover more usability concerns such as interaction design patterns that don't make sense and only make the software more complex to use.
Heuristic
Violation
Recommendation
Severity
Visibility of system status
Whenever you perform actions such as adding a customer, it doesn’t tell you if the task was completed. In lots of cases, users are left wondering if they did they completed the task correctly.
Have a modal show up after the tasks are completed. An example is displaying a message that says “Customer added successfully” rather than having nothing after task completion.
4
Match between system and the real world
Terms such as “value” and “processor” are too technical for the average user. The UX copy is hard to understand and provides little context.
Use simple, clear language. We have to be straightforward and not let users wonder what certain terms mean. Leave no room for doubt and avoid jargon as well as technical terms.
4
User control and freedom
Users can’t duplicate alerts. They have to create a new one each time.
Add a feature that allows users to undo deletes and prevent deletion by accident. There should also be an option to duplicate alerts.
4
Consistency and standards
Simple actions such as adding a promotion takes more steps than it should.
Make it more intuitive. It’s too inconsistent. You have to go to another section just to view customers when you can do that and also edit and delete them in a single page.
4
Error prevention
If a user selects the “delete” button accidentally, it performs the action without any warning. Also, it doesn’t let them undo it.
Include limits as to what custom fields they can add so sensitive information remains safe. Have a modal that shows up upon clicking “delete” which tells the user it cannot be recovered and if they wish to continue.
3
Recognition rather than recall
Users have to remember alerts. Once created, you can’t duplicate them to make a new one. It relies heavily on users remembering the configurations of the alert they want to copy and paste.
Have instances in which users can go back to a previous state and copy/paste alerts, promotions, or anything applicable. It’s better for them to not rely in remembering what they configured.
2
Flexibility and efficiency of use
Discounts can only be set for every invoices and not customized according to specific instances.
Give users more freedom in terms of navigation and eliminate the extra steps that are not needed. The product should adapt to their needs and not have users question how to perform a simple action or customization.
4
Aesthetic and minimalist design
The menu on the side bar looks cluttered, as well as the information on the software overall. It seems all spread out. I have concerns about how findable is the information.
To avoid crowding pages, we recommended card sorting to organize the information on the UI since everything appears arranged in a way that can be confusing for users. The excess of fields problem can be fixed by applying Miller's Law to format the page better, dividing field groups into chunks.
4
Help users recognize, diagnose, and recover from errors
Error messages are lacking. For example, fields that have an error or are left in blank if are required don't indicate users what is wrong. It only relies on color and visual cues rather than adding text to give more context. The visual cues alone don't exactly tell users the problem nor how to solve it.
Provide clear, text-based error messages with instructions. Don't rely only on visual cues.
4
Help and documentation
Some pages and fields have no context to them nor any indication of what you can do in them. Users may see these pages and wonder what they are for.
Include tooltips for unfamiliar terms and instructional text for pages that provide context regarding what certain functions do.
4
Develop
I assisted with the implementation of a new design system that addresses accessibility concerns. The old design had components that are not WCAG compliant.
On the new designs I made, inputs have a hover, disabled, resting, field, and error state. Also, I added error messages to avoid using color only to convey information. There will be a text-based error message and red color at the same time.
All in all, I used design system best practices to design the screens that focus on the most important task: taking a payment. I redesigned the Web Pay, virtual terminal, and cashiering screens.
Web Pay screen
Whenever the business sends a customer a secure link to input their card information, this is what they will see.
Before (old design)
After (new design)
Virtual terminal screen
This is for when the business wants to take a payment when the card is not present or wants to process a mail order/telephone transaction (MOTO). Typically, the merchant will take their card details and processes the payment on this page.
Before (old design)
After (new design)
Cashiering screen
If the customer is in the store, or the payment is done in person, this is the cashiering screen the user will see to take the payment. This one has two steps: first, you input the amount, and then, you select the payment method.
The old design has a complicated process. You have to input the amount first, and then input it again on the next screen where there is a table with all of the payment types.
The amount column, which defaults to zero dollars, is actually an input where you would type the dollar amount to bill, but it doesn't look like a field.
It looks like normal text, which is confusing. After writing the amount on that column and click on the plus (+) icon, you can tender the amount.
I went ahead and changed it. Now, you simply have to input the amount, select the payment type from the radio button list, followed by the next screen in which you enter the invoice number, customer code, and email. These three inputs are not required.
Before (old design)
After (new design)
Test
To validate our design decisions and see if the new designs are effective so far, we used a remote unmoderated usability test for the Web Pay and virtual terminal screens. For the cashiering screen, we used a remote moderated usability test.
Users were asked to think aloud as they navigated the interface. They were asked a series of questions after finishing the test.
I assisted the UX Researcher and took notes to create a report that is shared with the stakeholders. I also provided recommendations, conclusions, and the key takeaways based on the data.
Virtual terminal screen usability test
All of the participants felt like completing a transaction was simple and none of them encountered any problems.
The average time on task is 1 minute and 23 seconds. Overall, this proves the process is quick.
We need to reassure users that their payment is secure, as there was skepticism and lack of trust among several participants.
Add a checkmark that indicates that the payment information is correct. It's a common design pattern that people are used to seeing. Two participants were surprised this feature wasn't there.
Participants assumed they needed a customer code to process a payment, which isn't the case.
Participants felt like there was information missing such as secure payment disclaimers and a way to add taxes.
I included some quotes from the participants:
"It seems like a great product and a great system."
"If only it had some sort of symbol like one that says it's backed by FDIC."
Web Pay screen usability test
All of the participants found the transaction process simple.
The average time on task is 57 seconds. Overall, this proves the process is quick for a user that is being exposed to this software for the first time.
Some users felt skeptical because there was nothing indicating their payment is encrypted.
Trustworthiness was the main concern rather than actual problems navigating the interface.
Here are some comments from the usability test that I found important:
"Probably the easiest transaction I have done."
"You should add some verification to show a little bit of trust."
"There isn't anything here that says the payment is encrypted."
Cashiering screen usability test
70% learned how to use the cashiering feature quickly and took them a few minutes to get used to it. The other 30% felt like they needed more time to get used to the interface and found it overwhelming.
Participants are used to seeing card numbers formatted automatically in other payment platforms, and were surprised the software didn't have this feature.
They were distracted from the main task due to not knowing if they needed to fill out the customer code and invoice number fields to proceed with the payment. Both of these steps are actually optional.
One common occurrence is that some participants didn't know the next step. For example, when they looked up the invoice number and the fields updated accordingly, they were unsure about what they had to do next.
We need a way to let users know that looking up an invoice and the customer code is optional. It's not clear enough.
Here are some comments from the usability test that I found important:
"It's pretty intuitive after a minute or two."
"It should have spaces automatically when you type in the card number because it's a standard design pattern."
"I'm looking and I'm thinking if I have to enter the invoice number, customer code, and email."
Usability test takeaways
Despite the cashiering screen receiving positive feedback, there were still several users unsure if whether or not they have to input the invoice number, customer code, and email.
We are going to add text to these fields that indicate it is optional. We are also going to add automatic spacing to the card number inputs because it's a feature requested by many users in the interviews.
In conclusion, the designs are useful and users could perform transactions.
I did notice a lot of skepticism because they didn't see anything that reassures them that the payment is secure.
They are used to seeing items like the FDIC logo or any indicator of the software being backed by an entity they perceive as trustworthy.
Iterating on designs after the usability test
I added the secure payment logo to all screens so that users can feel that their payment is secure and supported by a legitimate financial organization.
We implemented a mechanism to automatically add spacing to credit card numbers, as per user expectations.
For the cashiering screen, not only I added the secure payment logo just like participants recommended during the usability test, but I also marked the fields optional. Now, users don't have to assume they need to enter a customer code and an invoice number to take a payment.
Project takeaways
Through this project, I learned how important it is to cater to users' expectations and empathize with their mental models. There is a difference between what the designer expects compared to what the user really wants to see.
We were surprised when we realized small details like automatic spacing on card numbers make a huge impact because it's a pattern users have experienced frequently that they expect to have it everywhere.
This is a lesson that I have always carried with me since then, and has shaped up my current work style. It's always important to advocate for the user's expectations and feelings rather than pay attention to what we think about our users as designers.
