Trading OMS: Designing a tool for professional traders

How much time do you have?

TL;DR

As Lead Product Designer, I led the 0-to-1 design of an internal Order Management System for a global bank’s trading desks, replacing a broad vendor platform.

Instead of copying the vendor’s feature set, I ran discovery with traders across regions to scope an MVP around what they actually use, then designed a modular pattern system that each new phase plugs into, with no redesign needed.

Role: Lead Product Designer, scoping, UX & UI
Scope: 0-to-1 product development
Timeline: 1.5 years

The shipped orders view

View all details below

For deep readers

1. Strategy & Scoping

From vendor dependency to internal ownership.

Context

Trading teams had been relying on an external OMS that was powerful but far broader than their real day‑to‑day needs. An internal solution was an opportunity to align the product with actual workflows, reduce long‑term dependency, and simplify an overly complex platform.​

Built an internal OMS to replace a broad, one-size-fits-all vendor tool, ensuring direct alignment with trading and system needs.

Role

As Lead Product Designer, the focus was on defining what the internal OMS needed to do first and what could be safely left out, based on usage patterns across global regions.

Partnered with traders, business stakeholders and developers across regions to scope MVP features, avoiding filler information and features. We’re building what we need, not a copy.

Highlights

  • Cut the MVP to core workflows after discovery with traders in global regions showed a relevant portion of vendor features weren’t needed, so the first release focused on what desks use every day.
  • Validated every data field before any UI work, with a Must-have / Nice-to-have / Not-necessary review. This aligned all stakeholders’ expectations, kept screens lean, and gave developers a fixed data scope from day one.
  • Shared the validated data scope early, so development could start in parallel with design.
  • Mapped trader actions and order phases when they weren’t yet shared across teams, then turned them into a shared model that aligned traders, Product and IT, and became the reference for design and development decisions.

The internal OMS is now a better strategic fit: focused, owned in‑house, and adaptable to evolving needs.

It supports autonomy, long-term ownership, and tighter integration with internal tools, while reducing reliance on an external platform built for a much broader market.​


2. Workflow Simplification

Untangling complex trading workflows without slowing traders down.

Context

Traders work in a high‑pressure environment with dense, fast‑moving information. Existing workflows had grown organically, with multiple tools and steps layered over time and tuned to a very broad audience rather than internal teams.

Approach

The work began with detailed workflow mapping in collaboration with traders and stakeholders across regions. Interviews, both local and remote, helped distinguish between what users said they needed and what they actually used. Diagrams and scenarios surfaced friction and duplication before any interface design. I followed what my friend Davide wrote about working with extremely busy people.

Close collaboration with Product Owners and Developers ensured solutions made sense, could ship quickly, and reused patterns from other internal platforms.

Untangled complex trader workflows, without slowing users down. No more manual cross-checking across scattered windows.

Highlights

  • Merged separate windows into one view with a detail panel, so traders stopped cross-checking across screens, adjusting complexity to suit actual needs.
  • Used user flow diagrams and shared key screens early and often, to communicate progress and feature implications to coordinators, developers, and other designers.
  • Chose dense tables with grouping levels and closable search tabs, so traders can keep high order volumes open without losing sight of the orders that need action.
  • Standardised grouping, filtering and drill-down across every table, so one mental model works everywhere and across use cases. New tables don’t need new patterns.

The OMS now supports the traders’ speed and focus, with targeted features for their roles, rather than duplicating the legacy platform.

Aligned workflows and patterns let teams across regions work more consistently while still respecting local financial specifics.

Building in‑house also ensures alignment with the design system and the reuse of known patterns, helping developers ship faster and with fewer mistakes, and giving users who work across several platforms a familiar experience.


3. Designing For Scalability Under Uncertainty

Creating patterns that future requests can plug into.

Context

The project was planned and delivered in several phases, and not all future requirements were known at the start. There was a risk of designing something too narrow or rigid, especially with development progressing in parallel.

Designed a modular, scalable architecture, enabling easy adaptation for future trading requirements on this and other internal platforms.

Approach

The design focused on reusable structures and interaction patterns rather than one‑off screens. Flows and components were kept modular so later phases could extend the system, rather than bypass it. The internal design system was used deliberately to maximise scalability and adaptability.

Devised a way of indicating item relationships across different tables and aggregations. Compatible with bulk-actions flows, too.

Highlights

  • Locked layout, navigation and data-handling patterns in phase 1, so later phases require little to no redesign.
  • Turned down customising for a single order type in favour of a configurable pattern that served all orders.
  • Reviewed each release with traders and engineering, catching misalignments before they shipped.
Building trust in the platform, down to the details, while managing operational risk and confidence in the product.

The Trading OMS can evolve without requiring a full redesign whenever new requests appear. This reduces future design and development effort and keeps the experience coherent as the platform grows, while giving stakeholders confidence that changes plug into an understandable system, rather than disrupt it.


What I learnt

  • Scope is a design decision. The biggest impact came before any UI: agreeing what not to build made every later screen simpler.
  • Busy experts need evidence, not workshops. Short sessions, concrete screens and data reviews got better input from traders than open-ended research.
  • Patterns beat screens under uncertainty. Investing in a pattern system early meant later phases fit in, instead of forcing redesigns.

“It’s been a unique and thought-provoking UX design journey which has really tickled users. It’s also been a constant quest for structure, and what we’ve established with you is a solid foundation for what’s to come.”