FX Sales Trader

Overview

Designing a new Caplin product from scratch to delivery a year later.

Problem statement

FX sales traders act as a middleman for the bank and its customers. They make trades on behalf of the customers with the bank, to manage risk and make money for their desk a margin is added to prices quoted to the customers. Traditionally this margin is added on manually either by keying in a price or mentally adding to the price they see on their systems. This method is error prone and does not give the customers a consistent price. Caplin decided to build a product to solve this problem.

Users and audience

The end users of the product are  FX Sales Traders. They work in an fast paced environment, spending a large part of the day on the phone with customers and traders. The time from picking up the phone to executing a deal is often less than a minuet. They normally have between 3 and 6 screens with different software packages open at the same time.

Team and my role

Caplin use agile project management to build products. Although it evolved over the course of the project the core team consisted of:

  • A Product owner
  • 4-12 developers
  • A UX designer, (me)

At the early stages of the project I followed the lead of the product owner to develop the strategy and scope. As the project progressed I worked in agile sprints to produce wire-frames, prototypes, a visual design language, high fidelity screens and pixel perfect spec documentation. 

Constraints

Without direct access to the end users extra diligence was needed to adhere to best practices and to work closely with those who did have access (sales team and product owners). Agile is brilliant at building software, but it can stifle design. It is challenging to focus on small portions of a big picture to meed sprint deadlines.

Design process

The Strategy for the project had been forming slowly over the past few years among Caplin's product owners and sales teams. The Project started with Story Mapping to define the scope.

User Research started by interviewing and doing workshops with subject matter experts. Secondary research on trading floor life provided insight into the emotional side of the environment.

Design research looked into competitor products and existing systems and workarounds that currently solve the problems.

The MVP consisted of being able to complete a Spot trade, so this workflow was sketched out countless times and reviewed with anyone who had spent time with FX sales traders. The project timeline focused on features and each was addressed in turn according to the roadmap. Below I have picked out key elements as examples.

The margin indicator

There where already some concept designs done for this portion which showed a bar representing the margin. The flaw in this data visualisation was that no one had done the maths to get a realistic idea of how large it would be at different market conditions. Although it was a single bar, I considered it a chart and every chart needs a scale. The key to making the visualisation work was setting the scale to be "0 to Set margin * 2". This places the bar in the middle of the chart initially and gives enough room to move closer or further away.

Search

The first step in the users workflow is to identify the client they are talking to and bring them up in the system ready to make trades on their behalf. As the exact data structure of a deployed system could not be known, I wanted to make the search interaction flexible enough to accommodate multiple hierarchies of data.

The search interaction was a project in itself and i have detailed the design process separately.

Trade Ticket

When designing the ticket I went to the most complex type of trade first to ensure all the features could be accommodated. The more simple trade types would be a case of taking away rather than starting again. The ticket started as an Excel document that I adapted from a reference document made by a subject matter expert that was used to check prices in another Caplin product. I changed the layout to represent the bid and ask prices fanning out left and right from the center.

I made wireframes in InDesign at first as it deals with tables well. After the design became more robust from several iterations I moved to Photoshop to make high fidelity visuals.

Earlier in the project the trade ticket had three modes:

  1. Setup (from fields)
  2. Unlocked
  3. Locked

Setup mode was made up of from fields to input the trade details quickly. Unlocked was a higher risk mode to execute in as any quoted price may change before it can be executed. Locked mode solves this problem by locking a price and allowing the margin to move to accommodate the change in the underlying trader price. The locked and unlocked modes worked on the assumption of a real-time streaming price. Later the design was reworked to accommodate a single RFQ (Request For Quote) which essentially combined the locked and unlocked modes. This was catering to the specific needs of a single client but it proved the design was flexible enough to accommodate change.

 

Retrospective & lessons learned

Wireframes in Financial services

The numbers matter when presenting financial services designs. This is a bitter pill to swallow for most designers as they can make leaps of imagination to see them as always adding up. End users and stakeholders however, will spot a mathematical error from a mile off. Once an error is spotted, it will derail a presentation and devalue everything shown. Get comfortable with Excel, sit with some one who knows what they are doing and ask them to prototype a portion of a financial application, I guarantee you will be impressed.

Hi-Fi to early

Moving to high fidelity too soon makes it very difficult to have the right conversations about the design. I found myself too often defending a visual design when I wanted to talk about a functional or interaction change. Because of this the project eventually got to a point where it was hard to fix issues that had emerged from agile iterations. 

To solve this I addressed the issues outside the agile process as a separate project.