Project Background
I helped define and design a digital payment processing system for businesses to accept in-person payments in collaboration with business analysts and cross functional stakeholders in product management and engineering.
This was a part of a pitch (a proposal) for how Paymentus could enter the service industry to serve the needs of both B2C and B2B businesses alike, enabling them process in-person payments electronically.
What I did
I helped define a list of requirements for an over-the-counter payment system and worked through user flows for common scenarios and processes for accepting in-person payments. Our high-level user story (epic) defined as such:
- As a user I would like to be able to accept in-person payments electronically.
The following task flow represents the payment process at a high level. In a typical scenario, a customer would approach a cashier (our user) who would process the payment by selecting options from a list based on the customer’s preferences.
Letting the system do the work
The Product Manager had initially defined requirements for splitting payments; He discovered that customers often want to split their payment across different payment methods. He proposed having an explicit “split-pay” function in the UI that would facilitate this process.
I instead proposed to have the system take those scenarios into account and respond accordingly; If a partial payment was made, the system would accept it (so long as there remained a balance) and assume that payments were going to be split across multiple payment methods.
Key and Supporting features
The following screens represent the interface on which interactions occur for the primary use case I was designing for — In-person over the counter transactions — As part of the experience, the product was meant to be accompanied by an inventory system (yet to be defined.)
I designed backwards starting from the screens that ultimately answered the tasks to the ones that initiated them; from the receipt, review screens, payment method selection to the entry point.
Separating configurations by use case
While going through certain requirements with my product manager, I realized that a majority of them were conflating needs (features) for mutually exclusive use cases. There were requirements that were typical for businesses that transact with customers remotely which were more appropriate for an invoicing system defined for a business that didn’t….
After many rounds of back and forth, we decided to define and design for each use case (along with their key features) separately. In order to reduce the complexity of product (which was initially trying to cover requirements for different types of businesses) We separated features that were appropriate for an over-the counter payment system from and invoicing system.
The slider below shows the interface I designed for issuing invoices:
The process and its outcome
I worked collaboratively with the product manager; Our process involved individual ideation and exploration, interspersed with regular check-ins where we shared ideas.
Because this project was triggered as an opportunity for Paymentus to enter the in-person payment processing market, The scope of my involvement included the definition and refinement of requirements, the interface’s design and the orchestration of user interactions.
Due to a shift in priorities the primary requirements of this project were met when we created and documented the deliverables. I was the sole designer on this project.