Media Markt MediaPay

In this new flow we needed to rethink the payment moment. The customer needed much more interaction with the till assistant than observed initially. In the original MYMOID payment process the customer and the merchant could be totally disconnected and the momentum relied on the customer’s actions. The payment could be delayed as long as needed. However, in Media Markt model the interaction wasn’t just between a user and an app, but also between the two users at a time, interchanging information and completing tasks.
Additionally this process needed to be agile and quick, otherwise it would take too long to complete it and that’s a serious hurdle when managing a till.
And besides, the till assistant won’t only use the app to initiate the purchase and complete the payment, but also they would need to register the receipt all along with the cash.

The device was the key in such complexity. We detected that the user and the till assistant would need to be perfectly coordinate, so we helped both to monitor their movements one with the other.
We defined the whole thing from above as a single flow: how will the payments work? How would they connect to the CRM server? But once we started defining the UX we needed to work on both flows separately. The system needed to follow some key steps, so our first effort was to fit them all together.
We had to make decisions about many details that hadn’t been defined previously when the project was kicked off: backend configurations, CRM integrations, operations latency, security issues and peripheral devices connectivity.
We divided use cases in three main groups that affected the UX in a different way:

1. Purchase preparations, in which the customer would decide the payment method and the merchant would register the check out
2. Purchase action, in which the user and the merchant would need to interact between them and individually in a validation process
3. Purchase registering, in which the merchant would need to add a receipt to the purchase and the user would receive the purchase confirmation for support

The devices set up and maintenance were also important but it was more related to a business concern than to a UX issue. So although we also worked on it as a side use case (multi-user feature and activity registration) we relied it on the backend and selling side.

The UX was defined from our MYMOID experience. Aside from some aesthetic polishing, the idea was to simplify as much as possible the flow, making the process understandable and predictable. Although we learnt a lot from previous projects at MYMOID, this approach was more complex –managing receipts, linking bills and dealing with the customer’s device.
On one side, there should be clearly described steps showing of on their device’s screen. We set the process as a dialogue between the machine and the user so that the assistant could know what to do at every moment –we asumed that despite the training there were going to be too many details to pay attention at during the payment.
On the other side, the UI needed to be water-clear and easy to understand. In fact there were few new functions, but the process was long and annoying, and any mistake would imply starting over again from the beginning. Clear messages, clear iconography and clear steps.
Whenever the customer’s app was intended to be attractive, the merchant’s needed to be neat and functional, so we proposed clear and aseptic texts, plain colours, large buttons and direct instructions.
On the other side, even when the device was a weight light and thin iPod 5G, the POS case made it heavy and difficult to hold. We tried to visualise the scenario to make easy to tap buttons and to add evident behaviours.
And finally, we tried to keep the flow as short as we could, reducing the delays and effects by making them short and descriptive -brief animations, direct control and anticipation.
The UI was simple –yet balanced and elegant, as much related to a POS terminal as the brand guidelines let us design it.