FinchTrade↗

Context

FinchTrade sells liquidity to businesses that move size: instant exchanges, payment processors, card acquirers, institutional desks. They do not shop by browsing – they arrive from a peer, a Telegram group or a conference, already knowing what execution quality means, and they decide fast whether a counterparty looks credible.

That set the design problem. The product had to prove reliability, compliance, and execution before it explained features, and it had to serve a desk where the Trader, the Compliance officer, and the Founder each sign in under their own role, with a different scope of responsibility.

Role and scope

Sole product designer on a team of 16, end-to-end: user research, information architecture, UX and UI for the trading portal, the product website, an atomic design system, and brand communications. The same period covered the sibling AML product, MarketGuard.

Research ran the same way it did on the sibling product: competitive analysis across the OTC desks these buyers already used, more than 20 jobs-to-be-done interviews with Traders and Founders, personas, information architecture validated against their tasks, then prototypes and A/B tests before build.

Artifacts: personas, in-product journey, story map, information architecture, testing↓

Insights that changed the product

What the research found, what it changed in the interface, and what that produced.

Trading portal

The competitive review had already shown most of what the interviews said: onboarding, the dashboard, Spot trading with Market and Limit orders, RFQ, and deposits to whitelisted addresses counted as basic on both sides – which is an answer in itself, the baseline was set right. The difference was elsewhere: exportable trading history, separate access rights per teammate, multicurrency and reporting-currency options, and a referral system. The interviews with Traders and Founders named each of those.

Onboarding, three versions deep

Full access is gated by KYC. Reviewing the file, FinchTrade's compliance team can ask for further documents, and usually does, so every request has to reach the client through the product. The point was to unload the inbox, unload support, and let the review run without anyone chasing documents by hand. It took three versions, from a 324-minute queue down.

73%Widget CTR

312 minOnboarding time

Version 1 displayed one request at a time, and that action froze the queue:

• the next request waits for the current one to close
• the client never sees how much is left
• nothing runs in parallel, nothing can be handed over

78%Widget CTR

128 minOnboarding time

Version 2 moved the requests to the bottom right corner. One card per request meant the stack grew with the queue: on a narrow display it took the whole UI, and on a wide one it buried the point under three or four lines of instructions – with nothing to minimise until the request behind it closed.

89%Widget CTR

68 minOnboarding time

Version 3 replaced the queue with one list: every open request, its state, and the link that closes it. The FAQ and a line to the account manager sit in the same widget, which folds into an animated 👋 in the corner when nobody needs it, so questions stop becoming support tickets. The job now sits on the dashboard, not in the inbox or the support queue – onboarding fell to 68 minutes, 79% less, and click-through on the widget reached 89%.

Product website

The site is organised around what each audience is trying to do rather than around the product’s own structure. Every persona named the same first channel – their own network, a LinkedIn or Medium community, an offline conference, with Google last – so navigation was built by persona and use case: the use-cases block repeats below the fold, the footer carries expanded navigation, and the demo request answers with a calendar of open slots.

Site metrics: the ninth month of work against the baseline taken when analytics went in

The drop in misclicks came from the design system: clickable elements were given their own language, so nothing static looked interactive.

Lighthouse audit: after the code and graphics optimisation against before

Raising load speed was my initiative: I set the target and took the graphics half of it – SVG for interface graphics, WebP for the rasters, lazy loading below the fold. The code was the front-end developer’s.

Design system

An atomic design system shared by the trading portal and the AML product, documented so the front-end team could build from it without a hand-off call.

One rule did most of the work: a clickable element says so, and nothing static borrows that signal. That is what brought the misclicks on the website down, and it earns more inside the portal, where a dense trading screen leaves little room for guessing. The rest of the system exists so the rule holds at scale – foundations on a 4×4 module, every component documented with its states.

Communication design

Buyers typically first come across the company on LinkedIn, Medium, or at conferences, so the materials available there shape their first impression.

I created a unified template system for social media posts, content feeds, sales one-pagers, and business cards that can be opened on a phone’s lock screen, saved, or forwarded immediately. This system ensures the brand remains clear and credible, since in this market, a loud presence is considered risky.

The system also supported the brand identity, the SMM style guide, and the printed materials used for conference stands.

Research

The artifacts, as they were used. FinchTrade and MarketGuard shared a design system, not a study – the interviews, the testing, and the card sorting below were run for this product. Every table here is transcribed from the working research board.

In-product journey

What it produced: the order of work inside the portal, and the two places where it stalled – KYC follow-ups and onboarding.

The path inside the product, from sign-up to the first trade – the marketing funnel is shared with MarketGuard; this one is not

User story map

What it produced: the MVP scope, in the order a desk actually meets it. Four tracks, each read top to bottom: the need, the goal behind it, the stories under that goal, and the tasks the interface has to carry.

User story map – transposed from the board so each level reads as a row

Information architecture

What it produced: the four sections of the portal, and the names on them. Twelve features were sorted by users before any screen was drawn, so the grouping came from their vocabulary rather than from ours.

Quantitative and qualitative research

The prototype went through Maze twice. Open questions were clustered into themes, an opinion scale measured how hard the task felt, and the second round ran against the fixes the first one asked for.