Account and Payment Improvements – Antonio Trotta

Context

A fixable problem without a fix

Payment-related queries accounted for 17% of all contacts to IG’s Trading Services team. That figure had been accumulating for years, but it had never been treated as a design problem. I believed it should be. Before any design work could begin, however, the business needed evidence that the problems were fixable and that the investment was justified. Building that case was the first task.

Problem

Years of design debt, no single owner

The ability to add and withdraw funds sits at the core of a trading platform’s client experience. At IG, the flows supporting it had been built incrementally over many years, without coherent ownership or a single view of the domain. Clients were failing to verify their bank accounts in predictable ways, generating support calls that were costing the business time and eroding confidence in the platform. The problems were not concentrated in one area. They were distributed across a domain that no one had yet attempted to understand as a whole.

My role

End-to-end ownership

I led the design work end-to-end: from planning and conducting the initial discovery phase, through producing the C-level investment pitch, to organising and facilitating the design sprint with the engineering team in Bangalore. A second designer joined the team during the elaboration and prototyping work. I was responsible for setting the research direction, managing relationships with compliance and regulatory stakeholders, framing the vision document, and translating the approved direction into testable design concepts.

Discovery

Building the evidence base before designing

My first decision was to treat the discovery phase as a standalone project. This was deliberate. The issues affecting payments were poorly understood across the business, and the evidence base needed to make a compelling investment case did not yet exist. Moving straight to design would have meant addressing surface problems without a clear problem hierarchy. I wanted to understand the domain properly before proposing any solutions.

I spent five days with IG’s payment support team, listening to calls and observing how advisors handled the most common queries. The volume of issues related to bank account verification was immediately apparent. What the call listening made clear was that clients were failing in predictable, consistent ways. The flows were not communicating what was required of them.

On the final day I ran an affinity mapping workshop with the support team to consolidate the week’s observations. This gave me a structured view of the failure points and a first indication of which issues were driving the most contact volume.

To understand the regulatory and compliance constraints governing account payments, I ran in-depth interviews with specialists across the Compliance, Credit, and Client Money teams. These conversations were essential, particularly given the complexity of the regulatory environment. Several of the verification failures I had observed were not design problems in the conventional sense. They were communication problems: clients did not understand the regulatory requirements they were being asked to meet, or why those requirements existed. The domain experts helped me map the full journey, identify the regulatory touchpoints creating friction, and establish which constraints were fixed and which could be addressed through better design.

The outcome was a series of detailed flow diagrams, which I maintained in a dedicated wiki page to give the broader team visibility into the domain analysis as it developed.

Flow diagram produced from domain research interviews. Mapping the compliance and credit decision points made clear that several common failure modes reflected a mismatch between how regulatory requirements were communicated to users and what those requirements actually meant in practice.

I completed the discovery phase with a competitor review examining how other platforms communicated payment requirements, and a full heuristic evaluation of IG’s existing flows using the Weinschenk and Barker guidelines:

Prioritisation

Choosing where to focus first

With a substantial backlog of issues identified, I used a Red Routes framework to prioritise by task frequency and user impact. This was an important discipline. Without it, the project risked becoming a catch-all improvement exercise. The Red Routes analysis gave the team a defensible basis for sequencing work and concentrating the first phase on the flows responsible for the majority of support contacts.

Red Routes prioritisation. Mapping tasks by how often clients needed to complete them against the consequences of failure gave the team a clear hierarchy and a shared rationale for what to address first.

Investment case

Making the case at C-level

The discovery work culminated in a vision document I prepared for C-level stakeholders to secure project funding. I applied IBM Hills methodology to frame the outcomes in terms of client experience and measurable success criteria, rather than as a list of design deliverables. The document connected the research evidence to business impact and gave the budget holders a specific picture of what success would look like.

The pitch was approved.

Framing the work in terms of client outcomes rather than design tasks gave stakeholders a basis for evaluating the investment on its own terms. IBM Hills vision document approach

IBM Hills vision document, prepared for C-level sign-off. Framing the work in terms of client outcomes rather than design tasks gave stakeholders a basis for evaluating the investment on its own terms.

Design Sprint

One week in Bangalore

With the project approved, I proposed running the kickoff sprint with the engineering team in person in Bangalore rather than managing it remotely. This required two weeks of preparation: restructuring the standard sprint format to fit the complexity of the payments domain, scheduling sessions across three time zones, and coordinating eight teams. It was not the simplest path, but I believed it was the right one.

The payments domain was technically intricate, the team was distributed, and remote alignment on a problem of this scope would have taken months. A week together in Bangalore compressed that into five days. By the end of the sprint, the team had a defined plan for the first release, a set of design concepts to develop and test, and a shared understanding of the problem that had not existed before.

Design Sprint, Bangalore. Five teams, three time zones, five days. The sprint produced the first tangible design directions for the bank verification and debit card withdrawal flows, and gave a distributed team a shared reference point for the work ahead.

Design

Prototyping the priority flows

Following the sprint, the team developed and iterated prototype designs for the priority payment flows. The bank account verification journey was restructured to communicate requirements clearly at each step and to reduce the inputs generating failures. The debit card withdrawal flow was redesigned around a single funding source, removing the requirement to add and verify a separate bank account. That requirement had been generating both client confusion and AML compliance risk. Neither was necessary.

Desktop design

Mobile design

Debit card withdrawal redesign. Addressing the different edge cases simplifying the rules and supporting the user along the way eliminated a persistent source of confusion. 98% of debit card withdrawal requests now complete successfully.

Outcomes

Three metrics, one domain

Bank account verification rates improved from 35% to 76%. Customer service contacts related to bank verification fell by 54%, and the time the Trading Services team spent on avoidable payment queries dropped by 47%. The debit card withdrawal journey achieved a 98% completion rate. Consolidating funding and withdrawal to a single source reduced AML compliance risk as an additional benefit.

These were not marginal improvements. They reflected what is available when a domain that has accumulated years of design debt is addressed systematically, with evidence-led prioritisation and proper investment from the business.

Reflection

The discovery phase was not a delay

The most consequential decision on this project was treating the discovery phase as a self-contained investment rather than a preliminary step. Had I moved straight to design, the work would have addressed visible problems without a clear problem hierarchy, and the pitch to C-level would have lacked the evidence it needed. The discovery phase was not a delay. It was the reason the project was approved at all.

Running the sprint in Bangalore was the second decision that proved its value. It was operationally demanding to organise. But it produced alignment across teams that had not previously worked together on the same problem, and compressed a coordination effort that would otherwise have extended the project timeline significantly.