Logic Builder
the problem
FactSet’s Order Management System (OMS) for institutional asset management has a complex system for the creation and management of compliance rules. This system is used to limit exposure, trading, and more so users can focus on their jobs, instead of what securities they can hold. The user thinks of these rules as logical statements, e.g. “A > B AND C <= D”, which can get complex as the number of conditions increase.
OMS’s current tool used a large table and indentation to show logic relations. Adding to this was only available on right click or hovering on the left side of the row border.
By speaking with team members in UX, I found multiple product teams were struggling with similar problems. I looked across all our current UX work and at least five teams needed this functionality. I looked deeper and found we had three user types:
Compliance & Middle Office staff - In addition to OMS, FactSet Execution Management System (EMS) needed this for a “Smart Trading Assistant” to automatically execute trades.
Data Analysts & Research Analysts - Concordence Data Feed users had a need to refine and extract particular data points from large data sets.
Research Analysts - A new unified Screening app needed a “advance filter” that allowed users to combine multiple conditions with “AND” and “OR” logic.
The breakdown
I needed to validate that users were interested in a logic builder and didn’t want an “Excel-like” formula editor. FactSet users generally have high usage of Excel, so this would determine the correct direction. I also needed to find out the level of complexity users required.
Other apps have used granular formula editors to allow users full control over building logic, conditions, and math. Users were not interested in typing at this level of detail.
I worked with our UX Research team to set up a study with users of our current apps to validation our assumptions. We sent a survey and scheduled 12 people for 30 minute interviews.
Where these the correct people to target? If not, who did this work?
Do they call a help desk to have a FactSet employee do this for them?
How would they approach building a rule?
Our findings showed us several insights:
Users rejected the idea of an Excel formula builder. When shown a logic builder for another app, users complained about complexity and readability.
Currently, the OMS & EMS logic builders are handled almost 100% by client relationship manager or help desk. When asked why:
OMS - the UI is just a table, hard to understand the logic, where to edit/add.
EMS - you have to know Java code validate your rule and the output.
Users repeatedly told us their mental model which was demonstrated by speaking aloud, “Price is greater than 50 and daily volume is less than 10M or the price crosses a 50-day moving average”. This confirmed our assumptions about their mental model.
Sketching out the flow revealed a sticking point, which was the addition of parenthesis and operation order. We called this concept “groups” internally.
The issue I kept revisiting was how to control the order of operations.
The solution
I looked to find other implementations of a similar pattern and paired up with a visual designer to work together on some designs. Ultimately, the visual designer and I settled on an approach that needed several things that weren’t covered in other patterns or originally requirements:
The user had to be able to add a nested group implicitly. We didn’t want to have a concept of ‘add a group’ if we could help it. This was going to cut down UI components and now saddle the user with adding/removing parenthesis.
The user had to be able to insert conditions, not just add them to the “bottom” of the list of conditions so users could edit conditions without rewriting them.
We needed to strongly communicate the relationship between logical conditions so users could understand how conditions evaluated relative to one another.
This needed to be accessible for users who don’t use a mouse.
results
We designed with five major iterations, which are detailed below: We tested each with ~10 users in an unmoderated study with a simple task to create a rule that got more complex as the task went on each time. Each round revealed opportunities to improve the user experience.
The first design didn’t effectively communicate the relationship between items. Users got lost after going one level down. Users also found the implicit movement from AND to OR confusing.
The second design was inspired by an implementation EMS engineers had started without UX. These were unreadable to users because it reversed the mental model users had. Research backed up our assumptions, but as this was partially built it was tested again.
The third design was an attempt to show connection between the groups and elements within them. We found we had too many controls and when rules got more complex, the user had a lot of cognitive load to complete subsequent tasks, like adding or editing existing conditions. .
The fourth design has the best results when adding conditions early on. Users needed stronger communication of the relationship and fewer interactive elements. There was confusion over buttons and logical groups as the user added to the rule.
The fifth design leveraged a more visual hierarchy to clearly define how the conditions were related. Buttons were moved to be an explicit part of the conditions and groups. Preview logic was moved to the top and no longer optional. Users clearly understood relationships, moving between groups, and inserting into groups. Greater than 80% were able to complete all tasks while ranking “ease of use” 6.7/7. You can see the Figma prototype here to experience the process.
This has been built as part of our Fusion library and we now have one component for five apps. FactSet engineering resources are saved to focus on customer delivery, instead of creating multiple logic builders. We’ve saved at least four months of engineering work by centralizing this as part of the design system. Teams can also contribute to this one pattern as it is part of our design system. Relative rules are already in the team’s backlog for new features.
Lessons Learned
I would have involved engineers from UI Standards and all the potential Product teams earlier. There was a game of organizational hot potato on who was going to build this that wasted time. Had more teams been involved earlier, I think it would have been easier to sort out who was responsible for writing the code.
Require better requirements. OMS showed us their old system for creation these rules, but no Product team ever gave us detailed user stories, acceptance criteria. We’d find out new and different criteria as we tested and got feedback from internal stakeholders. I would have pushed back on this much more if I could do it all over again.
Accessibility earlier. We originally designed with less focus on accessibility. This was more difficult than designing layers of functionality based on a 100% accessible experience at the core and implementing “accelerators” for abled users. We came full circle with review/edit modes but it was afterwork instead of built into our process.