Online transaction
overview ux flow, wireframes, mockups
Overview flow
Flow of the basic user interaction from the beginning point where user is interested in obtaining VIP, to the end point where user has successfully obtained VIP. This phase consists of initial discussion with business stakeholders and the payment team in order to get a scope of requirements and possibilities.
VIP Plans page
》Type A: dropdown reveals payment methods
∘ priority on making all the plan types visible in one glance
∘ this allows easy comparison between price points & length of subscription plans
∘ once user is interested in a particular plan, the dropdown reveal immediately lets them find out if they are able to proceed with the listed payment methods
∘ this allows easy comparison between price points & length of subscription plans
∘ once user is interested in a particular plan, the dropdown reveal immediately lets them find out if they are able to proceed with the listed payment methods
__________________________________
》Type B: plans with recommended payment methods + dropdown for others
∘ a promoted payment method for cases of business partnerships or promotional events
∘ in wireframe, for Plan 2, users will tap dropdown once to reveal the recommended payment method, then tap ‘more options’ to see other methods. this is adding another step in a flow where things should be kept simple and direct to reduce risk of user frustration and dropping out of flow
∘ in wireframe, for Plan 2, users will tap dropdown once to reveal the recommended payment method, then tap ‘more options’ to see other methods. this is adding another step in a flow where things should be kept simple and direct to reduce risk of user frustration and dropping out of flow
__________________________________
》Type C: dropdown reveals payment methods
∘ branching from Type B; moving the dropdown UI to the bottom of the plans in an attempt to simplify Type B
now all plans only require 1 tap to reveal all payment methods while still including the ‘recommended payment method’ feature
∘ wording of dropdown may need to change to align all plan types
now all plans only require 1 tap to reveal all payment methods while still including the ‘recommended payment method’ feature
∘ wording of dropdown may need to change to align all plan types
__________________________________
》Final wireframes: separating payment methods from plans
After a round of usability testing is done using the initial wireframes, it's found that the layout becomes packed once all the textual components are filled and the dropdowns are engaged. At this point, user may be overwhelmed in trying to pick a plan.
The decision then is to cleanly split the various decisions that a user has to make and allowing them to focus. First is to choose a plan that suits them the best (period, price, benefits). Once done, they are then shown the payment methods available for that plan. The payment team strives to provide all methods for all plans, but business agreements will inevitably make some unavailable. At this point, if the user decides that none of the methods are suitable, they can go back and select a different plan.
__________________________________
Transaction flow of various payment methods
1) Credit Card
∘ simple & standard credit card flow
∘ business requirement is to include a ‘saved cards’ feature (Step 1B) that allows user to opt for their card to be remembered for future transactions
∘ ‘security code’ to have a simple modal that pops up to explain where it can be found on a standard card
errors in credentials that can be detected before form submission are to be shown before the review step
∘ business requirement is to include a ‘saved cards’ feature (Step 1B) that allows user to opt for their card to be remembered for future transactions
∘ ‘security code’ to have a simple modal that pops up to explain where it can be found on a standard card
errors in credentials that can be detected before form submission are to be shown before the review step
》Initial wireframes
》Final wireframes
__________________________________
2) Carrier Billing
∘ business requirement is for the UI to be flexible enough to display the variety of carriers available in Malaysia while not cluttering the layout. thus the design idea is to separate the carrier selection (Step 1) from the previous VIP Plans page
∘ in cases where user’s account is tied to the business’ header-enriched feature, Step 2 can be pre-filled with the correct mobile number. Highly encouraged to allow user the ability to confirm the number on their own instead of immediately taking them to Step 3
∘ Step 3 provides options to counter the possibility of verification code not being received by the user: Change number & Resend code
∘ in cases where user’s account is tied to the business’ header-enriched feature, Step 2 can be pre-filled with the correct mobile number. Highly encouraged to allow user the ability to confirm the number on their own instead of immediately taking them to Step 3
∘ Step 3 provides options to counter the possibility of verification code not being received by the user: Change number & Resend code
》Initial wireframes
》Final wireframes
__________________________________
3) Google Play
∘ standard transaction flow using Google play; the flow is an overlay above the current page once user has selected the GP payment method
__________________________________
Success page
∘ purchase successful notification
∘ purchase receipt
∘ encourage user to immediately begin VIP experience by suggesting next action
∘ purchase receipt
∘ encourage user to immediately begin VIP experience by suggesting next action
__________________________________
