Trade Experience / Order Entry System
Five connected trading surfaces designed from the ground up: the account you trade from, two ways to build an order, and the two places you live with it afterwards.
Scope
Five surfaces, one workflow.
The ticket is the part people picture, but it is one step. A trader picks an account, builds an order either one at a time or a dozen at once, watches what happens to it, and lives with the position that comes out the other end. I designed each of these surfaces and the decisions that had to hold across them.
Two entry points, not a queue: the ticket and the panel are alternatives, chosen by whether the hard part is the instrument or the volume. Both land in the same Orders list.
The product needed a trading experience that could meet institutional expectations, but trading was never one screen. The account, ticket, Orders and Positions are the same transaction at different moments, so designing them independently would create conflicting rules and states. The real problem was making the system agree across equity, options and multi-leg instruments.
Shipped as one connected system across QSWeb, and helped secure new bank clients.
Designed with the product teams that owned each surface, and carried through build and design QA with engineering and QA.
- 01One ticket, however complex the instrument
- 02Keep Orders flat, even when the order has a tree inside it
- 03Four kinds of holding in one table, without pretending they are the same
One ticket, however complex the instrument
An equity order is a symbol and a quantity. An options order adds an expiry, a strike and a side. A multi-leg strategy is up to eight contracts priced together and sent as one instruction. The ticket absorbs all three rather than forking into separate experiences: one structure, the same fields in the same order, growing as the instrument grows. Fast trade and Line Trader are built on the same model.
Progression, steps 1 to 3
The ticket grew as the instruments did.
It did not start at eight legs. Each step kept the shape of the one before it and added only what the new instrument genuinely needs, because a trader moving from shares to options should not have to learn a new screen.
- Side, symbol, quantity
- Order type and duration
- One estimated cost
- Expiry, strike and call or put
- Open or close, not just buy or sell
- A quote panel worth the space it takes
- Two legs, one instruction
- A strategy above the legs that drives them
- One net price, which can be a credit
Step three is where the design cost sits. Up to that point a ticket priced one thing. A multi-leg order prices the whole set, so the total stops being a sum of rows and starts being the thing the trader is deciding on. Step four is the same ticket taken as far as it goes.
Progression, step 4
Eight legs, one order.
The far end of the same ticket. Rolling an Iron Condor means closing four open contracts and opening four replacements, so the ticket has to hold all eight, price them together, and submit them as a single instruction. Nothing new is introduced here: it is step three at the size it has to survive.
+5 more legs
A ticket sized for its hardest case carries structure a plain equity order never needs. The alternative was a set of tickets that each had to be learned, and maintained, on its own.
Keep Orders flat, even when the order has a tree inside it
Orders is a list you scan. A multi-leg order breaks that: it is a parent with up to eight legs, and those legs carry real meaning. Turning Orders into a tree would charge every ordinary order for the few that need the structure. Instead a multi-leg order expands in place into its legs, with a narrower column set, because a leg is not a small order and should not be dressed as one.
Orders
A flat list with a tree inside it.
Orders is a long scannable table and almost every row is one order. A multi-leg order is not. It is one thing the trader submitted and several things the market answered separately, and both facts have to be true in the same list.
Giving each leg a full row would have doubled the list and implied things that are not true. A leg has no status, order type or order id of its own. It only has a fill.
The parent keeps the order columns. The legs get their own header and only the four that mean anything to a leg, aligned under the parent's so the fills read down one column.
A second header inside a table is a thing to keep aligned forever. It buys a list that still scans in one column while telling the truth about partial fills.
Leg detail sits one interaction away rather than in view at rest. The list stays scannable, which is the thing Orders exists to do.
Four kinds of holding in one table, without pretending they are the same
Positions carries shares, single options, covered positions and spreads. They share a surface but not a grammar: what you can do to a covered call is not what you can do to a hundred shares. Positions groups by what the holding is, so each kind keeps its own identity and its own actions instead of being flattened into one generic row.
Positions
Four kinds of holding, one table.
Shares, a single option, a covered call and a two leg spread are all positions and none of them are the same thing. They are named differently and the sensible next action is different for each, so the table groups them and lets each group keep its own identity.
A single flat list would have needed one generic row that described none of them well and offered actions that did not always apply. Grouping costs a heading per section and buys rows that say what they actually are.
One uniform table would have been less to build and less to learn. It would also have offered the wrong actions on the wrong holdings.
A trading system rather than a set of screens.
Delivered a complete set of trade tools, including tickets, modules, and contextual actions integrated into QSWeb. The system was used to support institutional requirements and helped secure new bank clients, including BMO and Scotia. Established a scalable design system and interaction model that continues to be reused across products and platforms.
Across devices
The same order, wherever it is opened.
One instruction, the same fields in the same order. On a trading desk a leg is a line. On a phone it is a block. The layout re-forms; the model underneath does not.
+5 more legs
More detail behind the decisions above.
Why Roll was the hard case
Every other ticket action resolves to one direction applied to everything. Roll is the single exception, and that exception is what forced the ticket action and the leg order types to stay answerable to each other.
Interaction logic
Roll is two positions in one order.
Open and Close apply a single direction across every leg. Roll is the only action that holds both at once, so the ticket-level action and each leg's own order type have to stay reconciled in both directions.
Changing one leg updates the ticket action; changing the ticket action rewrites every leg. Neither can drift out of step with the other.
Two ways to build an order
The ticket is one way in. The multi-order panel is the other, built around scope so an incomplete order cannot be selected and a bulk action can never act on something that will fail. It has since grown into its own module.
The order still has a life after submission
Ticket work usually stops at submit. What comes after it is where a trader finds out whether the order did what they meant, so the confirmed state had to keep reporting rather than just congratulating.
Review to confirmation
Designed through to done.
Eight legs collapse into one decision: what the order does, what it costs, and whether to send it. Submitting resolves into a confirmed state that still reports what was placed.
Six widths, and the one the build found
Every surface was drawn at six widths from 390 to 1920. The build surfaced a seventh between 1024 and 1280, which was applied across every surface rather than patched into the one that exposed it.
Responsive
One leg, three layouts.
The same leg, carrying the same six decisions, re-forms as width is lost. Only the layout changes, never the order of the fields.
Every field on one line, scanned left to right.
The row wraps to a second line. Field order is unchanged and controls keep full size.
The leg becomes its own block, with the row action moved to its header.
Implementation
The breakpoint that came from the build.
The ladder started as the usual set. It gained one more once the tickets were being built, and that one came from a developer, not from a design review.
Six widths from 390 to 1920, each a layout I had drawn and signed off. The gap between 1024 and 1280 looked like a safe stretch of the same design.
It was not. In that gap the ticket body and the quote panel were both above their minimums individually and too wide together, so real windows landed in a range no drawing covered.
A seventh snap point at 1192, drawn for every surface rather than patched into one. It is in the equity ticket, the options ticket and the holdings table, because a breakpoint that only some screens know about is worse than the gap it fixed.
The same pass produced the quote panel that collapses below 568 rather than shrinking, for the same reason: two things that each still fit are not the same as two things that fit together.
The signals that had to hold everywhere
Two colours for buy and sell. Status as a chip in the same column on every surface. A link mark for a row that is part of something larger. Themes standardized to Dark, Light and CVD across all four products rather than decided per screen.
System
Decided once, then used everywhere.
These surfaces were built over about a year, in different sprints, sometimes for different client builds. Four decisions had to mean the same thing in all of them, because a trader moving between screens should not have to relearn what a colour or a mark is telling them.
Related Projects
Line Trader
Placing twenty routine orders through a full ticket means twenty trips through the same screen. Every row here is a complete order, so a list of them can be built in one place and sent together or one at a time.
Notes
Leadership asked for something like a consumer notes app. What the product needed was notes that know which instrument they are about, and that survive being one panel in a crowded workspace.