WorkNumber 02Capital Group

Making trade history readable at a glance

A trade operations tool that replaced downloading and reading text files with visual indicators, so specialists can see what happened to a trade and whether it needs them.

Role: Product strategy, research, wireframing, prototyping, delivery and UAT
Through: Wongdoody
Platform: Desktop web, internal tool
Users: Trade operations specialists

A table of trade reversals above a panel listing every version of the selected allocation

The problem

Banks execute stock trades through the clearing house, and when a trade needs attention an alert lands with the operations team. To find out what an alert was for, a specialist had to download a text document and filter through it by hand.

These are people who process large volumes of transactions and cannot afford a tool that interrupts them. The history of a single trade can run to several versions, reversals and corrections, and all of it was locked in text.

What I did

I interviewed the business users, mapped every cancel and correct scenario the system could produce, designed a visual language for a trade's state and history, and tested it with the people who do the work, through to user acceptance testing.

The outcome was a redesigned verification experience in which status and history are visible in the table itself, with a stable panel for the detail, and no text file to download.

Mapping every scenario first

A cancel-correct can be simple or it can branch: a correction arrives before the first reversal is acknowledged, a straight cancel follows a correction, and so on. Before designing a row I needed to know every state a row could be in.

I gave each distinct workflow a letter and each step in it a number, so A1, A2 and A3 are the three steps of scenario A. Complex scenarios branch off simple ones, and some share a starting point. The map gave the team one reference for every state, and each scenario linked to a page showing its rows step by step.

Diagram of lettered scenarios branching from shared starting points, grouped as pre-PNR and post-PNR, with a legend of user interaction points — The scenario map: eleven scenarios, their steps, and the three points where a user has to act.

A scenario walked through in four steps, showing how the table rows change at each one — One scenario, step by step, showing exactly how the rows change.

Key decisions

Decision

Encode a record's place in its chain as a mark

A small set of icons says where a record sits: the latest version or a superseded one, part of a reversal chain or not, acknowledged or still waiting. Unacknowledged reversals are marked in red.

Trade-off. New iconography has to be learned. We kept the set small, built it on Capital Group's existing design standards, and documented it as a key.

Legend explaining each version and reversal icon, and the not selected, hover and selected states of a table row — The key to the version and reversal marks, with row states.

Decision

Flag history with a folder

Rows with historical activity carry a folder indicator, so a specialist can go straight to the records that need a closer look and skip the ones that don't.

Decision

A dedicated panel, not expandable rows

An earlier design expanded a row in place to show its history. User testing showed that this disrupted the table people were working in. Moving history into a fixed panel under the table gave every record the same predictable layout, however long its history.

Trade-off. The panel takes vertical space from the table. In return the table never moves under the user.

The corrections view: a table of reversals above a panel listing every version of the selected allocation, with alerts and comments below — The corrections view. Selecting a row fills the Allocation Versions panel beneath it.

Tested with the people who do the work

Business users were in the loop for each round, and that continued through user acceptance testing. The expandable-row problem was found this way, before development, when it was still cheap to change.

The trades table with status, match status and indicator columns across dozens of rows — The trades table. Status and history are readable without leaving it.

Outcome

Cancelled, corrected and historical trades are identifiable in the table, without downloading or reading text documents.
Records that need investigation are flagged, so attention goes where it is needed.
One consistent layout handles both simple and complex scenarios.

What I took from this project is the value of enumerating every state before designing for any of them. The scenario map is the artifact I would make again first.