Foundation
Crafting design guidelines and establishing shared design language
DESIGN SYSTEMS
Building a scalable foundation from the ground up.
Payments Canada lacked a centralized design system for the Real-Time Rail platform, creating risk for inconsistency and implementation inefficiency. I led the creation of a foundational design library, grounding it in existing patterns from adjacent platforms while adapting them for a real-time, data-intensive product.
I established reusable standards across core components, creating a shared source of truth for design and engineering. This not only supported parallel development, but also helped reduce ambiguity during build.
Understand
Background & context on the problem space
Defining the problem space
THE CHALLENGE
Designing a real-time payments platform with no precedent.
The RTR platform was built within a tightly constrained enterprise environment - fixed timelines, pre-defined requirements, and a non-traditional, documentation-led discovery approach. While requirements outlined what the system should do, they left significant ambiguity in how complex clearing and settlement processes should be presented.
How might we translate abstract, system-level requirements into clear, scalable interfaces, with little precedent for real-time payment systems at a national level?
Define & Ideate
Translating business requirements into design opportunities
Defining the problem space
In the absence of a traditional research phase, I formed early design hypotheses through cross-functional discussions with business analysts and engineers, grounded in business requirements and system constraints.
I established my design decisions around key design principles such as clarity, scalability, and usability, which served as a foundation for early exploration and alignment.
Transaction Search
Business Requirements.
'Upon performing a transaction search…
the RTR C&S UI will show historical transaction information from the past 40 days (configurable, up to the configuration of transaction retention in the RTR C&S UI). The nature in which search results are returned is not customizable and results are read-only. The search will return all applicable transactions based on criteria provided, to be viewed based on UI design.
Based on requirements for Transaction Search - permission-based access, multi-criteria filtering, a fixed historical window, and read-only results, I formed early design hypotheses to guide low-fidelity exploration. These focused on enabling efficient, accurate data retrieval while minimizing cognitive load within a highly constrained system.
HYPOTHESIS 01
Search Criteria
If search criteria are grouped and structured by intent (time, amount, participants, and status), users will be less likely to be overwhelmed by input complexity
HYPOTHESIS 02
Results Table
If results are displayed in a structured, scannable, read-only table, users can quickly review and compare transactions with minimal friction
HYPOTHESIS 03
Expandable Table Rows
If rows can expand inline to reveal additional details, users can access deeper transaction information without losing context or leaving the results view
Notifications Configuration
Business Requirements.
'An Organization will be able to identify up to 10 email addresses…
which should receive email notifications, for each notification relevant to the Organization, through the RTR C&S UI. Organizations will have the ability to add or remove email addresses for each list of up to 10 emails.
While these business requirements defined the system behaviour of the notifications configuration feature, the interaction model for managing and maintaining these recipient lists was open to interpretation.
HYPOTHESIS 01
Progressive Addition of Recipients
If additional email fields are revealed progressively as users add recipients, the interface can stay lightweight for organizations with only 1-2 contacts while remaining scalable
HYPOTHESIS 02
Efficient Review and Maintenance
If recipients are presented in a single, scannable list, users can more easily manage and update configurations over time, rather than clicking into different states or steps to understand who’s included
System Notification Messages
Business Requirements.
'SNM inboxes will be on an individual basis…
sent to each user’s respective inbox to read and manage. The user will have the ability, within their view for notifications:
● to view unread and read notifications received in a list view, ordered from the latest notification to the oldest
● to select a notification to delete it from the list, mark as read or unread
During early ideation, I focused specifically on the notification preview experience - how users become aware of new system events and quickly assess their relevance, while intentionally deferring full inbox management to a dedicated, more detailed view.
HYPOTHESIS 01
Notifications Preview
If notifications appear in a lightweight, expandable preview ordered by recency, users can quickly assess relevance and urgency of the messages without leaving their current task
HYPOTHESIS 02
Scoping
If the preview experience is scoped to awareness and triage, and more advanced actions are deferred to a dedicated view, the system can better balance immediacy with control
HYPOTHESIS 03
Notification Display
If unread notification counts are clearly surfaced within the global navigation, users can immediately recognize when new messages require their attention without actively checking a separate inbox
Design & Iterate
Continuously refining design decisions
Defining the problem space
With clear design hypotheses established across features, I focused on refining interactions through ongoing exploration and collaboration. Designs were continuously evaluated against usability, scalability, and implementation constraints through regular discussions with engineering and bank stakeholders.
Transaction Search
BEGIN BROAD. REFINE TO EXACT.
Finding a transaction starts with a simple choice: search by a known identifier or explore by date. From there, users can narrow their results using filters like amount, status, and participants - making it easy to move from broad search to exact match.
PRE-ITERATION
Single-step transaction search
We began with a single-step experience where users selected a transaction identifier and filled in all search fields at once As we explored further, varying rules and conditionality across identifier types made the experience less predictable - leading us to shift toward a more guided and flexible approach.
POST-ITERATION
A guided, two-step search experience
Based on feedback from bank stakeholders, we restructured the experience into a simple, two-step flow - starting with selecting from one of three transaction search options, then showing only the criteria fields relevant to that choice. This creates a clearer, more predictable experience while reducing complexity behind the scenes.
Notifications Configuration
TARGETED NOTIFICATIONS, SIMPLIFIED.
Managing notifications starts with choosing which events matter. From there, administrators can assign who gets notified - ensuring the right people receive the right updates, at the right time.
PRE-ITERATION
Single-field notification setup
We explored variations of a compact, pill-based input that allowed multiple email addresses to be added in one place. While efficient for simple entry, it didn’t scale to support different event types or notification channels - a requirement identified from subsequent stakeholder discussions. This led us to rethink how the configurations should be structured.
POST-ITERATION
Organized by event, designed for scale
We restructured notifications into a two-pane layout - selecting an event type on the left, with its configuration shown on the right. This keeps everything in context, making it easy to review, switch, and manage recipients while staying organized and scalable.
System Notification Messages (SNM)
CENTRALIZED NOTIFICATION VISIBILITY.
The SNM view bring together all system messages - grouped by type and status - so users can quickly scan what’s new, understand what matters, and take action when needed.
PRE-ITERATION
Notifications within the flow
We began by exploring a right-side panel that kept notifications within the context of ongoing tasks. While convenient, the limited space made key actions harder to access and relied heavily on icons to communicate message types - reducing clarity and ease of use.
POST-ITERATION
Bringing clarity and action into one place
We expanded notifications into a full-width, structured table, which allows messages to auto-scale and be viewed in full without extra interaction. Clear labels and icons distinguish message types, while primary actions are elevated to buttons. Together, these create a more efficient and intuitive way to scan, prioritize, and take action on notifications.
