CopyTrading

One week, two inputs.

A service-design session: we split into three groups, one per user type (newbie, experienced trader, master), interviewed them, turned each finding into a feature, and scored them into an MVP backlog.

Alongside it, I studied every major competitor – how they're built, what users already expect, where they fall short.

Three findings shaped the product:

• The two roles aren't fixed. A newbie often grows into a master with their own copiers. So I designed for the journey between roles, not two static types.
• Users didn't want complex strategy filtering, so I cut it.
• The standard terms confused even expert traders, so I fixed the wording with our UX writer.

I turned the findings into architecture diagrams, user flows, and a journey map for each role – all built inside one fixed limit.

We used a ready-made backend, chosen for cost and speed. It set the number of accounts, how offers worked, the copy formats, and the analytics I could use.

I designed the flows to fit those limits instead of fighting them.

The easy option was to put CopyTrading inside the existing trading app – instant users, no marketing cost.

I argued against it, on three risks: the trading app had a history of regulator and app-store blocks, including one permanent one; it was built only for trading, so adding CopyTrading meant rebuilding its whole structure; and that rebuild would break the budget and the deadline.

The cheapest way to reach users carried the biggest risk. We built a separate app.

Full product across both roles. The master creates a strategy, sets how they get paid, and manages it. The investor discovers a strategy, reads its stats, sets copy parameters, starts copying, and reviews results.

The clearest place the stance shows up is the discovery screen. A beginner picks who to copy from a few numbers – so those numbers are a safety choice, not decoration.

We researched which stats tell the truth about a strategy instead of dressing it up, and landed on six. Three are direct: ROI, drawdown, and P&L. Three are indirect: how many people copy it, how long it's been running, and a risk score we built. You can tell at a glance whether a strategy is any good, and one flashy number can't fool a newbie.

The same stance shaped the copy controls: fine-grained limits and a manual close, so the investor stays in control of their own money.

The mobile app carries the full investor loop – discover, set copy parameters, copy, review. It has no master flow, and that was deliberate.

Masters work mostly on desktop, and building the full master side on mobile was expensive for little return.

Cutting it fit the stance, too: the product is built around the investor, so the investor's experience had to be everywhere.

The web cabinet had no real system – about a hundred unassigned colors. I didn't rebuild it. I took the minimum: reworked the existing kit and pulled a small set of tokens from production, just enough to ship.

Before handoff I built a prototype and ran a moderated usability test on the two core flows – the investor finding and copying a strategy, and the master creating one. This checked flow and wording, not scope: can people move through it, do the terms make sense. It surfaced a few small copy fixes, which I made before the final handoff.