At a Glance
EBizCharge is a robust B2B payments and collections platform that allows businesses to take payments with a virtual terminal, manage and automate payment collections from their customers, and view their company's sales with payment gateway functionality. The platform also serves as a light ERP for small businesses who can create sales orders, invoices, and manage inventory from the platform. The product is about to enter the development phase.
My Role
This product was conceptualized by myself and the VP of Software Engineering at my current company slowly over the past 2 years as we gained deep understanding on our users' pain points, needs, and wants. I was the sole researcher and designer for the assets and designs shown. Recently, I demoed a prototype of these designs with the head of engineering to company executives for proof of concept, and now that the product has been green-lit, I am managing a team of designers and developers on the execution of the project.
Discovery
The platform features and requirements were informed by:
- Pain points, needs, and wants of our existing user base currently using 2-3 separate legacy products of ours to complete workflows that could be completed within 1 unified, robust application if our products were combined and reimagined
- Brainstorming sessions where we conceptualized new features and ways to streamline / automate existing workflows, that we gathered from countless hours of user research and feedback
- Reviewing feature requests from users over the years
- Market research, competitive analysis, and industry trends for virtual terminal / POS applications, customer relationship management systems, cloud ERPs, and payment collection platforms
Virtual Terminal
We knew we needed to take our legacy desktop POS application to the cloud (and make it a "Virtual Terminal") in order to add new, more advanced technologies and allow our users to reap the myriad of benefits that cloud applications offer over desktop apps. We decided to include the virtual terminal as a module in our all-in-one platform.
Since the virtual terminal is a key part of the overall product, I began by gathering feedback and use cases on the existing POS product. I interviewed:
Since the virtual terminal is a key part of the overall product, I began by gathering feedback and use cases on the existing POS product. I interviewed:
- Existing users to identify usability issues and customer wants, as well as gather typical user types and use cases
- Members of our in-house customer support team to leverage their plentiful knowledge on what the problems are that users encounter every day with the current POS
- Sales department to hear what feedback they most commonly hear when demoing the product, the types of objections they hear on cold calls to prospective customers, and reasons they encounter when existing customers leave
Who are our users?
66%
|
34%
|
Who will be the users of our new all-in-one solution?
Below are some examples of how I translated data on the users of our existing products into personas, journey maps, and case studies. We kept these archetypes at the core of decision-making for feature set, information architecture, and analytics to include throughout the product.
Information Architecture
Due to the financial nature of the platform with users taking payments and issuing credits sometimes in very large amounts, developing a system for admin users to manage user roles and permissions was important. As we designed the architecture, we decided to keep functionality modular where entire sections can be hidden or available depending on user permissions.
Establishing a Design System
Before I joined, there were no development or UI guidelines of any kind and therefore, UI varied greatly across platforms. I created an EBizCharge design system for our designers and developers to use for all new products, including this all-in-one platform. I use Invision's DSM to house the design system.
Virtual Terminal Module
The design for the Virtual Terminal module incorporates extensive feedback from users of the desktop POS, best practices from usability studies, and common design patterns from relevant cloud applications to avoid steep learning curves and deviations from user expectations.
New TransactionUsers can select whether they would like to run a sale, a credit, or select a different type of transaction. We chose tabs to display these options so they can easily be hidden depending on user roles and permissions.
Users can select an existing customer or add a new one, enter transaction details, and select a payment method, either by using a credit card saved on file for the customer, manually entering a customer's new card, processing a physical credit card with a chip-reading device, or paying with a bank account. |
Transaction History
Users can view and filter all their transactions in the Transactions History tab. The columns display the most important pieces of information users need at a glance.
Clicking on a specific transaction expands a side panel that allows users to drill into more details of the transaction and complete further actions, while still allowing them to stay on the page to avoid toggling back and forth between a single transaction detail view and the transaction list. I used card sorting activities with users to reveal mental models that helped determine how the transaction data is grouped on the detail panel. |
Customer Management
Customers can be synced from a business's ERP / accounting software or CRM system or created from within the EBizCharge platform.
Customer Profile
I gathered feedback from users on the types of information they want and need to know about their customers and which customer insights would be valuable at a glance when determining which customers to most closely follow for payment collections. Analytics and data visualizations using Power BI are placed at the top of each customer's profile to provide at-a-glance stats about the health of the customer's payer standing.
Expandable panels with tabs are used to allow for hiding and collapsing sections, as well as make it easy to hide certain sections depending on user roles and permissions.
Sections display read-only information and can be edited / managed in modals via the blue links. I used iconography next to actions to increase learnability and fundability (e.g. pencil icon to indicate editing, eye icon to indicate viewing ability for invoices). In addition, I used visuals to make content easier to view (e.g. VISA and bank icons in "payment methods". |
Email Pay
Send Email Payment Requests
This section allows users to email their customers with a link to a secure web form where the customer can view and pay off their invoice via a secure web form.
Pending Email Payments
Having a place where uses can view email payment requests that were sent but have not yet been paid, and whether the customers have viewed the payment forms, emerged from seeing how users waste time manually following up with their customers about fulfilling their payments.
I narrowed down the things users want to know the most about their pending requests and designed "Send History" and "# of Times Sent" columns. I used color to indicate invoice status and made the rows expandable to allow users to drill into pending requests deeper if desired. |
Invoices
Invoice lists and sales orders in our existing products lack filtering options and the ability to complete many options. Therefore, we added extensive filtering options, with the most in-demand filters exposed and easily accessible, as well as an actions menu to each row and the ability to process payments on multiple invoices in a batch.
|
Building an easy-to-use and intuitive invoice creator is crucial to our application. I studied dozens of invoice builders out there and thought carefully about the micro interactions within this flow.
I chose a layout that resembles our default invoice template. It mirrors what their actual invoice will look like so they don't need to relearn where certain fields are. |
Other Screens
Settings
Create recurring payment + manage templates
User Testing
My team and I held a series of remote user test sessions with existing customers to gather qualitative and quantitative data on the prototype’s usability, satisfaction, and efficiency.
Before we began tests, we wrote a user test plan which defined:
We compiled results by:
We acted on test results by:
Before we began tests, we wrote a user test plan which defined:
- Testing goals
- Participant recruitment methods
- Procedure
- Tasks for participants to try to complete
- Questions for participants
- Usability performance measures such as completion rate and time on task.
We compiled results by:
- Transcribing verbal feedback
- Creating word clouds and maps showing overlapping feedback and outliers
- Calculating time on task, completion rate, inaccurate click rate, and other performance measures from session recordings
We acted on test results by:
- Brainstorming design solutions for identified usability issues
- Prioritizing which sections to dedicate additional research, design, and testing time to