Designing Payments for Bots.
I am a UX designer at MagicX & have been designing bots for the past 10 months. One of my very first designs at MagicX was to design the payments flow. The payments flow has been evolving over the past 10 months. Here is a retrospective account of how the payment process has evolved over the past year.
SEPTEMBER 2015:
Payments over chat had never been done before and was a completely new paradigm.
We were using Instamojo to power payments. It provided the users option to pay either via Debit/Credit cards or via Netbanking. The first attempt designing payments at the chat platform was to give a clickable button with due amount to be paid. On clicking the button it redirected the user to a web view where the users could select to pay either via Debit/Credit card/Net banking enter their details and make the Payments.
Around this time we began integrating with Paytm wallet for payments. The Paytm flow allowed users a one time login into their Paytm account and rest of the payments could be done with one tap pay.
So now there were going to be two payment flows. This meant an added level of complexity for users as now they had to choose in between multiple payment options.
So it was clear that the payments flow needed to be completely revamped.
So while designing the new flow, kept one of the core user emotions in sight, “Fear”. The momentary state when the user has authenticated the payment(tapped on the button) but has not received the status of the payment, whether it has failed or was successful. To understand the problem better, we devised a user story.
Keeping Ganesh’s FEAR(due to lack of feedback) as a motivation to design we decided to design the payment process to give users a good accountable feedback at each step.
Alongside it was decided that payment via paytm should have a higher preference as it simply requires a one time login and then every payment ever made could be done in a single tap.
So we started with initial concepts of designs, here are some of the initial concepts.
In these concepts the simplicity of the right-most design seemed to fit our objectives, it had a clear hierarchy in the higher amount of importance given to Paytm and the lower amount of importance given to other options.
And to solve the problem of feedback in the payments flow we divided the payment flow in; Unpaid/To pay, payment initiated & payment completion states. Once the user taps on the payment button it simply changes states at the same place keeping the user informed at all stages.
As for paying via other options, when the user exited the web view and returned to chat view, user was to be shown the payment success as a completion indicator on the same button.
DECEMBER 2015:
In December we had sometime from implementing new features and to have a look at some old features we had implemented. By now we had sufficient number of daily orders coming in to run some tests.
Over time we had received a constant feedback consistently:
The Payment button looks like a button we understand we have to click it but we don’t know what will happen when we click it. Are we choosing the Paytm as a payment method or are we paying by clicking on it.
The users understood that it was a Paytm button but new users kept second guessing wether it will select paytm as a payment option or will it commence payment.
Keeping the feedback in mind we experimented with a parameter from the original design to see if we could improve conversion.
We tried out in the payments option was to change the subtitle in the payments bubble button. Originally it used to read out “Pay using”, we experimented with a few alternative copies of text which were leading in nature. So, the different copies we tried out varied from “Tap to pay” “Tap to pay now” “Tap to make payment “Tap to complete order” “Click to pay” “Click to complete order”, etc.
There were more orders completed with the changed texts. Changes with the text “Tap to Pay” and “Tap to make payment” performed better than the rest.
MARCH 2016:
In January 2016 we had pivoted from MagicTiger(Manual human assistance) to the MagicX(Yayy! automated bots). While doing this we shifted the login to app via Paytm accounts. So the users didn’t need to add their paytm accounts separately.
Around March we were launching with an in app wallet(Credits) which acted similar to cash back and karma points. This brought on a new challenge of informing the users of how the payment will be split.
Previously the user was informed only how much the final amount they had to pay and not the distribution. In case of MagicTiger it was easy as the user could simply ask for the distribution and a human could tell exactly what the user wanted to know, this was a problem in case of Bots.
So, inspired by the concept of individual cards having structured messages to show an abundance on information we came up with two cards; Order Summary & Payment Summary.
So whenever the user has given the bot the appropriate information regarding the bill amount, how the payments are split setting up the right context for the payment button.
Once again we visited Ganesh’s user story & observed that we were putting our complete focus on the users needs before the payments and a bad job when it came to giving the user feedback after payments are done. We sent a toast after the payment was successful or not but the user had no way of knowing if his recharge was complete or whether his electricity bill was paid. So after the payments we created two feedback messages;
One normal message notifying the user of the current state of the order, weather the recharge order was complete or not, was the electricity bill paid.
& a “Track Order” button which would let the user track the status of their order and their previous orders.
A detailed summary of their order. If someone paid a bill, clicking on the order tracking would show the user the current status of the order and the order details and payment summary. For every state of the order a detailed text highlighting the current state of their order. For example; if someones recharge had failed and they were to be refunded the amount the text would read, “Your refund has been initiated, you shall receive the amount in 7–10 working days”
Along with the order details we also designed email receipts to be sent to the users at different points.
JUNE 2016:
By now we were armed with a few more insights into how the payments flow was structured.
- There were three consecutive messages sent in succession to the user with a plethora of information. The information was a good feedback to the user but the vertical real estate consumed by the messages was too much.
- Now we had added an additional payments option of Cash on delivery to the food flow making it a category accepting all forms of payments. So we needed to make switching in between payment methods easier.
- We had observed payments patterns amongst users. Such as users would prefer to pay for a recharge via Paytm but would prefer to pay via cash for food orders. So, having the preferred mode of payments(default) in different categories was the next step to go.
- Also, regarding the the current amount in their Paytm wallet. The button bubble had two amounts written, one was the amount due and the other was their existing Paytm balance. User’s were confused at the first glance as to which was the amount they were to pay.
There was also the case where we had given generic titles such as order summary, payment summary and Track order in the pre and post payments. We decided to change the language in the overall flow to to be more personalised with respect to individual categories.
The New Designs
In the new design we combined the payment summary & the payments as a single card.
Text for order summary customised as per individual bots.
Impact
During user testing responses were positive and people seemed to get what amount they had to pay straightforward. The number of successful transactions increased by 2% as a result of this change.
Other exploration
We protoyped a voice based interaction where users who couldn’t type could order things without the barrier.
This idea never made beyond experimental phase as a dominant user base didn’t have appropriate hardware to support an interactive voice chat & limitations of voice tech to recognize local languages & accents.
