The Bid & Offer application was an internal trading tool used to review, manage, and act on market opportunities.

On the surface, the problem looked technical: the page was slow, the data took too long to load, and the interface had become difficult to use as the amount of information grew.

But after working more closely with traders, it became clear that performance was only part of the problem. The bigger issue was that the tool no longer matched the way traders actually worked.

My role was to help improve both the experience and the technical foundation of the application: making it faster, clearer, and more aligned with the real trading workflow.

Help traders move from information to action faster, with less noise and more confidence.

Context

Trading tools are different from generic business applications. They often sit inside fast-moving workflows where timing, confidence, context, and small interface details matter.

A slow or cluttered screen does not just create frustration. It changes how users behave. People open extra tabs, export data, create shadow workflows, and eventually stop trusting the product during the moments when it should be most useful.

The Bid & Offer app had reached that point in parts of the workflow. It was still functional, but it was asking too much from its users.

Problem

The main problems were a mix of product, UX, and engineering issues. The page loaded too much data upfront, backend queries were doing more work than necessary, and the frontend had to render large amounts of information at once.

At the same time, the UI was visually heavy. Important fields were mixed with secondary details. Traders had to scan too much information to answer basic questions: is this relevant, is it actionable, what changed, and what do I need to do next?

There was also too much manual data handling. Some bid and offer information came from semi-structured sources such as emails, chat messages, copied text, or documents. Turning that into structured data slowed the workflow and increased the chance of mistakes.

Constraints

This was not a greenfield product. The application already supported real trading workflows, existing data models, and operational habits.

  • We could not redesign everything at once.
  • We could not interrupt active workflows.
  • We had to preserve details traders relied on.
  • We had to improve performance without making the system harder to maintain.
  • We had to introduce automation without reducing user control.

A big part of the work was translating between traders and engineers. A trader saying a page is slow might mean the API is slow, but it might also mean the useful information is hard to find, filtering takes too many steps, or the screen does not match their mental model.

What I did

I worked closely with traders to understand how they used the application during real workflows. Instead of starting from the UI or the database structure, we started from the trader's decision process.

We looked at what they checked first, which fields created confidence, which details were only needed later, which actions happened repeatedly, where they hesitated, and where they left the product for another tool.

That helped separate the work into three practical areas:

  • Simplify the interface around the most important trading decisions.
  • Improve how data was loaded, queried, and rendered.
  • Explore AI-assisted data capture to reduce repetitive manual input.

Design decisions

One important design decision was to treat focus as a feature. The previous interface exposed a lot of information at the same time. Every field had a reason to exist, but not every field deserved the same level of attention.

  • Primary trade information stayed visible.
  • Secondary details became less dominant.
  • Rarely used information moved into deeper views or expandable areas.
  • Repeated actions became easier to access.
  • Filters and sorting followed how traders actually searched for opportunities.

The goal was not to hide complexity completely. Trading is complex, and expert users need control. The interface needed to reveal complexity at the right moment, not all at once.

Engineering decisions

The performance work focused on making the system faster in ways that matched the user workflow.

  • Introduced pagination so the app no longer loaded everything upfront.
  • Optimized database queries to reduce unnecessary work.
  • Returned smaller API payloads focused on the current view.
  • Improved filtering and sorting responsibilities across backend and frontend.
  • Reduced frontend rendering cost for large table-like views.
  • Avoided unnecessary re-renders and expensive client-side transformations.
  • Cached stable reference data where it made sense.
  • Added clearer loading and refresh states.

The point was not only to improve technical metrics. It was to improve the feeling of the product. A trading screen that technically loads in the background but leaves users waiting, guessing, or scanning too much still feels slow.

AI-assisted data capture

Another improvement area was reducing manual data entry. Bid and offer information often starts in messy formats: email threads, chat messages, copied text, PDFs, or semi-structured notes.

We integrated AI APIs to help capture information faster. The AI layer assisted with:

  • Extracting bid and offer details from unstructured text.
  • Pre-filling fields such as counterparty, product, volume, price, and delivery period.
  • Highlighting missing or ambiguous information.
  • Suggesting normalized values when source data used inconsistent wording.
  • Detecting potential duplicates or similar existing entries.
  • Summarizing longer messages into actionable details.

The principle was important: AI should reduce admin work, not replace trader judgment. Traders still reviewed, corrected, and confirmed the information.

Outcome

The improved Bid & Offer experience became faster, clearer, and better aligned with how traders worked. The page no longer tried to load and display everything at once. Traders could get to relevant information more quickly, scan with less effort, and focus on the trade instead of fighting the tool.

Performance improvements helped reduce waiting time and made the app feel more responsive under real usage. UI improvements reduced visual noise and made the main workflow easier to follow. AI-assisted data capture helped reduce repetitive manual input and moved information into the system faster.

What I learned

The biggest lesson was that trading software is not only about data and execution. It is also about language, trust, and workflow.

Engineers talk about APIs, queries, state, payloads, rendering, permissions, and maintainability. Traders talk about price, exposure, counterparty, urgency, confidence, and action. Both views are necessary.

I also learned that performance problems are not always purely technical. Sometimes the page is slow because the query is slow. Sometimes it feels slow because the user has to process too much information. Often, it is both.

Reflection

This project reflects the kind of engineering work I enjoy most: close to users, grounded in real workflows, and practical about trade-offs.

A faster page is useful. A clearer workflow is useful. A tool that helps users focus on the right decision at the right moment is much more valuable.