Back

Markets Risk Platform - Improvements & AI Adoption

June 2026

Low fidelity UI design

To demonstrate improvements made after the initial launch of the application in order to continue the UX process iterations and reflect based on user feedback and usage analytics

To demonstrate improvements made after the initial launch of the application in order to continue the UX process iterations and reflect based on user feedback and usage analytics

Context

This project is a collection of improvements from the initial migration (legacy to next gen) project post roll out, done in the space of Q2 2025 - Q2 2026. Please note that due to confidentiality, I cannot share any low or high fidelity designs.


Problem Statement #1

Our Inbox application with 10k+ global users sometimes receive alerts and review items without understanding why they got them or what action is expected, especially for new joiners. Lacking in-context explanation, they leave the app to ask product support for clarification, which adds friction and avoidable support volume. Their questions are varied and context-dependent, so static help fails them.

Research Process

  • Analyzed data of the queries to the product support to see any trends and patterns as to which specific alerts/review items trigger need for clarification

  • Interviewed product support

  • Interviewed users who have sent in the queries

  • Write up jobs-to-be-done and How Might We statements

  • Drew up cost/effective analysis in having a static generic text vs. having a dynamic, context-based in-app support

Solution

  • Integrated an in-house AI tool to clearly display a short explanation as to why they are receiving this item

    • Explaining what the expectation is from them was avoided to make sure that we are not "leading" users exactly what to do, as some of the alerts were sensitive and need more human judgement

  • Integrated an AI chatbot as a secondary solution to help with more context-dependent questions that are specific to the asset class (i.e. business group) a user is in


Problem Statement #2

In the legacy application, viewing a trader’s profile and requesting amendments to it were split across disconnected pages; one page to view the profile, a separate page to edit it. This forced users to navigate back and forth and lose context between what they were looking at and what they were changing. While viewing a profile, users were also given a flat list of all the permissions the profile entailed with no visual hints or hierarchies, which meant that the users had to take on the cognitive load and calculations to understand the data.

Once an amendment request was submitted, there was no way to track its status, leaving users uncertain whether the request was sent, in progress, approved, or rejected. This created a confusing workflow with duplicated efforts, and a lack of confidence that requests were being actioned.

Research Process

  • Drew up a full user flow between a trigger point of user having to view/edit a profile all the way to having to actually create a request of amendment

  • Interviewed different user groups to find out their usages (e.g. admin user who makes changes vs. a regular user who only views the profiles)

  • Analyzed usage analytics of the legacy application to cross-check the interview statements vs. how users are utilizing the legacy view/write modes

  • Designed low-fidelity design and high-fidelity design, get user feedback, and iterate

Solution

  • Consolidated the trader profile viewing experience by

    • Hiding content that are redundant behind Collapsibles

    • Restructuring the data shown in a guided hierarchy (e.g. showing tree structure of related data instead of a flat list of items)

  • Streamlined the experience for requesting for amendments by integrating the ability to edit within the same page as viewing by enforcing a more granular permission level

  • Created the ability to track the requests sent, where the link to track also appears upon clicking submit as well as a space to track all requests raised by the user and their team members


Problem Statement #3

Some review items, due to the nature of them, are sent to users in another language other than English. Most of the times, the users don't speak the language so they have to mark those items as "Cannot Review", which was resulting in inefficiency, growing backlog of unresolved items, and increase in user frustration.

Research Process

  • Analyzed data of those that are marked as 'Cannot Review' and derive how much % of the entirety of review items are marked as such

  • Analyzed samples of the actual items alongside with the data aforementioned to understand the languages flagged, type of content, length, etc.

  • Interviewed Supervisors (users)

  • Designed low-fidelity design and high-fidelity design, get user feedback, and iterate

Solution

Added an auto-translate feature so that user is able to see all items in English and have the ability to turn off the feature if wanted (for those that do speak the original language and would prefer to review in the original language)

Context

This project is a collection of improvements from the initial migration (legacy to next gen) project post roll out, done in the space of Q2 2025 - Q2 2026. Please note that due to confidentiality, I cannot share any low or high fidelity designs.


Problem Statement #1

Our Inbox application with 10k+ global users sometimes receive alerts and review items without understanding why they got them or what action is expected, especially for new joiners. Lacking in-context explanation, they leave the app to ask product support for clarification, which adds friction and avoidable support volume. Their questions are varied and context-dependent, so static help fails them.

Research Process

  • Analyzed data of the queries to the product support to see any trends and patterns as to which specific alerts/review items trigger need for clarification

  • Interviewed product support

  • Interviewed users who have sent in the queries

  • Write up jobs-to-be-done and How Might We statements

  • Drew up cost/effective analysis in having a static generic text vs. having a dynamic, context-based in-app support

Solution

  • Integrated an in-house AI tool to clearly display a short explanation as to why they are receiving this item

    • Explaining what the expectation is from them was avoided to make sure that we are not "leading" users exactly what to do, as some of the alerts were sensitive and need more human judgement

  • Integrated an AI chatbot as a secondary solution to help with more context-dependent questions that are specific to the asset class (i.e. business group) a user is in


Problem Statement #2

In the legacy application, viewing a trader’s profile and requesting amendments to it were split across disconnected pages; one page to view the profile, a separate page to edit it. This forced users to navigate back and forth and lose context between what they were looking at and what they were changing. While viewing a profile, users were also given a flat list of all the permissions the profile entailed with no visual hints or hierarchies, which meant that the users had to take on the cognitive load and calculations to understand the data.

Once an amendment request was submitted, there was no way to track its status, leaving users uncertain whether the request was sent, in progress, approved, or rejected. This created a confusing workflow with duplicated efforts, and a lack of confidence that requests were being actioned.

Research Process

  • Drew up a full user flow between a trigger point of user having to view/edit a profile all the way to having to actually create a request of amendment

  • Interviewed different user groups to find out their usages (e.g. admin user who makes changes vs. a regular user who only views the profiles)

  • Analyzed usage analytics of the legacy application to cross-check the interview statements vs. how users are utilizing the legacy view/write modes

  • Designed low-fidelity design and high-fidelity design, get user feedback, and iterate

Solution

  • Consolidated the trader profile viewing experience by

    • Hiding content that are redundant behind Collapsibles

    • Restructuring the data shown in a guided hierarchy (e.g. showing tree structure of related data instead of a flat list of items)

  • Streamlined the experience for requesting for amendments by integrating the ability to edit within the same page as viewing by enforcing a more granular permission level

  • Created the ability to track the requests sent, where the link to track also appears upon clicking submit as well as a space to track all requests raised by the user and their team members


Problem Statement #3

Some review items, due to the nature of them, are sent to users in another language other than English. Most of the times, the users don't speak the language so they have to mark those items as "Cannot Review", which was resulting in inefficiency, growing backlog of unresolved items, and increase in user frustration.

Research Process

  • Analyzed data of those that are marked as 'Cannot Review' and derive how much % of the entirety of review items are marked as such

  • Analyzed samples of the actual items alongside with the data aforementioned to understand the languages flagged, type of content, length, etc.

  • Interviewed Supervisors (users)

  • Designed low-fidelity design and high-fidelity design, get user feedback, and iterate

Solution

Added an auto-translate feature so that user is able to see all items in English and have the ability to turn off the feature if wanted (for those that do speak the original language and would prefer to review in the original language)