Designing checkout flow for chatbots.
DEFINING OBJECTIVE & SCOPE
I worked as a product designer at MagicX where we built chatbots for e-commerce applications. We had our own mobile app, but we didn’t build any frameworks of our own. We curated different partners & integrated their services into our app. Having multiple partners meant having multiple payment gateways. Adding to the complexity of a completely new paradigm for users. Payments via chat.
We were targeting the blue collar demographic who had been taken by a storm of cheap smartphones & chat apps such as Whatsapp, hike, etc. As the chat paradigm was a familiar one we hypothesised that by bringing complicated app flows into simplified chats would lead to a higher conversions better adoption.
As the payment flow was common in all the chatbots we built may it be grocery shopping or buying bus tickets, it needed to be solved on a holistic level. I worked on improving the payments flow for a year.
When we launched the app to test out our hypothesis, so we built a Minimum Viable Product(MVP). It consisted simple chat bubbles & hyperlinks linking to payment gateways. After initial testing and good response we got down to actually building it from ground up.
Our potential users were familiar to chatting with their friends but most of our potential users had never made a online transaction, may it be card swipe at POS or buying something from Amazon. Most of our users were used to transacting via cash. A typical user story for us looked like this:
For most people viewing digital money was a scary thing as they couldn’t see where and how did money go from point A to B at the click of a button. So we decided to address this FEAR in our users by building a product which would keep them informed about the status of their money at all times. Something that gave constant feedback to users.
We partnered with a payment wallet which would give up payment updates instantaneously. Paytm provided us with realtime feedback on the payment status without redirecting to a different state.
So the initial construct we came up with looked something like this:
With this change we increased our successful transactions by over 50%
we still had other payment options, but we wanted to promote the behaviour of quickly transacting so we hid the cash on delivery option below the prominent paytm CTA.
In the 2.5 months the new payment flow had been live we kept getting feedback on how it was performing. We, observed that the payment CTA was still not very apparent to the users.
Instead of rethinking the entire approach we decided to run A/B tests by changing the the prompt text accompanying the CTA. 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.
Changes with the text “Tap to Pay” and “Tap to make payment” performed better than the rest by 6%.
In the 8 months we had been active we had expanded to about 7 different chatbots including utility bill payments & cab hailing bot. With so many different bots we were sending users too many messages from our end & the information in the messages was unstructured making it hard for users to scan through the relevant information.
We were partnering we multiple vendors for different bots so some of the transactions were being delayed by as long as 10 minutes sometime. As a result we needed a order tracking mechanism to handle such cases.
In order to address the issue or scanning through information we came up with the concept of two cards, Order summary card & payment summary card:
or in the context of the user flow:
To address the second problem of having delayed order completions we built a way for the users to track their orders. So, if the payment is successful we affirm the payment completion & give them a way to track their order.
On clicking the “Track Order” CTA would give a detailed summary of their order. For every state of the order a detailed text highlighting the current state of their order.
To deliver a better user experience we also designed emailers of the order & payment status.
By doing this we were able to catch-up on the % of successfully completed orders we were losing out and eventually increased our over all completed orders by 4%.
We also observed another impact due to this change. This was the first time we were giving a “contact us” CTA to the users. The number of users who contacted us with issues decreased by about 14%.
Three months later we again surveyed our users for feedback and we discovered some problems our users were facing.
- Delivering information via cards was appreciated but users complained it took a lot of real estate. A lot of times users had to scroll through to see the entire summary
- 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. Regular users would prefer to pay for a recharge via Paytm but would prefer to pay via cash for food orders. So, having preferred mode of payment(default) in category was a pattern.
- 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.
Addressing the above issues. We decided to reorganise the information to be more contextual & include the billing summary along with the payment button to build in more context and setting it as the preferred mode of payment.
You can also check out the a working prototype below.
[Marvel link pending]
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.