Foundation
Crafting design guidelines and establishing shared design language
Defining the problem space
Understand
Background & context on the problem space
Defining the problem space
Define & Ideate
Translating business requirements into design opportunities
Defining the problem space
Transaction Search
Business Requirements
"All users of the RTR C&S User Interface with appropriate permissions will have the ability to perform a transaction search by providing a combination of search criteria.
Upon performing a 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 the defined business requirements for Transaction Search, specifically the need for permission-based access, multi-criteria filtering, a fixed historical window, and read-only results - I formed a set of early design hypotheses to guide low-fidelity exploration. These hypotheses focused on how the experience could support efficient, accurate retrieval of transaction data while reducing cognitive load in a highly constrained, rules-driven system.
Notifications Configuration
Business Requirements
"Email notifications will be delivered through a list of provided email addresses and will be managed at the Organization level.
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. There are no validations on the provided emails."
The business requirements for Notifications Configuration established clear constraints: notifications are managed at the Organization level, delivered via email, and limited to a maximum of 10 addresses per list, with no validation enforced on input. While the rules defined system behavior, the interaction model for managing and maintaining these lists was open to interpretation.
System Notification Messages
Business Requirements
"The RTR C&S Application will have the ability to identify when new system notification messages are available to an authenticated logged in user.
Any user who is authorized to access notifications, will be able to view the count of unread notifications related to their individual inbox on the RTR C&S UI. 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:
● view unread and read notifications received in a list view, that will be ordered from the latest notification to the oldest
● view a notification’s content
● select a notification to delete it from the list
● select a notification to mark as read or unread"
The business requirements for System Notification Messages defined a comprehensive notification model, including unread counts, individual inboxes, read and unread states, deletion, and detailed message views. 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.
Design & Iterate
Continuously refining design decisions
Defining the problem space
Transaction Search
Transaction Search enables users to retrieve transactions by applying a combination of criteria such as date, time, amount, status, and transaction identifiers. Early design exploration centred on a single-step flow in which users selected a transaction identifier type and then completed all applicable search fields at once.
During review, our initial design surfaced challenges related to the varying rules and conditionality associated with different transaction identifier types. This design implied that field labels, validations, and error states needed to change dynamically based on user selection, which increases both implementation complexity and cognitive load. This insight prompted a re-evaluation of the interaction model to better balance usability, predictability, and system constraints.
Based on discussions with target users and the development team, the search flow was restructured into a guided, two-step experience
Users first select a transaction search option, after which only the criteria relevant to that option are displayed
This approach reduces conditional complexity in the interface and minimizes dynamic field and validation changes, establishing a clearer mental model for transaction search while balancing business rules with usability and implementation constraints
Notifications Configuration
Our subsequent iteration organized notification event types within an accordion layout, allowing individual email addresses and usernames to be edited or removed per notification event
This approach increased flexibility and clarity across notification configurations. However, it introduced vertical scalability issues, requiring excessive scrolling to reach event types positioned further down the page
The final iteration presented notification event types as a selectable list, with configurations for the selected event type displayed dynamically in a dedicated detail panel to the right of the screen
This layout conserved screen real estate while allowing all configured emails and usernames to be reviewed at a glance. It also enabled quick switching between event types, along with efficient editing and deletion of recipients
System Notification Messages
A subsequent iteration introduced a dedicated notifications page, with a master–detail layout allowing users to select a message and view its content alongside the list
This approach improved clarity and supported common message-level actions. However, the typically short length of system-generated messages resulted in excessive unused space within the detail view
Our following iteration expanded the notifications view to full width, allowing message rows to auto-scale and display the full content of messages without additional interactions
This eliminated the need to open or expand individual notifications. However, separating notifications into multiple tables by type increased cognitive load and required more scanning and scrolling
The third iteration explored a tabbed table layout, enabling users to switch between notification types within a single, consolidated view
This approach improved efficiency by reducing the amount of scanning involved. However, discussions with the development team revealed that the added scope would make this design infeasible to be implemented within the project’s delivery timelines
Our final iteration consolidated notifications into a single table, with message types clearly distinguished through a combination of icons and text labels. The required primary actions - 'Delete', 'Mark as read', and 'Mark as unread '- were all surfaced as prominent buttons instead of text links to improve visibility and ease of interaction
This approach balanced clarity, efficiency, and implementation feasibility within the project’s constraints
