Introducing trade executions to Rocket Exchange
As an intern, I was the sole designer on this workstream, onwing the end-to-end flow design under my mentor's guidance. From February—April 2026, I worked in a close pod with our Product Manager and Engineering leads to fine-tune the feature, where it is now being built out in our Beta dev environment, setting the stage for more trade executions to come.
OVERVIEW
Trading and hedging securities are the backbone that keep mortgage lenders like Rocket running.
Without it, Rocket would risk running out of the capital required to close hundreds of millions of dollars in mortgages daily! When the Capital Markets team needed to add Options trading to their operations, product leadership saw a bigger opportunity: build it inside Rocket Exchange, our next-gen platform, instead of the aging legacy trading app. Because Options would be the first trade execution type built in Rocket Exchange, this design would become the foundation every future trade type builds on.
CONTEXT
Rocket's trade executions run on a legacy application built over twelve years ago without product or design support.
The system has become slow, inconsistent, unintuitive, and difficult to update, limiting the team's ability to expand in any direction. Every new feature means fighting an already brittle system rather than building on a solid foundation.
This project presented the opportunity to deliver a new, business-critical feature, and create a foundation to bring all trade execution types into Rocket Exchange. That meant the design decisions here would set the interaction patterns and workflows that every future trade type would inherit. Getting the framework right was as important as getting Options right.
DESIGN PROCESS
We build for a small, internal user group, usually 5 to 10 people making decisions that move millions of dollars within the company.
Because of our user size, we connect with traders' team leaders (who are themselves users of our features) throughout the process, from discovery through implementation.
Our PM and lead engineer put together rough v0 prototypes to establish the feature's core requirements, like saving drafts of trade bookings and giving traders the opportunity to pairoff open trades at the time of booking. We shared these early with the users' leader to surface potential issues or gaps before committing to a direction.
From there, I took the v0 prototypes as a starting point and iterated in Figma to find the right layouts and flows. I set up a regular feedback cycle with Product and Engineering, sharing the latest iterations to stay aligned as the design evolved.
Early iterations of the trade bookings layout.
KEY DESIGN DECISIONS
Determining where a trade lands on the interface after booking
Early on, I had landed on showing both drafted and booked trades in parallel tables, since our PM confirmed there would only ever be a handful of drafts at a time. The team approved it, but with one caveat: there needs to be an initial filter to show trades in the "Booked" table, because there was too much data to load at once.
This presented an experience issue: when a user books a trade, how do we show the user it was successful? What if they want to take actions on the trade immediately after booking?
My solution was to move the booked trade history onto its own dedicated tab and replace the "Booked" table with a "Booked today" table, saving traders time from having to enter search filters to view trades they just booked.
Designing multiple trade history iterations to accomodate Engineering timelines
Given the constraint that historical trades required initial search filters, I dove into iterations of what that experience would look like, given the high volume of inputs a trader could search with. I landed on an design recommendation where the historical view lives in its own tab to maximize the viewable rows in the historical table and the search filters are grouped and labelled to aid easier navigation of the many input options.
Additionally, knowing that this feature will already be a heavy lift project for the team, and that there can be some lift from devs when elements from a page need to interact with or affect AG Grid table integrations, I aimed to be flexible to potential needs by creating an "MVP" option that uses AG Grid's built-in filtering tools. This would work with the historical table out of the box, meaning that, while not the ideal UX (such as a lack of input organization and showing users a black table), it would not cause potential delays on a prioritized feature.
Once I reviewed the options with the team, we were able to determine that the design recommendation was workable for the initial feature launch.
Finding the right time and place for users to match trades for pairoff
A key part of the trading process is "pairing off": the act of matching opposing trades and settling out the difference in cash, reducing the amount of transactions to complete and lowering costs.
There are several workflows where a trader could engages with pairoffs: when immediately they book a trade, checking open trades for new opportunities, or reviewing existing pairoffs to break up. A key challenge was figuring out the best place for these workflows to live—contextually with other trades or in a dedicated pairoff space?
I explored options where traders could open drawers contextually to interact with pairoff actions, but ultimately the tables that pairoffs actions interfaced with were too big to make sense living in a drawer.
Ultimately, I recommended that pairoffs could mirror the design of trades themselves, where there would be a table to create pairoffs and one to manage existing tradeoffs.
FINAL WORKFLOWS
These 3 key design decision led to the final architecture of the feature, where each workflow lives in its own tab.
OUTCOMES
My end-end designs were approved for an initial Beta launch.
Actively collaborating with cross-functional partners and showing multiple design options let the team balance visual craft and user experience against engineering timeline with full information, giving us confidence heading into initial launch.
My design set the foundation for how trade executions work in Rocket Exchange.
An additional trade type, Futures, is already slated to begin development immediately after Options launches, inheriting the interaction patterns, data structures, and workflows I designed.