Vendor Payment Portal User Experience Design
Client: Wheels, Inc.
Wheels Inc., a trusted industry leader offering fleet leasing and management services, needed to develop a new payment portal for their vendors. I was brought on to design the User Experience for the new application.
The Problem
LeasePlan and Wheels/Donlen were merging to form one company. During the database integrations, the need arose to help small repair shops request payment for work done to Wheels managed vehicles. This project was crucial during the merger because maintaining client services was a top priority during the transition.
What is the solution?
The solution is an online portal tailored for vendors (repair shops) to effortlessly request payment for services provided to Wheels clients. This portal offers a seamless platform for vendors to submit payment requests without the need for complex logins. It boasts a clean and intuitive interface accessible through web browsers, eliminating additional software installation.
What were the results?
The portal's user-friendly design and efficiency significantly improved vendor satisfaction. Payments became hassle-free, reducing the need for direct contact with Wheels. The solution's multi-platform approach, including web and iOS, ensured accessibility. Key tools used in this project were UXPin for wireframes and prototypes and Miro for collaborative brainstorming.
While the happy path for users was straight-forward, the portals asks for specific (and accurate) information based on the clients' pre-approved amounts. Significant time was spent working with the IT Architecture team to determine how best to have users prompt the API calls and to determine the limits which would trigger an error state.
After searching via the VIN and PO# fields, the vendor is then asked to input the invoice subtotal and sales tax amounts. This information was required to check if the final service amount stayed within the set variance that the client pre-approved. If the inputed amounts were within the variance level, then the vendor proceeds through the flow.If the repair is outside the variance allowed, the user is asked to resubmit an itemized list of services for approval.
Once the invoice total and sales tax amounts have been confirmed, the vendor is then asked to review their information and is given a choice on how they receive their payment.
How we got there
Background Research
Both Legacy companies had processes in place for their large repair shops to submit invoices for payment. Since we had insider access to those systems, the team did extensive research into how those applications were built; paying special attention to what worked well and what areas needed improvement. Although our users, small repair shop owners, had slightly different needs, these insights still gave us a solid foundation to build off of.
The Team:
I worked as the sole UX Designer on this project. I facilitated weekly design session with the core product team. These collaborative sessions allowed us to design in an iterative way that kept the user’s needs, the business’s needs, and the technical requirements in balance. The other product team members included:
IT Manager
Business Analyst
Lead Developer
Director of Product Management
Problem Statement
The problem centered around merging databases during the Legacy LeasePlan and Wheels merger. A user-friendly portal was needed for vendors, particularly small repair shops, to request payments easily. The "How might we" statements guided us to simplify access, ensure usability, streamline submissions, provide instructions, accommodate legacy vendors, optimize performance, enhance search, and ensure security.
-
This question addressed the need for an intuitive and user-friendly interface.
-
The focus here was on making the portal accessible to users with different technical backgrounds.
-
Efficiency was key, and we aimed to minimize any unnecessary steps in the process.
-
Communication was crucial, and the portal needed to guide users effectively.
Defining MVPs
After collecting the necessary information, our first task was to help Calculai define what the Minimum Viable Product needed to be for the application. Based on the user research that had been collected, we identified five features that needed to be included in the initial product offering.
An excellent onboarding experience
A tool to manage finances regarding children
A messaging tool
A scheduling tool
A place to organize and store key contacts and documents relating to children
Due to our limited time on the project, we drilled down further to uncover what features needed UX expertise. After discussions, we agreed that the onboarding experience and the financial management tool added the most value to users and therefore should be focused on first.
Financial Management Tool Design
Calculai leadership strongly believed that the financial management tool was one feature that would differentiate the application from the competition. By the end of the project, I had designed 4 user flows for the financial management section of the application. These four flows were developed through the use of stakeholder interviews, synthesizing user research, competitor research, and iterative design.
Four User Flows of the Financial Management Tool
First-time use flow
Setting up an account flow
Add a payment account flow
Transfer money to account flow
First-Time Use Flow
Calculai leadership wanted a strong first-time use flow. The overall application requires a lot of information from the user. The fear was that asking for all required information during the onboarding process would overwhelm the user leading to sign-up abandonment. Instead of asking for all of the information during the onboarding process, it was determined that information should only be gathered when it is necessary for the operation of the specific tool.
For the financial management tool, this meant that I needed to design flows that captured the required information from users at the correct time. Based on user research, I knew that users needed to know why information was being asked of them; especially when that information was in reference to their children and their finances.
I determined that before any information was asked of the user, they needed to have a mental model of how the tool would assist them as they manage their household. As a result, I designed a mini-onboarding process for the financial management tool that showcases to the user how the application helps them manage finances related to their families.
Setting Up Account Flow
The core of the application's financial management tool is the ability for users to set up an account to manage finances related to their family. Many of the features for this account were still under development and so specifics in regards to account creation were yet to be determined. Still, we wanted to get a sense of what the flow would look like for account creation to help inform future decision-making.
After consulting user and competitor research, I determined that the setup of an account should have three steps in the initial user flow.
Verify the parents' identity
This step is necessary to comply with laws surrounding financial account creation
More research is needed to determine the correct steps needed to comply with the law
Select the child/children the account is for
Children are added to the parent's account in a different section of the application. If no child has been added, the user will be directed to that section to add a child before creating an account.
Transfer funds into the account
Before funds can be added to the new account, the user will have to set up a payment account. If no payment account has been added, the user will be directed to the add payment account flow before creating an account.
Add Payment Account Flow
To set up an account, make transfers, or pay for expenses relating to their family, the user must set up a payment account.
To simplify the process for users, I set up the flow where the user only needs to login into their financial institution's online banking system to link their payment account. User testing is needed to determine whether or not users prefer this way of linking their payment account or if they would rather manually input their account and routing information.
Transfer Money to Account Flow
The final user flow that needed to be developed for the financial management tool was the transfer money flow. This feature doesn't become active for a user until they have added at least one account and at least one payment account. I completed extensive competitor research for this flow to see how other applications handle money transfers. Users needed the option to transfer money to and from multiple accounts. Additionally, they needed an option to make the transfer once or recurring.
Final Deliverables & Next Steps
Financial Management Tool User Flow
The finished deliverable included an initial user flow for the Financial Management section of the application and a working prototype to be used for user testing. This flow, incorporating the four individual flows described above, maps out the total user experience for the tool.
*click to view prototype in Figma
Kiido Wireframe Prototype
Equipped with a prototype built from the wireframes and user flows I developed, Calculai is now set up to conduct user testing to see how this tool can solve its users' problems. Although this user flow was developed through extensive research, there is no doubt that this will only be one of many iterations of the tool's design.
Before handing off the final deliverable, I suggested that Calculai address the following questions during user testing:
Does the design make users feel secure about conducting financial transactions? How can this be improved?
How do users prefer to verify their identity? Does this comply with local and federal laws regarding financial account creation?
How do users prefer to link payment accounts? Should other account types (Paypal, etc) be considered?
Next Steps
The next step in the development process for the financial management tool is for Calculai to conduct user testing. Through testing, they will gather the information needed to iterate on the design. Beyond user testing on the financial management section of the application, there are several other steps that will need to be taken as Calculai moves forward on the project.
Other application features will need to be developed to determine how the financial management tool will interact within the ecosystem of the entire application.
Once the application branding has been developed, high-fidelity mockups will need to be created taking into account the results of the user testing conducted with the wireframe prototype.
A high-fidelity prototype of the entire application will need to be created and then tested with users.
There are also still unanswered questions within the financial management tool that will need to be answered. Some answers will come from user testing and some will come as the application gets further developed. Below is a list of questions I feel still need to be answered before the design of the financial management tool is completed.
Does the application comply with the laws surrounding financial account creation and management? How will complying with these laws constrain the design and/or user flow?
How will the financial management tool operate within the broader scope of the overall application? How will the different features interconnect?
What safety features need to be added to make financial transactions through the application secure?
What payment account options do users prefer? How do they prefer to connect said accounts?
How can expenses out of an account be shared or assigned to a specific parent?