Background

In collaboration with a team of 2 designers and 3 engineers, I designed an accessible self-service banking tool for TD Bank. The goal was to make everyday banking easier for users with visual and motor impairments by reimagining how accessibility integrates into core financial experiences.

Problem

Accessibility in many banking systems is still treated as an add-on. Visual contrast, keyboard navigation, and reachability often fail to meet the needs of real users.

Similar queueing services failed users with low vision, small motor control, or those who are seated. Interfaces often had small touch targets, complex flows, or hidden controls. On the digital side, users with memory or dexterity challenges struggled with common tasks. Compounding that, disorganised queues and slow service led to frustration and dissatisfaction, which impacts both usability and brand perception.

The challenge: how to create a kiosk and digital interface that truly considers physical, sensory, cognitive, and motor differences, especially within TD’s accessibility mandate (their Multi-Year Accessibility Plan).

1

Design an inclusive banking experience that meets WCAG 2.1 AA standards

2

Streamline the queueing process to reduce wait times, confusion, and staff intervention

3

Demonstrate measurable improvements in usability, accessibility, and customer satisfaction

Process

We laid out the project in four main stages:

Part I: Research & Ideation
I brainstormed broadly, even beyond what seemed feasible, to understand the full solution space. Ideas were clustered into themes like queue optimisation, input accessibility, assignment logic, and universal design. I mapped the queuing journey from arrival to service and ran a stakeholder analysis (users, TD regulators, engineers, local branches) to balance needs.

Part II: Paper Prototyping
With early flows defined, I sketched paper prototypes of screens and interactions. Users were invited to step through tasks like “join queue,” “select service type,” or “cancel request.” I observed where confusion or hesitation occurred, then iterated.

Part III: Functional Prototype
I built a digital prototype in Figma (or a prototyping tool), integrating touch, card-tap input, voice or speech hints, and keyboard fallback. I ran usability sessions with participants, including those who use assistive tools. I collected both quantitative metrics (task success, error rates, time) and qualitative feedback (comments, frustration, suggestions).

Part IV: Final Product / High-Fidelity Version
I polished the UI, applied accessibility enhancements like high-contrast variants, focus indicators, and alternative input flows. The prototype simulated real use. According to my report, participants achieved 100% completion across core flows and rated the interface with an average SUS score of 82.9, reflecting excellent usability. I documented everything in a final report that tied back to research findings, design rationale, and next steps.

Research & Ideation

Stakeholder Analysis

User Research

Research & Ideation

Paper Prototyping

Sketching

Task-Flow Testing

Functional Prototype

Wireframing

Interaction Design

Usability Testing

Final Product / High-Fidelity Version

High-Fidelity Design

Validation Testing

Final Report

Research & Discovery

To design an accessible banking kiosk, I started by understanding the needs of all potential users, especially those with varying abilities. I reviewed existing kiosk systems, accessibility guidelines, and user complaints to identify key pain points. I then conducted interviews with both stakeholders and users who rely on accessibility features to uncover challenges that might not be obvious from existing documentation.

This stage also involved mapping the current user journeys to pinpoint friction points and barriers, such as confusing navigation, low-contrast visuals, or non-intuitive touch interactions. Insights from this research informed the accessibility requirements and set the foundation for designing an inclusive and user-friendly kiosk experience.

Key Activities:

  • Stakeholder discussions to understand business and operational requirements

  • User interviews with accessibility-focused participants

  • Accessibility audit of existing kiosks

  • Mapping user journeys and identifying pain points

Stakeholder Analysis

In the TD Bank project, I conducted a comprehensive stakeholder analysis to ensure the successful design and implementation of an accessible queueing system. This analysis involved identifying key stakeholders, understanding their needs and expectations, and assessing their influence and importance to the project. The primary stakeholders included TD Canada Trust, users (customers), the engineering design team, competing banks, government regulatory bodies, and other functional departments like marketing and HR.

By identifying each stakeholder's specific needs, ranging from accessibility requirements and system integration to legal compliance, I evaluated the potential impacts of these needs on the project. This allowed me to prioritise design elements that enhanced customer satisfaction, ensured compliance with accessibility laws, and provided TD Bank with a competitive advantage in the market. Through careful stakeholder analysis, I aligned the project's objectives with both business goals and user-centric needs, ensuring successful system deployment.

