SEPT 24 → RESEARCH · CASE STUDY

Dynamic Quantum Optimisation - IBM Quantum, 2024

Led design and prototyping for a quantum-powered financial trading interface

Role: Design Lead (UI/UX, Prototyping, Client Demo)
Team: EMEA Head of Quantum Sales, 2 Quantum Developer, 2  Engineers, 2 Designers.
Toolkit: Qiskit, Python

Confidentiality Note

This case study describes a design exploration conducted within an enterprise AI incubation studio. Certain details have been generalised or omitted to respect confidentiality.

Quantum - Call Options
Animated Version of this Case Study

Project Overview

Problem
A global enterprise was spending significant compute time pricing fuel hedging instruments across quarterly portfolios. The underlying challenge — pricing call and put options across multiple assets over one- and two-year forward periods — aligned well with quantum amplitude estimation.
Non-technical teams across IBM wanted to prototype internal tools to improve workflows, but building even simple applications required engineering support. Existing no-code tools struggled to produce outputs aligned with IBM’s Carbon design system and enterprise standards, which reduced trust and limited real adoption.

The algorithms were functioning. The challenge was making their outputs usable for quantitative trading teams operating under time pressure.

I led prototyping, interface design, and the final client demo, working closely with quantum developers to translate algorithm outputs into something traders could evaluate and act on.

The Design Problem

The audience was quantitative trading teams, not general users. They did not need an explanation of quantum computing. They needed:

→ Clear decision outputs
→ Transparent differentiation between quantum and classical methods
→ Traceability from algorithm to result

This created three concrete requirements.

Decision Clarity: Users needed to evaluate hedging positions and forecast outcomes without switching into technical tooling. The interface had to absorb the computational complexity and present trade-relevant outputs directly.

Method differentiation: Quantum-derived outputs (via amplitude estimation) had to be visibly distinct from classical pricing results. This distinction needed to be embedded in the UI, not hidden in documentation.

Algorithm lineage: For a quantitative audience, credibility depends on traceability. The interface surfaced direct links to the Qiskit tutorials and academic references underpinning each algorithm, allowing users to inspect the methodological chain if required.

What We Built

The dashboard organised hedging data by quarter, showing optimal portfolio positions, trade frequency across the hedging period, and comparisons between quantum-informed pricing and spot performance. Quantum-derived outputs were clearly marked within each result view, so traders could see which components were informed by quantum amplitude estimation and access the underlying methodology without leaving the workflow.

The key decision was embedding algorithm provenance directly into the result layer rather than separating it as external documentation. For this audience, that distinction was the product.

My Contribution

I led:
→ Rapid prototyping of the trading interface
→ UI/UX design translating probabilistic algorithm outputs into trade-relevant views
→ Structuring how quantum and classical results were differentiated
→ The final client demo

The work focused on making algorithm outputs legible to experts who needed to evaluate risk, not explore technology.

Key Outcomes

The interface was deployed to the client and the project became a whitelabel reference model used across EMEA for scoping and presenting quantum engagements. The design work established patterns for a genuinely new category of problem: how do you present quantum algorithm outputs to expert users who need to act on them, not just understand them?

What This Taught Me

Quantum computing introduces a specific interface challenge:

→ Outputs are probabilistic
→ The computational process is opaque
→ The audience is technically capable and sceptical

The usual design instinct is to abstract complexity away from the user. This project inverted that. The audience was sophisticated enough that transparency was more useful than simplification — showing the algorithm, its provenance, and its distinction from classical methods made the outputs more actionable, not more overwhelming. Designing for experts sometimes means designing for more, not less.

Project OverviewThe Design ProblemWhat We BuiltMy ContributionKey OutcomesWhat This Taught Me
Benjamin Woodmansee is an AI product designer working on frontier AI systems including agent interfaces, computer-using agents, generative AI tools, developer platforms, and human-AI interaction design.