I was tasked with designing an enterprise payment platform. When I joined the team, the product vision has already been established, and the product has gotten its first client - NHL. I led the effort to work with an internal product team and the NHL to fully design the application.
PayPrise is a white-label product by Vernalis as a part of its Sports ERP suite. Within the Sports League industry, there is a pressing need to have an enterprise payment software that allows them to invoice and charge business customers securely and easily. PayPrise was developed to suit this need.
How might we design a payment platform for large enterprises to generate invoices and charge enterprise customers?
Lead UX Designer
White Labeled Product; Licensing to the NHL
When I joined the team, a product vision has already been formed. To get up to speed, I scheduled meetings with the product team to identify the product vision, user goals, and business processes.
Reviewing documentations available provided me with more details on business rules and user stories. Through interviews with the product team, I was able to identify gaps between user needs and the product backlog. Working with my teammate, I iterated on product features and the prioritization of these features.
Throughout the Discovery process, I also conducted a competitive analysis to see what other applications offer for big enterprises. The analysis revealed of the types of features that might be valuable to customers. I further validated the importance of these features through user research by understanding users’ goals, behaviors, and pain points. See the next section for more details.
To understand the users, I scheduled interviews with our first customer NHL. Interview sessions are scheduled with stakeholders and future users. First, we listed the use cases, which included anything from invoicing other companies for brand asset licensing to charging guests hotel fees for special events. Then, we mapped out the current processes to identify how payments are currently charged, who is involved in the process, and the pain points involved.
Ensuring the safety of credit card information is a critical need for both types of users of the application. My role required me to be both the UX designer and the business analyst of the product, I needed to understand how online credit card payments work and how information can be stored securely.
For that, I conducted research and documented requirements for PCI compliance and Stripe API. This step helped me understand what data is needed for creating charges, and what data the application can and cannot store.
The first step of my design process was to create user flows. The product aims to help organizations and their customers to create and submit payments easily and accurately, and therefore I spent time iterating on user flows to ensure the product helps users achieve their goals.
After mapping out the key user flows, I started working on documenting features in the product backlog. Working with stakeholders and the product team, I further divided features into two branches - MVP and Roadmap to prioritize the important ones.
I then began wireframing. The design was broken into phrases based on workflows - request a payment, receive an invoice, cancel an invoice, leave comments, etc. The process was an iterating process where I frequently presented my designs to the product team and the stakeholders at NHL to obtain feedback.
Working with a senior designer, we came up with some visual concepts for the application. Because the product is white-labeled, we wanted to make the visual design flexible to suit branding needs.
When designing the invoice screen, I wanted the design to mimic the layout of a traditional paper-based invoice. However, I also would like to add functionalities that could address users’ pain points. Therefore, two features are added - 1) display request status, and 2) show request timeline, which could provide greater transparency and allow users to obtain real-time information.
Surfacing the invoice status first allows users to know the status at a glance.
Metadata of the invoice is displayed next. Data points displayed vary for user roles.
Users can refer to any supplemental information in the Notes section while reading the invoice line items.
The format of the invoice form is very similar to what an invoice would look like. This is intentional because the consistency helps users familiarize themselves with the layout. Many fields are auto-populated based on the user’s profile, allowing the user to fill out the form quickly.
Whenever an action is performed on the invoice, it will be added in the timeline, which is displayed in a subway stop style.
One of the major challenges in this project is to design data tables for invoices. Specifically, how can I design the table so that users can 1) easily identify and locate the invoice and 2) understand the status of the invoice at a glance?
I tackled this challenge by asking and designing solutions for questions below.
When logging onto the application, what does the Admin want to know?
Through user research, I found out that the Admin would be most interested to know statuses of unpaid invoices. With this information, I decided to create the invoice table so that unpaid invoices are displayed first upon logging in. Overdue invoices are sorted to be shown on top to raise the Admin's attention.
What data does an admin need to identify an invoice in the invoice table?
Users needs to be able to identify and locate an invoice easily in the invoice table. By conducting user and competitive research, I determined the key information a user needs to identify an invoice, such as the invoice number, the invoice recipient, and the invoice date.
How can we give users the flexibility to organize the data table?
To address this question, I added sorting and filtering functions to the data table. For example, if the user wants to look at canceled invoices that are issued in the last 30 days chronologically, the user can do so by using the date filter, the status filter and the date sorting features.
submit a payment
To submit payment, a customer will go to the invoice and click a Pay button. The application will then directs the customer to this payment submission screen. On the left side of the screen, the invoice summary is displayed so that the user can refer to the invoice without having to switch screen. On the right side, the customer will enter the credit card information. This concise screen allows users to submit a payment easily and confidently.
Actions such as sending an invoice or canceling an invoice would trigger an email notification to the customer. Working with the clients at NHL, I identified all scenarios, designed the email layout, and documented the content.
There are a few actions a user can take in PayProc or that are high-risk and irreversible. For example, if an invoice is canceled, the recipient of the invoice (aka the Payer) will no longer be able to submit the payment. To reduce risks caused by misclicks, I needed to design effective confirmation popups for these key actions.
Through researching best practices and conducting user testings, I designed the confirmation screen so that it shows consequences of the action, displays the action that's performed, and avoided ambiguity in wordings.