Stakeholder

Needs/Requirements

Impact

Estimated Influence

Estimated Significance

TD Canada Trust

Seamless queuing system, Addresses visible & invisible disabilities, Low complexity & economic feasibility, 100% task completion rate when tested

Improves accessibility of queuing service, increases customer satisfaction and retention rates

Medium – Broad sense of requirements, but few specifics

High – Provides resources and guidelines that the project must follow

Users

A system that accommodates accessibility needs, reduces barriers, and works on personal technology platforms

Improves day-to-day banking experience, increases overall contentment and satisfaction

High – Built directly for users

High – Success depends on the user’s ability to complete the required tasks

Engineering Design Team

Design based on TD’s requirements, uphold ethical & responsible design principles

Creates potential prototypes for future reference, Acts as a paradigm for banking systems

Low/Medium – Requirements are client-dependent

High – The Entire system is reliant on their work

Competing Banks

N/A

Shows other banks an accessible design, could create competition

Low – Irrelevant to design

Low – Not relevant to this project

Government

Upholds the Canadian Charter of Rights, Adheres to federal & provincial legislation, including accessibility

Must follow legal guidelines

Medium – Directly impacted by legal guidelines

Low – Only relevant if the system violates laws

Other Departments (Marketing, HR, etc.)

Non-complex system, Access to back-end interface for customer & employee concerns

Must be intuitive for employee use, supports training

Medium – Must be intuitive

Medium – Success depends on employee use

Mapping the Journey

After research, I mapped out he user journey to help pinpoint moments where users encounter problems or friction. By understanding these touchpoints, we can address pain points, enhance the overall experience, and ensure a smoother, more intuitive interaction for the user.

Design

Each screen and interaction in the final product was informed by the report’s findings. For example, earlier prototypes revealed that users often missed hidden actions, so in the final version, all primary actions are visible and always enabled in context. Touch targets were increased to at least 44×44 px, contrast ratios were certified, and focus order was logical and predictable.

Results

In the end, we delivered a high-fidelity prototype that integrated improvements based on feedback from the previous round of testing.

  • Developed in Figma, this prototype is fully interactive, simulating the final product experience for users. Key accessibility features, such as specific colour schemes and automatic interactions, were implemented in this iteration.

  • Usability testing was conducted with varied groups, including individuals with visual and motor disabilities, to ensure inclusivity. Participants were tasked with completing specific actions on the prototype without assistance, achieving a 100% completion rate. Using the System Usability Scale (SUS), we assessed the ease of use and learnability of the interface.

  • The prototype received an average SUS score of 82.9, equivalent to an 'A' grade, indicating excellent usability with no significant issues reported by participants.

100%

Task completion score

100%

Task completion score

82.9

System Usability Score

Challenges & Lessons Learned

Collaboration across disciplines was vital and sometimes messy. Remote constraints made building a physical kiosk prototype challenging, and COVID restrictions limited in-person testing with users who have disabilities. Our timeline for outreach was short, making recruiting participants harder than expected.

On the technical side, integrating card-based inputs, asynchronous queuing logic, and offline fallback modes required frequent alignment sessions with engineers. Some early design patterns needed rework after technical constraints became clearer.

Nonetheless, the project reinforced a core lesson: accessibility leads to better design for all users. We also learned the importance of keeping prototypes realistic enough to test real constraints, while staying flexible to pivot based on feedback.

Next Steps

We’ve documented the path forward based on both research and feasibility. Next, we plan to:

  • Add keyboard navigation support via proper tab indexing

  • Implement screen reader compatibility with ARIA labels and announcement contexts

  • Ensure alternative text for every icon and image

  • Test across assistive technologies (screen readers, voice control, keyboard-only browsing)

  • Extend the design to the employee interface, with role-based access to queue management, customer matching, and no-show handling

  • Introduce analytics dashboards tracking usage patterns, error frequency, and accessibility events

  • Pilot a live deployment in a branch to gather real-world validation