Compliance Manager
the problem
As part of an acquisition of an order management system (OMS), FactSet wanted to build out a standalone compliance manager to be used across all FactSet applications. However, the current compliance manager was very difficult to use: Creating compliance rules was cumbersome with no systematic help and other settings were exposed in a series of database tables without any informational structure. Current users in the OMS rely 100% on support staff to configure and adjust their compliance system.
The original layout uses large forms, no information architecture, and locks the user into all activities around a singular compliance rule.
Accounts had to be attached to a rule. This forces users to add individual accounts to multiple rules and view accounts only through rules.
Other parts of the application used outdated tables styles and crowded, cascading dialog boxes for creation and editing.
The breakdown
We knew our user was going to be a compliance officer at a mid-to-large asset manager. However, we didn’t have their mental model to validate our concerns. We spent some time with a handful of users and a UX Researcher over the course of two weeks. Users very clearly approached their compliance system in two ways:
Rules first - The main interaction point is a rule that has accounts mapped to it and rule settings.
Accounts first - The main interaction point is an account, that has rules mapped to it.
Because of this pattern, my approach to allow the user interaction with both items (as required) but to allow them to transverse both workflows when needed. We also found out that users generally applied rules to the same groups of accounts, so we decided to build out list groups.
I spent time with the product team and our UX Researcher to map out the information architecture as our users had communicated their needs to us. I did this in Figma and broke it down into two sections: The requirements that relate to a rule or account and all other requirements.
One section was broken down to show all the parts that relates to a singular rule.
All other parts that touched a rule were mapped and related with their properties and required actions.
Other parts of the application were mapped as well, but held in a parking lot to be analyzed or handled later.
The solution
After mapping out the structure, it was relatively easy to find a way to build the workflow into a grid-based system. The approach was to allow the user access to other pieces of the system at key points in their workflow. We also allowed the experience to be approached from rules->accounts or accounts->rules.
I created a navigable approach, but started the user in the “Rule Manager” view. Rule changes that need approval are displayed in a collapsible header section.
We exposed particular options of a rule, those that were changed most frequently, in an “inspector” panel.
results
After showing our mockups to stakeholders, I wanted to build our a prototype in Figma that could validate our design decisions. We took this prototype to four existing clients of the OMS and interviewed 12 people on our designs. I was very happy to hear the feedback and positive validation of our approach. We did get some great feedback about even more improvements to our approach.
Users wanted to be able to add new attributes right in the rule-edit mode. This contradicted what product and SMEs told us about our client workflow.
Users need to upload and attach documents to rules, especially in our wizard.
Users didn’t only want lists of accounts, they also wanted ways to group/relate rules so they could have rule schemas to apply. For example, “EMEA Equity Rules” or “Dodd-Frank Rules”.
We are currently completing our initial build and designing new features based on the feedback we have and continue to receive. The first set of users will go live in January with our most recent iteration.
The accounts section was built and broken out into two tabs, so users could access accounts and account lists. This mirrors the settings in the rule panel.
Users could also jump to managing lists, their properties, and add members to the lists. They could also see associated rules in a second tab.
Alternatively, users could also access those lists in the rule itself. This view also allows the user to go to editing the main details of the rule that change less frequently.
Users can drill into a rule to edit various settings, logic for application, and more. We expanded changes to allow users to add new values to particular fields in line, rather than leaving the rule experience.
In this case, the user gets a modal drawer that allows them to create a new internal category for the rule they are editing.