Dealer App
Designing a complex internal trading tool with dealers and engineers — turning dense workflows, dependencies and operational risk into a clearer product experience.
Specific designs, client data and internal materials are illustrative or anonymised and cannot be shared publicly. This case study describes the design process, decisions and challenges using non-sensitive materials only.
Understanding a specialised domain
before redesigning the interface
The Dealing team relied on an internal application that offered a wide range of useful functionality but had become difficult to use.
As new processes and requirements accumulated, the limitations of the existing experience became increasingly visible. The decision was made to create a new application as part of IG Internal Platforms, while maintaining consistency with the wider platform.
The challenge was not only to redesign the interface. I first needed to understand a highly specialised trading domain, map complex dependencies between processes and design a tool that could support expert users working with large amounts of operational information.
I was the sole designer on the project and had one month to prepare the first version of the high-fidelity prototype.
Learning the domain before
designing the interface
Trading was not a domain I knew deeply when the project started. Before I could make meaningful design decisions, I needed to understand how dealers actually worked, which processes were connected and what information mattered when making operational decisions.
The future users were based in Cyprus, so I began the discovery phase with several hours of shadowing. Observing dealers while they worked helped me understand their workflows in context rather than relying only on descriptions of how the system was supposed to work.
I followed this with group conversations where users could explain:
- What slowed them down
- Which parts of the existing application caused problems
- What information they were missing
- Which workflows were particularly difficult
- The trading concepts and dependencies I did not yet understand
The research helped me build enough domain knowledge to participate in product discussions rather than approaching the problem only from the interface level.
Designing in small steps
under a one-month deadline
I had one month to prepare the first version of the prototype. Given the complexity of the tool, attempting to understand and redesign the entire application upfront would have created too much uncertainty.
Instead, I worked in small, iterative steps. I organised daily design sessions with future users and the developers who would later build the application. During each session, we focused on a specific part of the system and explored:
- How the functionality needed to work
- How the same process worked in the legacy application
- Dependencies between different actions
- Potential edge cases
- The pain points users experienced in their daily work
This approach allowed understanding, design and technical validation to happen in parallel.
Focusing on operational risk
and information overload
Research revealed several recurring pain points.
Some workflows made it too easy to perform the wrong action, increasing the risk of mistakes during operational work.
Users often had to repeat similar actions for different financial instruments, creating unnecessary effort.
The existing application made it difficult to interpret information and decide what action to take. Users were working with information-heavy tables, inconsistent visual emphasis, difficult-to-read controls, and a large amount of competing information.
The redesign therefore needed to improve clarity without removing the density of information required by expert users.
Designing with users
and engineers, not for them
As the only designer on the project, I deliberately turned ideation into a collaborative process. Instead of developing concepts alone and presenting finished solutions later, I involved both users and developers in brainstorming and design sessions.
This gave us several advantages. Users brought detailed domain and workflow knowledge. Developers could identify technical dependencies and possible implementation constraints. I could translate those perspectives into interaction models, information architecture and interface concepts.
We were able to discuss multiple approaches to the same problem, challenge them immediately and explore corner cases before investing time in detailed design.
These sessions also accelerated my understanding of the trading domain. Every discussion gave me more context for evaluating flows, dependencies and potential solutions.
Prototyping continuously instead
of waiting for a final solution
During collaborative sessions, I aimed to end with at least a rough prototype of the concept we had discussed. The purpose was not visual polish. The prototype gave the team something concrete to react to and helped confirm that we shared the same understanding of the workflow and dependencies.
Between meetings, I developed those concepts into more detailed prototypes and brought them back to the team. As a result, each part of the application went through several rounds of discussion and refinement.
This iterative process helped surface gaps early, before they became expensive implementation problems.
Bringing in an outside
design perspective
Working closely with the same users and developers gave me deep domain context, but it also created a risk: becoming too accustomed to the complexity of the system.
To counter this, I regularly presented sections of the application to other designers within the company. Their fresh perspective helped challenge assumptions that had started to feel obvious to people immersed in the project. Different designers brought different experiences and questions, helping me evaluate whether the interface remained understandable beyond the immediate project team.
Interactive prototypes were then used both with users and during stakeholder discussions. They helped communicate not only what individual screens looked like, but how the product was intended to behave.
Making complex trading
information easier to interpret
One of the most important shifts in the new application was moving beyond presenting operational information only as dense tables and numbers. The project explored more visual ways of representing trading processes and schedules.
Users who were accustomed to working primarily with numerical tables saw value in visual representations of stock-exchange processes and different types of calendars.
The goal was not to make the professional tool visually simpler for its own sake. It was to help expert users recognise states, patterns and upcoming events more quickly while retaining access to the detailed information they needed.
Selected interface concepts
The following screens are selected concepts from the high-fidelity prototype created for the new Dealer App.
Operational dashboard
Market events management
Exchange schedule overrides
Pending state / workflow
Key product decisions
Bring domain experts into the design process
The complexity of trading meant that design decisions could not be made from assumptions or requirements alone. Daily collaboration with dealers allowed domain knowledge to become a direct input into the product rather than something transferred through documentation.
Involve engineering before handoff
Developers participated while concepts were still being explored. This made it possible to discuss dependencies, scenarios and feasibility before the designs became expensive to change. Engineering was part of shaping the solution, not simply receiving it.
Design iteratively under uncertainty
With only one month to prepare the first prototype, trying to solve the entire product upfront would have created unnecessary risk. Breaking the system into smaller areas made it possible to learn, design, validate and iterate continuously.
Reduce cognitive friction without removing expert-level complexity
The existing application contained information users genuinely needed. The goal was therefore not to remove complexity indiscriminately. Instead, the design focused on making important states, patterns and actions easier to recognise within a complex professional environment.
Outcome
The documented outcomes of this project were:
- A first high-fidelity prototype of the new Dealer App delivered within a one-month timeframe
- Key workflows explored collaboratively with future users and developers
- Individual parts of the application iterated and tested multiple times
- Interactive prototypes used for user validation and stakeholder communication
- Visual approaches introduced for presenting trading processes and calendar-based information
- A design direction aligned with the wider IG Internal Platforms environment
Complexity becomes manageable
when knowledge is shared
The hardest part of this project was not creating the interface. It was building enough understanding of the trading domain to make responsible product decisions.
Shadowing users and working with dealers and developers every day allowed me to gradually move from asking basic domain questions to participating in discussions about workflows, dependencies and possible solutions.
The project also changed the way I think about collaboration. Instead of treating research, design and engineering as separate stages, we worked through problems together while the solution was still taking shape. That helped us identify gaps earlier and made prototypes a shared thinking tool rather than simply a design deliverable.
It reinforced a principle that continues to influence my work: in complex products, the quality of the solution depends on how effectively domain, technical and design knowledge are brought together.