TD Bank: Accessible Queueing Kiosk
To improve the customer experience at locations across North America, TD Bank sought out an accessible design that would efficiently queue customers, having persons with disabilities (PWD) at the forefront. Over the course of 8 months, I worked with a team of 2 designers and 3 engineers to create an accessible kiosk interface to meet those needs.
Role
Team Lead, UX/UI Designer, User Researcher
Client
TD Bank
Timeframe
8 months
Tools
Figma, Miro, Balsamiq
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