Case Study 2 • 2018 - 2019

Order management

Role

Product design lead & design manager

Company

Goldman Sachs

Scope

API information architecture
Design strategy
Research
Interaction design
Visual design
Prototyping
Design library

Overview

Around 2018, I started to notice a trend of users looking to diversify trading strategies. The growth of the Fintech industry prompted user curiosity about products with which they were not familiar. The need for cross-asset, cross-product trading was a challenge for Goldman Sachs. Goldman Sachs operated its business by siloed product, which developed a deep-rooted, single product infrastructure. For instance, the FX trading team wouldn’t collaborate with Commodity, so these two teams didn’t share their technology or business development. As a result, Goldman Sachs created many duplicated workflows and backend systems that were not connected.

I kicked off a design initiative to create a cross-asset platform that operated a new user-driven, cross-asset API infrastructure; a scalable design library; and a design process that improved technology and design efficiency.

Problem

Siloed bank infrastructure blocked growth
‍
I identified and interviewed 30+ users who had the wants or needs to trade cross-assets. They had trouble doing so in the current platform since the platform was product-specific.

I mapped out their user journeys to understand which area was blocking the users. After speaking to engineers, I found out that the historical backend infrastructure, which was created by individual trading teams, was not set up in a cross-asset way. The siloed infrastructure became a constraint from further developing the fluent user experience.

Opportunity

From user journey mapping, all users go through the same workflow.

However, when users watch prices, components are different for products. FX users prefer to watch price in a tile vs commodity users prefer condensed grids. The taken action and monitored processes, however, could share the same components. The pain point was that users had to navigate to different systems and workflows across product lines if they traded cross-asset.

Objective

Create a consistent and unified order management system

1. Speedy order submission process
2. Easy lifecycle management
3. Platform consistency and business calability
4. Increase the development and design team productivity

Quick Sketch

Got green light from stakeholders

The goal was to create a unified order management system in order to scale the platform. I quickly put some sketches together to get the team aligned with the vision. The team was happy with the direction, and I was able to get the budget from stakeholders.

Challenge

Initial backend resistance and information architecture reconciliation

The engineering team was excited about the direction. They had been struggling with maintaining multiple systems and keeping the platform consistent. The challenge was that in order to make the platform truly cross-asset with a fluent user experience, the backend infrastructure needed to be re-organized and aligned with the unified information architecture.

Compromises

SecDB - Goldman Sachs current backend system built in 1993

Restructuring the backend would be nearly impossible since GS has been operating for over a century, and historic data was stored in this storage system called SecBD. The SecDB is tricky to change since the data sets are messy and the system is easy to break. I didn’t want to give up and have the backend become a blocker to scalability and growth. Engineers, PMs, and I decided to create a new API that contained the user-driven infrastructure that routed the backend data sets to the right information architecture.

Solution step 1

Create user driven API

I collaborated with the engineering team on the new API. The information architecture was the key, so we went through the dated SecDB backend system, multiple data sets, and touchpoints users needed to go through. In the end, I proposed a new architecture based on user workflow.

Groom through backend data sets with engineers

Cross asset naming convention

Result - smart cross asset API, fetching data based on user needs

Solution step 2

Order management design system

To cooperate with the new API, I created a design system for the order management system, which included order tickets and order blotters. The workflow was relatively simple: the user needs to take action on an order ticket and monitor the order ticket in the order blotter. The importance was the framework, which can be used for design and engineering guidance.

Order ticket design

01

Lifecycle

Order lifecycle shows the specific steps an order goes through.

02

Atomic design

The order blotter is where the users store order ticket information. Before stepping into the order blotter that is driven by order tickets, I decided to start with order ticket design using atomic design method as an underlying structure organization. This system served product designers, product managers, and engineers to provide easy to understand guidance around the best design and development practice for order tickets.

03

Order ticket structure

04

Mapping API information into order system

The order ticket contains the information, which goes through the API in route to the right backend system. Every ticket starts with pulling a unique id from API. The ticket content is driven by product, order type, and the stage of the orders.

Order blotter design

01

Grid library

I have created Library 1.0 at this point (you can view the process of developing Library 1.0 in Case study 1). This was a continual effort to create Library 2.0, which included order management components and patterns–created more variants and received order management API items.

Grid anatomy

Grids allow users to easily compare items, edit data, and take actions on single or multiple items within the grid and export data.

Grid behavior

Grid sizing

This section defines the default and minimum sizes for the grid windows and details the responsive behavior of the grid, depending on the window width and height.

02

Order blotter API mapping

Once the library was updated and ready to scale, I injected order blotter API information to test out Library 2.0.

Default columns - primary data

Primary data is necessary information for users to monitor order updates. It includes three categories: product identification, order content and order operation. Primary data is displayed by default.

Column management

Secondary columns - secondary data

Secondary data can provide users more details than primary data. It follows primary data’s three catagories. Secondary data is not showing by default, it can be triggered in column management.

Test and iteration

The order management design initiative drove the API creation and organizational changes. I wanted to make sure the team was following through the vision, so I put testing as the top priority, which ran weekly. The user feedback ensured the team was heading in the right direction.

The weekly testing focused on functionality development, API connections, and order management performance.
‍
The design and engineering team collaborated on a two-week sprint cycle so that design iteration and bug fixes could push out to users.

Order ticket iteration

Order blotter features added

Prioritization

While I was iterating on the features, the fundamental direction was ready for engineers to start their backend build and front end preparation. Here was how I worked with PM and engineers to prioritize our development:

During and post development, I kept testing the features and the production environment with traders.

Impact

1000+

New cross asset institutional accounts onboarded

3200

+ 40%

Cross asset monthly active users

70%

Development time saved

Design library 2.0

While order management was under testing and development, I updated the design library to 2.0. The library would include order management templates and components.

Summary

New order management system was launched, and this process gave the team confidence in building products in a cross-asset way.

Next case study

Mobile trading