User flows
Integrating a new payment form with a minimal impact on the user experience
Client
Canada Post
Type
B to B
B to C
Role
Lead product designer
Team
5 developpers
3 QA testers
1 business architect
1 project manager
2 product owners
​Context
The number of digital fraud is augmenting and consumers data are more and more at risk. Therefore it becomes imperative to follow security procedures and technologies to stop any theft during transactions. However, these evolve all the time and this become very costly.
Until now, Canada Post had a custom payment form and was maintaining its security but to gain time and money, they decided to partner with Moneris to move the maintenance of the form directly to the third party partner.
​​
In this project, I led the integration of a new payment form into the 12 transactional applications Canada Post has, and ensure a minimal disruption in the user experience.
I worked in close collaboration with the business and solution architects to understand the requirements and limitations of the solution, with 5 developers and 3 QA testers to implement accurately the solution, and with stakeholders to present the new experience, and prepare them to the changes in the experience of their products. ​
Understanding the current situation
State of the payment form on 12 applications
An audit of the 12 applications gave me an idea of the problems I would be facing:
1- Some features are currently present on the payment form. How to integrate these features to the future form?
2- Some applications has similitudes but some were very different and would need specific attention.
​​​
The features of the current form ​​
Save card for future use
Saving the card information to the user profile and showing it as a saved card on future transactions
Address complete
Feature allowing to autocomplete the address field, avoiding address format mistakes
Billing address same as shipping address
This alows the user to gain time by skip the entry of their address.
Saved cards
Showing the user's cards recorded previously, allowing to complete the transaction faster.
Consent agreement
To make sure the user agrree to Canada post recording their information for this transaction, to protect CPC legally.
To look for solutions, I discuss with the team to understand the limitations of the new form and how to incorporate the features from the previous form.
The limitations from the new form
Design
The form has a specific design and wording that can't be customized.
Validation
The validation of the form can only validate the form, which means that no other validation can be done on the page of the form.
Features
None of the features we have are proposed in the new form and they can't be added in the short term.
Looking for solutions
Balancing user expectations and technical constraints
I started to look at the features individually to find solutions regarding keeping them and where to place them in the future experience.
​Example of solution for the consent agreement
Current implementation
After selecting to pay with a new card, the user fill out the form and has to check the box to agree to the consent agreement below the form. ​
​
Multiple solutions less ideal than the current state were possible but one question would solve everything: Do we really need the consent agreement at each transaction? In the case of a yes, the following questions was: could we use a passive consent?
After asking the legal team, their recommendation was to keep the consent agreement and to keep it active, meaning the user has to do an action to agree in order to make sure they have seen the conditions.
Also, to make the agreement valid, it had to be placed before the Pay button. ​​​
Propositions
​
Option A
Adding a modal after the selection of the payment with a new card.
​
​Pros: Focuses the user on the task to accomplish. The consent can't be missed.
Cons: The creation of a modal would require too much time to the developers to create. This solution was excluded.
​
​Option B
Adding the Consent agreement above the Moneris form.
​
Pros: It is the first form item the user see when arriving on the form.
Cons: The user has to agree to some conditions before adding their information. Also, the checkbox would not be able to be validated because it is placed on the same page as the Moneris form. Only the form would be taken into consideration as the button validates it only.​
This solution did not work.
​
​Option C
After the selection of the payment with a new card, the Consent agreement check box ​appears underneath the selection. The user has to check the box and then continue to the form.
​
Pros: The checkbox is placed outside the iframe so its validation is not interfering with the form validation. The user agrees to it before paying.
Cons: The consent is located before seeing the form.
​
This solution was the most viable and we went for it.
Design
​
I worked with the content writer on the team to add some context around the check box for the users, as well as adapting the message to Canada Post standards.
End to end user flows
Creating the new experience, as seamless as possible
With solutions for each current feature, I started by creating the end to end flow for the application which had the most use cases, in order to the most complete flow. Then I created the flow for the other applications, adapting it for each specific cases. For example, when only the credit card payment was available or if the billing address was not required.
The grey background present the happy path and on the blue background, when the Moneris form is visible by the user.
The orange background present the the screens with a negative outcome (such as when the user didn't select the consent agreement).
The white background is showing the other combinaisons. For example, the form presented for guest users.
​
​
​Example of user flow
The letter indicates which personas it is applicable to
Use cases
Specific notes for developers
User action