Denied Party Screening
How might we give customers a way to be clearly notified when their contacts have been flagged?
Roles & Responsibilities
UX Designer, user research, prototyping
Duration
Jun 2023 - Jul 2024
The Problem
Our product managers for Global Trade and Transportation identified a deficiency in our current product. The individuals with whom our customers interact for their business may be included in official Government lists of unauthorized or denied parties, and it is crucial for our customers to be promptly if any of their business associates appear on these lists.
The Solution
Our Denied Party Screening app enables customers to handle their contacts, view any flagged, and take appropriate action by either allowlisting or denylisting them.
Understanding the User
I had a conversation with Michael, our Sales representative and subject matter expert on the Denied Party Screening product, to gain insights into the customers' requirements. During the interview, I delved deeper into the functionalities that the application should possess.
Defining the Problem
Michael and I worked through a red routes exercise to comprehend the daily tasks that it would have to accommodate.
Brainstorming
After my conversations with Michael I was able to get a scope for what the application would be. It was doing double duty:
-
A Contacts application for adding, editing, and maintaining shipping and business contacts
-
A screening application which would scan Government Denied Party lists for any matches with the customers Contacts list
The most important part of the application was the screening feature so I needed to understand what the user would do after a contact had been flagged.
​
It turned out there was really only two actions that a user would need to take.
​
Either that Flagged contact was one that should not be allowed to do business with the customer, in which case they would need to be placed on a Denylist.
​
However in some cases, the Flagged contact, either through error or variations in local laws, could still be allowed to interact with the customer's business. In these cases the contact would be added to an Allowlist.
Lo-Fi Prototypes
The initial prototypes laid out the basics of the Application:
-
A large table grid of Contacts data
-
The navigation where the Company's contacts can be found as well as the Government Lists
-
A Form for editing
-
Some possible solutions for notifying users of the Flagged matches
-
A highly visible inbox notification​
-
A complete filtering of the Contacts list that shows the Flagged matches highlighted
-
Hi Fi Prototypes
The final solution was relatively straightforward.
​
The main focus of the application is the Contacts screen where users can view all Contacts, including any that have been previously flagged and Allow or Denylisted and the date.
The primary left hand navigation panel shows the lists sorted, with the customers lists grouped separately from the Government Denied Party Lists
The primary contacts list can be filtered to show only the Allowlisted, Denylisted, or Flagged contacts
The feedback from the subject matter experts was clear that the new Flagged matches should be immediately noticeable and very visible. So a button was added at the top of the screen. Clicking the button changes the Filter List to the Flagged view.
Here we can see the Flagged contacts view. These contacts are highlighted so as to give visible warning that action is needed.
Clicking on the contact takes the user to the maintenance form where they can review the contact, analyse the Government lists that the contact matched to, and choose to Allow or Denylist the contact.
