The need
Merchants can have a hard time accepting cashless payments. Existing payment terminals are clunky and often require an existing infrastructure of hardware and software. Especially for small merchants this barrier is difficult to overcome, resulting in low acceptance of cashless payments in small stores. The goal of the project was to envision a concept that gives every merchant - from lemonade stand to mom-and-pop-store - the possibility to accept cashless payments.
Outcome
Sum is a payment terminal that outsources all the complexities of a payment process to a smartphone or tablet. This makes the terminal lean and allows it to focus on its essential task: accepting payment cards and entering data by the customer. The physical confirm button creates artificial friction and ensures that the customer decides whether and when a payment is finalized. Via a complimentary dock, the terminal can be operated in mobile or stationary stores — or anywhere goods changes hands.
The process of designing Sum
The premise of this project was that especially smaller merchants struggle to offer cashless payment options. To validate this assumption, I went out and engaged with merchants and store owners in on-site interviews. Through the interviews I learned that one of the main challenges of payment terminals was the complexity of use and the required technical infrastructure to operate one.
Through the interviews I also learned that a payment system was just a smaller component of a larger point of sale system. For the scope of the project I decided to focus on the payment terminal itself which manifests the intersection between merchant and customer interaction.
🔬 Analysis
Based on insights from the merchant interviews and based on analysis of payment terminals I had brought to the studio, I started to work out pain points that complicate the setup and usage of the terminal.
One big issue with most terminals was the conflation of customer and merchant features on the same surface. Menu buttons and features that are otherwise only relevant for the merchant in specific scenarios, were exposed to the customer at all times. Besides the complexity of these menus this could also make the affordance of the device unclear to the customer.
🗺️ Interaction mapping
To detangle the merchant and customer interactions, I began to separate the physical touchpoints with the device between the merchant and the customer and mapped them to a simplified daily store routine.
In a first step, I looked at all the physical interactions with the device and separated them by merchant and customer interaction. A physical interaction was considered as such when there was direct interaction with the surface of the device.
Mapping the merchant and customer interaction to a timeline shows that the merchant does not interact with the device simultaneously with the customer. The setup process was omitted from the timeline because it usually happens once.
🤖 Validation through prototyping
To validate the separation of a physical terminal and merchant app, I built a physical and web app prototype.
Through the prototype I realized another advantage of this separation: The separation 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 — in other words, primitive input/output operations. 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.
💡 Design Exploration
Through a series of sketches and physical mockups, I explored the physical shape of the payment terminal.
💭 Informing the interface decision
To better inform the decision about the terminal's interface, I created a heatmap of the customer input throughout the different payment scenarios.
To analyze the interface, I mapped every physical customer interaction with he device across every possible payment scenario.
A heatmap derived from the overview revealed that the numerical PIN pad was only used in 2 out of 8 payment scenarios, with the confirm/abort button being used in 3 more edge cases (transaction cancelled by customer).
With only being used in 2 out of 8 payment scenarios but occupying 80% of the device's real estate, I concluded that the PIN pad was not justified. Based on the insights from the mapping, I did a second round of interface exploration where I focused on interfaces without a physical PIN pad.
After multiple design iterations, I decided for a touchscreen interface with a single physical confirm button. The confirm button is the most frequently used and consistent button across all payment scenarios. A physical button adds an artificial friction to the transaction. The customer decides whether and when to complete the transaction by pressing the button.
📐 Visual Design
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.
During the wireframe sketches, transparent paper helped me to layer different screen modals and work out a simple but concise hierarchy for the visual elements.
From the wireframes I concluded a visual hierarchy which is seprated into a primary and secondary modal. In both modals, the upper part of the screen is semantically reserved for device output such as payment status or transaction details. The lower part is reserved for customer interaction (ex. PIN pad) or customer prompts (ex. "Insert card"). Through this, the information hierarchy is consistent across all payment scenarios.
🚀 Cranking up the fidelity
Informed by the wireframes and based on the hierarchy, I translated the wireframes into higher fidelity mockups.
Visual clarity
The guiding principle for the visual design was to create clarity through reduction of elements and consistency of elements. Each step of the payment process is comprehensible and is consistently displayed in the upper third of the screen across all scenarios.Color contrast
The interface colors were informed by accessibility checkers to meet WCAG color contrast guidelines.
Customer input
The lower third of the screen is reserved for loading indicators and customer input. The physical confirm button is contextual and responds to the different payment scenarios and customer interactions.The merchant app
Payments to the terminal are initiated via a smartphone or tablet, which are the drivers of the operation because they house all the communication tools and processing power.
While the initial idea was to solve the communication between merchant and terminal via an app, designing this app was simply outside the scope of this project. The reason for this is that the app houses many complexities and must be closely integrated with a store system to manage ex. the merchant's good or price catalogs.
To still illustrate how the interplay between the terminal and such an application could look like, I did a visual mockup of an smartphone application which shows the process from a merchant's point of view.
💭 Reflection
Looking back, the project was a bumpy ride because I lost my focus several times and pivoted from left to right. Payment systems and the closely related point of sale systems are deep waters and ultimately industrial design plays only a small role in the bigger picture.
Because I became aware of this too late, or refused to acknowledge this (I can solve it all!!11), I had to cut corners because I ran out of time. For example, there was no time to validate the final concept with merchants or customers.
If I had the opportunity to do the project again, I would set clear constraints from the beginning. For example, I would more clearly define my role as an industrial designer at the time and see where I as a industrial designer can come in.
Constraints are not always evil. Sometimes, they safe you from walking off a ledge.
