Role
Product Designer — owned IA, interaction & product definition
Control Tower is the internal platform every Ritchie Bros. support team uses to move a transaction from auction to payment to released asset. I re-architected it around how that work actually happens — grounded in an audit of 51 real support actions — and led both the product definition and the design.
Ritchie Bros. runs one of the world's largest marketplaces for heavy industrial equipment. Behind every sale is a chain of people making sure it completes.
Customer Care Agents answer buyer and seller questions. CSMs manage relationships. Fin Ops reconciles money. Lien Specialists clear titles. Each of them lives in Control Tower — the internal tool that lets them see and act on what's happening across an account.
The name is the right metaphor: like air-traffic control, the job is keeping many moving things coordinated and intervening at exactly the right moment. The platform's job is to give each role a clear line of sight and the right controls — without burying them in everything the system could show.
This project was the 2.0: a full migration off a low-code Retool build and onto a purpose-built React application — and the chance to fix the structure, not just the surface.
The Retool version had been built feature-by-feature, in response to whatever request came in next. It worked — but the structure underneath had never been designed. The cost showed up in the day-to-day:
Without a PM, I could have started sketching layouts. Instead I started with an audit. I went through the team's standard operating procedures and pulled out every discrete thing a support user actually does in the platform — 51 distinct actions in all.
That library became the source of truth for everything that followed. Each action got mapped to the roles that perform it and the data it touches. Patterns emerged on their own, and the platform's structure fell out of the work instead of being imposed on it.
The six sections weren't a navigation guess — each one is where a cluster of audited actions naturally lived. I sequenced them around how work flows, leading with Events, the queue where a support user's day actually begins.
Role-specific landing. What a Care Agent needs to see first is not what Fin Ops needs.
The work queue — the entry point to a user's day, where incoming items get triaged and routed.
One search, the full account. The flagship surface for resolving anything tied to a buyer or seller.
Shared by Fin Ops and support, organized into four task-scoped subsections.
Everything tied to the equipment itself, from the support side of the lifecycle.
Corrections and exceptions, with approval handled as an access level rather than a separate role.
One search. Full picture.
The UCR was the answer to the platform's biggest failure: that one customer lived across many screens. The promise is simple — search once, and get the whole account in a single, navigable place.
▸ Replace with: UCR full-page layout (identity header + section nav + content)
The record holds a lot, so the structure has to keep the user oriented no matter how deep they go. A sticky identity header anchors who you're looking at, section navigation sits below it, and only the content area scrolls. You never lose the thread of whose account this is.
Search uses composable chips rather than a single fuzzy field. The model encodes real rules — a sale-number path is mutually exclusive from person chips — so the system can't be asked an ambiguous question. Results land in a persistent slide-over tray with full round-trip navigation back to where you started.
I designed a hybrid drawer that idles as a notes surface and becomes a detail inspector on demand — so the same persistent space serves both the "jot something down" and "look closer" needs without a second panel. It pushes content rather than covering it, using horizontal auto-layout.
The Payments tab opens with a Needs Allocation section — the work that actually needs a human — and a decision-tree remediation flow walks the user to the right fix. Out-of-balance payments were classified as invoice-initiated, so they live where the user already thinks to look.
▸ Replace with: search-tray round-trip · or the hybrid drawer in both states
Events is where the day starts, so the layout is built around triage. I explored a status-grouped accordion that merges each event card with its buyer detail inline — letting a user assess and act without leaving the queue or opening a new screen.
The open questions I worked through here were about multi-event expansion (how many things a user can hold open at once before the queue stops being a queue) and the navigation pattern back to a full buyer record. I carried the same IA-first discipline from the UCR straight into it.
▸ Replace with: status-grouped accordion, one row expanded
Owning the work solo meant every structural call was mine to make and mine to justify. I logged the reasoning as I went — here are a few of the load-bearing ones.
One primary pattern for actions — a slide-over tray — with modal, inline, and stepped-tray layered in only where the action type genuinely demanded it.
Notes can be created contextually in any section, but their full history lives unified on the customer record — filterable by where each was written.
I built components as patterns proved themselves across screens rather than speculating on a full library before the structure had settled.
A constrained five-color semantic system, each mapped to a specific UCR surface — so color always carries meaning rather than decoration.
Semantic mapping shown as placeholder — swap in your real five-color assignments.
If the platform hasn't fully shipped, that's fine — reframe this section as "Validation": stakeholder buy-in at the director presentation, prototype testing results, or decisions adopted into the build. Reviewers respect honesty about where a project stands more than invented numbers.
The thing I'm proudest of isn't a screen — it's that the structure holds up.
Because the architecture came out of a real audit of real work, every later decision had something to be checked against. When I wasn't sure whether something belonged in Events or the UCR, the action library answered it.
Working without a PM forced me to own the product question as well as the design one — what this should be, not just how it should look. That's the part of this work I most want to keep doing.
Next, I'd pressure-test the IA with the roles I designed it around and let real task-completion data, not my assumptions, decide where the structure flexes.