FX Options Risk UI
A clean, extensible app for a complex, evolving domain
Background
The Options desk at a French investment bank were part way through replacing their key risk system, but the UI was a sticking point. The new front end had been rejected by the traders as overly complex and unintuitive.
I took on the task of designing a replacement UI. The result was a clean, customisable application which provided an extensible framework for ongoing development.
Initial design
The first step was to understand the trader workflows and the system tech stack. From this foundation we delivered a proof of concept (PoC) design focussed on a single metric - Delta. This was well received and established the ongoing direction for the UI.
Core concepts
The system was based on the concepts of Reports and Views. A report defined which metrics to calculate, and could be run on demand or scheduled. Views were then used to query the results and display them in a grid.
When running a report, the UI abstracted away the complexity of the underlying calculation engine, only exposing non-standard settings when specifically required.
Keeping it lean
The primary job of the app was to display risk data, typically in multiple windows simultaneously. To support this, the app was hosted in a workspace platform which allowed users to arrange/snap/group windows as needed, and switch and share layouts throughout the day.
With multiple app windows open at once, the UI had to be as lean as possible: maximum space for the grid, minimum space for everything else. We therefore adopted a browser-like experience with minimal ‘chrome’ (tools and controls) around the edges, and maximum screen real estate for the data grid. Headings and reference data launched further controls, providing both context and an intuitive trigger for related actions.
Extensibility
From the outset, the options desk wanted the ability to model new risk scenarios as often as they liked. To achieve this, we designed a View Editor which allowed advanced users to create, edit and manage Views. It was essentially a mini IDE hosting an SQL-like instruction set, backed up by integrated docs and run-time debugging. Additional controls allowed the View aggregation, sorting, etc. to be configured. Once designed, Views could be shared or published across the platform for other users to work with.
Conclusion
This was a complex project with many moving parts and demanding stakeholders, requiring a high level of collaboration and inventiveness. After some initial teething troubles, the platform was quickly adopted and has continued to evolve.