I redesigned BitMEX Convert to support recurring conversions. When technical constraints wiped out most of our scope during engineering review, I pivoted the design to work with what we had. We shipped in two weeks, driving a 12% increase in feature usage.

‍

‍

‍

Impact

‍

📈 Recurring Conversion, Shipped‍

Convert went from one-off swaps only to scheduled recurring conversion. Traders can now automate dollar-cost averaging without manually converting each time. Usage rose 12%.

‍

⚡ Two Weeks, Despite a Scope Cut‍

Most of the intended scope was ruled out at engineering review. Rather than stripping the design down, I re-derived the structure for what the platform could actually support and still shipped on time.

‍

🔒 Feasibility Before Fidelity‍

This changed how the team starts work. We now confirm the requirements and what the platform can support before anyone opens a high-fidelity file, and engineering starts building at handoff, once the designs are actually done.

‍

‍

The Brief

The requirement arrived as a reference rather than a problem: build what Binance has. That included multi-coin allocation, splitting one source asset across several targets by percentage and editable recurring plans.

‍

‍

Initial Design

Allocation meant splitting one source asset across several targets by percentage, and it set the structure, so I built around it.

‍

Each target coin got its own row with its own balance and dollar estimate. The set had to validate to exactly 100%, which meant a running counter in the label and an error state when it didn't sum. Past three or four coins the list had to scroll, which pushed frequency below the fold of the card.

‍

At that point recurring was a genuinely different input model from instant, so I put the two behind separate tabs.

‍

‍

The platform supported single pairs only

Then engineering review changed the picture. The platform only supported single-pair recurring conversion, and multi-coin had never been on the roadmap. Plan editing wasn't supported either, and frequency was capped at weekly and monthly, which ruled out the daily and sub-daily options in the brief. All three came out.

‍

‍

Restructuring

‍

The tabs stopped making sense

The obvious move was to delete the allocation rows and ship whatever was left. I didn't, because taking out allocation also took out the reason the tabs were there in the first place. Recurring was now just the instant form plus a frequency and a start time, so the tabs were making people choose a mode before they'd entered anything at all. I replaced them with a simple repeat toggle: instant is the default, and the form only grows once you switch repeat on.

‍

‍

‍

The control stays the same size

With multi-coin gone, there wasn't much left to set up. A control that kept adding panels as you made selections would have been solving a problem the form didn't have anymore. So whether you pick weekly or monthly, the control stays the same size: two rows, same height, same spot on the card. The only thing that changes is what's in the second dropdown.

A date picker didn't fit either, because it asks for a specific start date, and recurrence doesn't need a date. It needs an anchor: a day of the week or a day of the month. That's what the control sets, and it reads back inline as 'Triggers on the 1st.'

‍

The tabs and the expanding panel made sense for a bigger feature set. At this scope, they were just leftovers from a version of the product that didn't exist anymore.

‍

‍

In the Terminal

‍

Convert without leaving the terminal

The interviews I ran made one thing obvious: traders keep the terminal open all the time, usually with TradingView in a second tab. They've set their workspace up the way they want it, and they don't leave it. Sending them off to a separate page just to run a quick conversion breaks all of that, for a task that takes a few seconds.

Nobody asked for this part. It came out of the research, and I pushed for it.

‍

‍

‍

Create the plan, stay on the chart

So I separated creating a plan from managing it later. Creating one never takes you out of the terminal, and the confirmation comes back as a toast that sums up the plan in a single line (pair, frequency, next trigger). There's a link to the full page if you want it, but nothing forces you there.

‍

‍

Craft

‍

Errors prevented, not caught

Input handling is really where a trading UI lives or dies, so this is where most of the detailed work went. I mapped out the two-way auto-fill between the From and To fields and wrote the logic for handling the precision differences between assets.

To stop conversions from failing, I put the live min and max order limits right in the input placeholder, so you can see the limits before you start typing instead of finding out with an error after the fact.

‍

‍

‍

Masking engine latency

Other platforms update live rates instantly, but our pricing engine had constraints that delayed the updates a little. Snapping the numbers straight from one value to the next made that delay really obvious and jumpy, so I added a 500ms debounce on the rate refresh. It hides the backend delay and makes the whole refresh feel smooth and intentional.

‍

‍

A quote is only good for a moment

The platform couldn't price conversions live inside the form, so the form just collects what you want and the rate gets locked in once, at confirmation. That makes the quote the moment that actually commits you. It holds for ten seconds with a visible countdown, and when it expires the action blocks and asks for a fresh quote, so nobody ends up trading against a stale price.

‍

‍

Result

‍

12% increase in Convert usage 8 weeks after launch

2 weeks, design to ship

‍

Multi-coin allocation, plan editing and sub-weekly frequency were designed and deferred for a later release.

‍

‍

Reflection

The brief pointed at a competitor's product, and doing that quietly assumes your own platform can do what theirs does. Nobody checked whether ours could, including me, and I'd built a full allocation model before the question ever came up.

That changed how I work now. I get the requirements locked down and have engineering confirm the platform can actually support them, from a logic map or wireframes, before I open a high-fidelity file. I also asked that development not start from work-in-progress screens. On this one, engineering had already picked up a related flow because they had spare capacity, and they were building from designs I was still changing, which is exactly how you end up baking rework in from the start.

‍

‍

‍