The goal of this project was to lower the barrier to entry for accepting cashless payments and allow not just merchants, but any individual — from lemonade stand to flea market — to accept cashless payments.
Sum is a redesigned payment terminal that makes accepting cashless payments accessible to any merchant. The physical confirm button on the front of the device gives the customer full control if, and when, a transaction is finalized, thus fostering trust between the customer and merchant. Due to its pocket size and complementary charging dock, Sum can be deployed everywhere a sale takes place.
The merchants scans or selects the items via the merchant app
The payment total gets send from the app to the terminal which then instructs the customer to pay
The merchants receives the payment confirmation on their app
The premise of this project was that especially smaller store owners face challenges when it comes to accepting cashless payments.
To learn more about their individual challenges, I engaged with merchants and customers in small ethnographic interviews which allowed me to capture stories about their challenges and relationship with cashless payment terminals.
The interviews revealed that the main challenge for merchants was the complexity of setup and the required infrastructure to operate a payment terminal.
Through the interviews I learned that the reason for the device's complexity were confusing menu buttons and a clumsy setup process. Especially the front of the device, which is customer facing, is cluttered with buttons that were not necesseary during operation of the device.
The reason for the confusing buttons is that merchant and customer features share the same surface. To bring order and detangle the merchant and customer interaction, I started to map and seperate the merchant features from the customer feature.
Based on the mapping and separation, every merchant interaction was externalized to an app while the customer interaction resided on the actual terminal.
In order to explore and validate this seperation of a terminal and a external smartphone app, I've built a prototype which replicated the separation into a customer terminal and merchant app.
With the prototype I realized one big advantage of this setup: it allowed the payment terminal to be pretty 'dumb'. All it had to do was receive data, send it over to the smartphone and display data back. Advanced tasks such as connecting to the internet or validating the payment data could be handled through the smartphone's already existing infrastructure and processing power.
Based on the insights from the functional prototype and the terminal analysis, I started to explore the form of the separate payment terminal. Through multiple iterations using sketches and prototypes with different fidelities, I arrived at a payment system which consists of three parts: a portable customer terminal with a physical PIN pad, a stationary charging dock and a external merchant smartphone app.
Based on the physical models I started to envision the screen and interface design for the terminal. But after going through a few payment scenarios I realized that the screen real estate was pretty tight. The physical PIN pad of the terminal left me with very little surface area to actually display visual elements and I was afraid that I would constrain myself.
After taking a step back and looking at my previous form explorations prototypes, I realized that I didn't really make an informed decision when I included the PIN pad. I added it because it felt right.
In order to own up to my mistake, I went a step back and started to focus on the PIN pad again. To make a informed decision this time, I decided to create a heat map of the PIN pad interaction to answer once for all if the two-thirds of surface area on the device are justified.
The heat mapping revealed that the PIN pad was not relevant for every payment scenario and I made the decision to rethink the whole input interaction.
Since the mapping revealed that the physical PIN pad had no merit, I started exploring different interface modalities using digital mockups, printouts and low-fi models.
After exploring in different directions, I landed on a digital touch interface with a single physical confirm button. My reasoning was that the confirm button plays a key role in almost every payment scenarios. But more importantly, having a physical confirm button next to a touch interface creates an intentional 'friction' in the payment process. By having the customer confirm the transaction through the press of a physical button, the device gives the customer full control if and when the transaction is finalized.
After settling on a interface, in a next step I started to translate everything into a CAD model so I could explore and fine tune materials and start tinkering with the construction.
Through wireframing and iterations of visual mockups I explored and tested how the interface and information architecture could be structured in a way that it makes the payment process on the device transparent and comprehensible. I also explored how modalities such as PIN or signature input could be translated into digital screens and how the digital interface plays along with the single emphasized physical button.
Through the wireframing I landed on a clear visual hierachy of interface elements. The bottom portion of the screen is reserved for customer input, such as PIN input or the Customer's signature, while the top portion displays Payment information consisten through all screens.
Based on the wireframes I began exploring and creating the visual design and design language for the reader.
The monochromatic reduced interface highlights and emphasizes the information that are being displayed on the screen. In the context of making payments I valued clear information structure above everything else.
For the final visual design finalisation, I combined the visual design assets with renderings to convey the interface and usage.
The merchant application which accompanies the app is a key part of the concept, but creating and conceptualizing the app was out of the scope of this project.
To still convey the interplay between reader and application, I build high fidelity mockups to convey how the UX flow between app and reader could look like.