TD Bank
Timeline
2021 - 2022
My Role
Senior Product Designer
What is TD Bank?
Headquartered in Toronto, Canada, TD Bank (Toronto-Dominion Bank) offers a full range of financial products and services to over 26 million customers worldwide. TD Bank is the 2nd biggest bank in Canada while being one of the top 10 largest banks in the USA.
Team
Using Agile, our Pod consisted of many roles across different categories. We had a Business team, Development team, and Design team.
My Role
I was the lead UX/UI Designer for Product Selector. My goal was to design a new shopping experience based on user driven data. Here are some of my duties:
Host workshops for user information and collaborative ideation
Design wireframes and create prototypes
Conduct user testing
Reviewing and oversee transition from design to development
Users
The main users are our Tellers at physical TD Bank stores. This includes a variety of different roles such as Store Manager, Individual Customer Assistant, Customer Service Representative, and Front Desk Teller. Making it easily usable to all levels of users was crucial.
New Application, Existing Flow
Although Product Selector is a new application, it was being squeezed into an existing application flow. I had to brainstorm an experience that seamlessly integrated into the existing end-to-end flow.
Scalability was a huge factor I had to keep in mind. As more features are due to roll in during sprints, it was important that they were able to be updated into the design without any complications.
Initial Product Selector - Single Signers
The first thing I did was figure out and plan the flow direction for users. The end-to-end experience was crucial to keep users on track to fulfill all requirements requested.
From Uncertainty to Clarity
Strategy Discovery Phase (narrowing the approach)
Research
Ideate
Conceptualize
Evaluate
Tactical Project Phase (refining the design)
Design
Usability Testing
Develop
Pilot
Requirements
For our high level requirements we had two sets of paths:
Happy Path: the ideal experience where no errors and complications occur
Unhappy Path: all the possible errors and error handling based on current restrictions and API constraints
User Flow
Many high level requirements go into the specificities of each action and function, but the general user flow goes like this:
Choose a product type
Add a product plan
Apply add-on(s) to chosen product plan
Checkout
Workshops
Workshops were a great way to get ideas from multiple roles within the TD stores. We involved a variety of store employees to bring in their ideas and requests. Splitting into teams with a mix of designers, business partners, and store employees, we were able to brainstorm multiple visual ideas and concepts.
Workshops were a great way to get ideas from multiple roles within the TD stores. We involved a variety of store employees to bring in their ideas and requests. Splitting into teams with a mix of designers, business partners, and store employees, we were able to brainstorm multiple visual ideas and concepts.
Main: Only allowing single Product Types per session
The need to cross-platform reference for information and promotions
Key products buried within system's architecture
Pre-filling product offers towards higher-tier accounts
Initial Ideation
Using the ideas from the workshops, I began to ideate a shopping experience that tackled the pain points. Using successful online shopping experiences as references, I took what worked and customized it to fit the high level requirements for Product Selector.
For our initial requirements, the target customers were single person sign ups. However, there was news of multi-party joint being included in the future so I made sure to keep future state situations in mind when designing. Scalability was crucial due to changes and new implementations in the future.
The ideal experience was to prevent users from having to restart the product selection process whenever they changed product types. Having all available selections and sub-selections shown at all times helps users switch between products easily.
The ability to add any combination of different product types, products, and add-ons within the same cart allowed flexibility. This results in more conversational opportunities for additional products per customer.
Conceptualize
Keeping all these factors in mind, I created wireframes for the ideal experience. There were 3 main components - header, product selection area, and cart. The header has two pieces of user information:
Employee ID, Store Information, and Journey: This is used to make sure the correct employee is assisting the customer. Store Information is needed because some products are only available for certain stores. Journey information allows employees to know the ID of the current flow - allowing other employees to pick up and continue a journey that was put on hold.
Customer Information: This is used to ensure the correct employee is being assisted. For future state (multi-party joint): this ensures ALL members of the party have been brought into Product Selector.
The product selection area is a 3-step process:
Product Type - the product type determines what kinds of products will be available. Product Types include Checking, Savings, and Money Market.
Product Plans - the products are all the available products within the product type and other factors such as current store.
Add-ons - the add-ons are attachments customers can apply to their products.
The cart shows all products and their associated add-ons. The user can proceed to checkout, sending them to the next application - Swift Signs.
Aligning visual designs
As previously mentioned, Product Selector was the newest application being implemented into an existing end-to-end flow. This meant that although it is a separate application, it still needed to seem seamless between other applications.
After products are checked out from Product Selector, the users are sent to Swift Signs - an application where Tellers can assign and fulfill customers with the products that were checked out. Swift Signs is an application designed and developed by TD’s Canadian branch.
We held weekly stand ups with the Swift Signs team to make sure we aligned on designs and updated each other on any requirement changes. Anything that affected us, affected them (vice versa).
User testing
After completing visual designs, it was time for user testing. Although our concept testing yielded great results and feedback from our business stakeholders, it was time to test our design using actual employees. Our participants ranged from all areas of the spectrum:
Age
Roles
Years of experience
Store location
Device
Using a prototype, we held user interviews with a realistic situation approach. With us pretending to be customers, the Tellers would have to assist us in checking out successfully. Throughout the tests, users were encouraged to voice their positives and negatives as the test went on. At the end of their respective tests, we had the testers fulfill a System Usability Scale (SUS) questionnaire.
User testing results
After gathering, organizing, and finalizing all interview feedback and recordings, we had an amazing score of 95 on the System Usability Scale (68 being above average, and 80+ being excellent). This gave us confidence in meeting our user’s expectations.
Sprinting & Developing
After making slight adjustments based on our user testing feedback, it was time to begin sprinting. During these sprint timelines, we had multiple sessions per week to refine our high level requirements. This meant there were design changes that needed to be made in accordance to these requirements.
Final designs
Through numerous iterations using all the feedback, requirements, and changes, we were able to finalize the design and experience for Product Selector.
Conclusion
After successful iterations and user testing, we were able to build a design that made the shopping experience streamlined and easy. Employees of different roles and levels of experience were able to become accustomed to the new Product Selector workflow. We were able to tackle the main pain points that employees had while introducing more logical and quality of life features. As of now, we are piloting Product Selector with a few selection of physical TD stores.
There are more features to come in the future, such as multi-party, joint, and account titling; however for now we want to introduce the new flow to our employees. Having them get accustomed to the new application will make it easier to adjust to any new features in the future.
TD Bank
Timeline
2021 - 2022
My Role
Senior Product Designer
What is TD Bank?
Headquartered in Toronto, Canada, TD Bank (Toronto-Dominion Bank) offers a full range of financial products and services to over 26 million customers worldwide. TD Bank is the 2nd biggest bank in Canada while being one of the top 10 largest banks in the USA.
Team
Using Agile, our Pod consisted of many roles across different categories. We had a Business team, Development team, and Design team.
My Role
I was the lead UX/UI Designer for Product Selector. My goal was to design a new shopping experience based on user driven data. Here are some of my duties:
Host workshops for user information and collaborative ideation
Design wireframes and create prototypes
Conduct user testing
Reviewing and oversee transition from design to development
Users
The main users are our Tellers at physical TD Bank stores. This includes a variety of different roles such as Store Manager, Individual Customer Assistant, Customer Service Representative, and Front Desk Teller. Making it easily usable to all levels of users was crucial.
New Application, Existing Flow
Although Product Selector is a new application, it was being squeezed into an existing application flow. I had to brainstorm an experience that seamlessly integrated into the existing end-to-end flow.
Scalability was a huge factor I had to keep in mind. As more features are due to roll in during sprints, it was important that they were able to be updated into the design without any complications.
Initial Product Selector - Single Signers
The first thing I did was figure out and plan the flow direction for users. The end-to-end experience was crucial to keep users on track to fulfill all requirements requested.
From Uncertainty to Clarity
Strategy Discovery Phase (narrowing the approach)
Research
Ideate
Conceptualize
Evaluate
Tactical Project Phase (refining the design)
Design
Usability Testing
Develop
Pilot
Requirements
For our high level requirements we had two sets of paths:
Happy Path: the ideal experience where no errors and complications occur
Unhappy Path: all the possible errors and error handling based on current restrictions and API constraints
User Flow
Many high level requirements go into the specificities of each action and function, but the general user flow goes like this:
Choose a product type
Add a product plan
Apply add-on(s) to chosen product plan
Checkout
Workshops
Workshops were a great way to get ideas from multiple roles within the TD stores. We involved a variety of store employees to bring in their ideas and requests. Splitting into teams with a mix of designers, business partners, and store employees, we were able to brainstorm multiple visual ideas and concepts.
Workshops were a great way to get ideas from multiple roles within the TD stores. We involved a variety of store employees to bring in their ideas and requests. Splitting into teams with a mix of designers, business partners, and store employees, we were able to brainstorm multiple visual ideas and concepts.
Main: Only allowing single Product Types per session
The need to cross-platform reference for information and promotions
Key products buried within system's architecture
Pre-filling product offers towards higher-tier accounts
Initial Ideation
Using the ideas from the workshops, I began to ideate a shopping experience that tackled the pain points. Using successful online shopping experiences as references, I took what worked and customized it to fit the high level requirements for Product Selector.
For our initial requirements, the target customers were single person sign ups. However, there was news of multi-party joint being included in the future so I made sure to keep future state situations in mind when designing. Scalability was crucial due to changes and new implementations in the future.
The ideal experience was to prevent users from having to restart the product selection process whenever they changed product types. Having all available selections and sub-selections shown at all times helps users switch between products easily.
The ability to add any combination of different product types, products, and add-ons within the same cart allowed flexibility. This results in more conversational opportunities for additional products per customer.
Conceptualize
Keeping all these factors in mind, I created wireframes for the ideal experience. There were 3 main components - header, product selection area, and cart. The header has two pieces of user information:
Employee ID, Store Information, and Journey: This is used to make sure the correct employee is assisting the customer. Store Information is needed because some products are only available for certain stores. Journey information allows employees to know the ID of the current flow - allowing other employees to pick up and continue a journey that was put on hold.
Customer Information: This is used to ensure the correct employee is being assisted. For future state (multi-party joint): this ensures ALL members of the party have been brought into Product Selector.
The product selection area is a 3-step process:
Product Type - the product type determines what kinds of products will be available. Product Types include Checking, Savings, and Money Market.
Product Plans - the products are all the available products within the product type and other factors such as current store.
Add-ons - the add-ons are attachments customers can apply to their products.
The cart shows all products and their associated add-ons. The user can proceed to checkout, sending them to the next application - Swift Signs.
Aligning visual designs
As previously mentioned, Product Selector was the newest application being implemented into an existing end-to-end flow. This meant that although it is a separate application, it still needed to seem seamless between other applications.
After products are checked out from Product Selector, the users are sent to Swift Signs - an application where Tellers can assign and fulfill customers with the products that were checked out. Swift Signs is an application designed and developed by TD’s Canadian branch.
We held weekly stand ups with the Swift Signs team to make sure we aligned on designs and updated each other on any requirement changes. Anything that affected us, affected them (vice versa).
User testing
After completing visual designs, it was time for user testing. Although our concept testing yielded great results and feedback from our business stakeholders, it was time to test our design using actual employees. Our participants ranged from all areas of the spectrum:
Age
Roles
Years of experience
Store location
Device
Using a prototype, we held user interviews with a realistic situation approach. With us pretending to be customers, the Tellers would have to assist us in checking out successfully. Throughout the tests, users were encouraged to voice their positives and negatives as the test went on. At the end of their respective tests, we had the testers fulfill a System Usability Scale (SUS) questionnaire.
User testing results
After gathering, organizing, and finalizing all interview feedback and recordings, we had an amazing score of 95 on the System Usability Scale (68 being above average, and 80+ being excellent). This gave us confidence in meeting our user’s expectations.
Sprinting & Developing
After making slight adjustments based on our user testing feedback, it was time to begin sprinting. During these sprint timelines, we had multiple sessions per week to refine our high level requirements. This meant there were design changes that needed to be made in accordance to these requirements.
Final designs
Through numerous iterations using all the feedback, requirements, and changes, we were able to finalize the design and experience for Product Selector.
Conclusion
After successful iterations and user testing, we were able to build a design that made the shopping experience streamlined and easy. Employees of different roles and levels of experience were able to become accustomed to the new Product Selector workflow. We were able to tackle the main pain points that employees had while introducing more logical and quality of life features. As of now, we are piloting Product Selector with a few selection of physical TD stores.
There are more features to come in the future, such as multi-party, joint, and account titling; however for now we want to introduce the new flow to our employees. Having them get accustomed to the new application will make it easier to adjust to any new features in the future.
TD Bank
Timeline
2021 - 2022
My Role
Senior Product Designer
What is TD Bank?
Headquartered in Toronto, Canada, TD Bank (Toronto-Dominion Bank) offers a full range of financial products and services to over 26 million customers worldwide. TD Bank is the 2nd biggest bank in Canada while being one of the top 10 largest banks in the USA.
Team
Using Agile, our Pod consisted of many roles across different categories. We had a Business team, Development team, and Design team.
My Role
I was the lead UX/UI Designer for Product Selector. My goal was to design a new shopping experience based on user driven data. Here are some of my duties:
Host workshops for user information and collaborative ideation
Design wireframes and create prototypes
Conduct user testing
Reviewing and oversee transition from design to development
Users
The main users are our Tellers at physical TD Bank stores. This includes a variety of different roles such as Store Manager, Individual Customer Assistant, Customer Service Representative, and Front Desk Teller. Making it easily usable to all levels of users was crucial.
New Application, Existing Flow
Although Product Selector is a new application, it was being squeezed into an existing application flow. I had to brainstorm an experience that seamlessly integrated into the existing end-to-end flow.
Scalability was a huge factor I had to keep in mind. As more features are due to roll in during sprints, it was important that they were able to be updated into the design without any complications.
Initial Product Selector - Single Signers
The first thing I did was figure out and plan the flow direction for users. The end-to-end experience was crucial to keep users on track to fulfill all requirements requested.
From Uncertainty to Clarity
Strategy Discovery Phase (narrowing the approach)
Research
Ideate
Conceptualize
Evaluate
Tactical Project Phase (refining the design)
Design
Usability Testing
Develop
Pilot
Requirements
For our high level requirements we had two sets of paths:
Happy Path: the ideal experience where no errors and complications occur
Unhappy Path: all the possible errors and error handling based on current restrictions and API constraints
User Flow
Many high level requirements go into the specificities of each action and function, but the general user flow goes like this:
Choose a product type
Add a product plan
Apply add-on(s) to chosen product plan
Checkout
Workshops
Workshops were a great way to get ideas from multiple roles within the TD stores. We involved a variety of store employees to bring in their ideas and requests. Splitting into teams with a mix of designers, business partners, and store employees, we were able to brainstorm multiple visual ideas and concepts.
Workshops were a great way to get ideas from multiple roles within the TD stores. We involved a variety of store employees to bring in their ideas and requests. Splitting into teams with a mix of designers, business partners, and store employees, we were able to brainstorm multiple visual ideas and concepts.
Main: Only allowing single Product Types per session
The need to cross-platform reference for information and promotions
Key products buried within system's architecture
Pre-filling product offers towards higher-tier accounts
Initial Ideation
Using the ideas from the workshops, I began to ideate a shopping experience that tackled the pain points. Using successful online shopping experiences as references, I took what worked and customized it to fit the high level requirements for Product Selector.
For our initial requirements, the target customers were single person sign ups. However, there was news of multi-party joint being included in the future so I made sure to keep future state situations in mind when designing. Scalability was crucial due to changes and new implementations in the future.
The ideal experience was to prevent users from having to restart the product selection process whenever they changed product types. Having all available selections and sub-selections shown at all times helps users switch between products easily.
The ability to add any combination of different product types, products, and add-ons within the same cart allowed flexibility. This results in more conversational opportunities for additional products per customer.
Conceptualize
Keeping all these factors in mind, I created wireframes for the ideal experience. There were 3 main components - header, product selection area, and cart. The header has two pieces of user information:
Employee ID, Store Information, and Journey: This is used to make sure the correct employee is assisting the customer. Store Information is needed because some products are only available for certain stores. Journey information allows employees to know the ID of the current flow - allowing other employees to pick up and continue a journey that was put on hold.
Customer Information: This is used to ensure the correct employee is being assisted. For future state (multi-party joint): this ensures ALL members of the party have been brought into Product Selector.
The product selection area is a 3-step process:
Product Type - the product type determines what kinds of products will be available. Product Types include Checking, Savings, and Money Market.
Product Plans - the products are all the available products within the product type and other factors such as current store.
Add-ons - the add-ons are attachments customers can apply to their products.
The cart shows all products and their associated add-ons. The user can proceed to checkout, sending them to the next application - Swift Signs.
Aligning visual designs
As previously mentioned, Product Selector was the newest application being implemented into an existing end-to-end flow. This meant that although it is a separate application, it still needed to seem seamless between other applications.
After products are checked out from Product Selector, the users are sent to Swift Signs - an application where Tellers can assign and fulfill customers with the products that were checked out. Swift Signs is an application designed and developed by TD’s Canadian branch.
We held weekly stand ups with the Swift Signs team to make sure we aligned on designs and updated each other on any requirement changes. Anything that affected us, affected them (vice versa).
User testing
After completing visual designs, it was time for user testing. Although our concept testing yielded great results and feedback from our business stakeholders, it was time to test our design using actual employees. Our participants ranged from all areas of the spectrum:
Age
Roles
Years of experience
Store location
Device
Using a prototype, we held user interviews with a realistic situation approach. With us pretending to be customers, the Tellers would have to assist us in checking out successfully. Throughout the tests, users were encouraged to voice their positives and negatives as the test went on. At the end of their respective tests, we had the testers fulfill a System Usability Scale (SUS) questionnaire.
User testing results
After gathering, organizing, and finalizing all interview feedback and recordings, we had an amazing score of 95 on the System Usability Scale (68 being above average, and 80+ being excellent). This gave us confidence in meeting our user’s expectations.
Sprinting & Developing
After making slight adjustments based on our user testing feedback, it was time to begin sprinting. During these sprint timelines, we had multiple sessions per week to refine our high level requirements. This meant there were design changes that needed to be made in accordance to these requirements.
Final designs
Through numerous iterations using all the feedback, requirements, and changes, we were able to finalize the design and experience for Product Selector.
Conclusion
After successful iterations and user testing, we were able to build a design that made the shopping experience streamlined and easy. Employees of different roles and levels of experience were able to become accustomed to the new Product Selector workflow. We were able to tackle the main pain points that employees had while introducing more logical and quality of life features. As of now, we are piloting Product Selector with a few selection of physical TD stores.
There are more features to come in the future, such as multi-party, joint, and account titling; however for now we want to introduce the new flow to our employees. Having them get accustomed to the new application will make it easier to adjust to any new features in the future.