TradingRooms·0→1 · Consumer Fintech · Sunset

Retail traders don't want more advice. They want to trade without watching the market.

TradingRooms — Room discovery screen
My role
Product Designer
0→1 · two-sided marketplace
System
3
actors · 10+ brokerages
Distinct user journeys
2
Room User + Room Creator
User states designed
4
Creator, Member, Non-member, Logged-out
The Insight

Most trading tools give you more information. TradingRooms gave you execution.

Retail investors in India face a specific problem that more data doesn't solve. The market is open from 9:15 AM to 3:30 PM. Most people have jobs. Even those who want to invest actively — who follow markets, read research, join trading groups on Telegram — can't be in front of a screen when it matters.

The insight: Retail traders don't want more advice. They want reliable execution without constant involvement. The tips and signals industry already existed. What didn't exist was a platform where an expert's strategy could execute automatically in a subscriber's brokerage account — in real time, transparently, with the user's funds staying exactly where they were.

TradingRooms was not a robo-advisor. Not a tips service. A social platform where expert traders ran Rooms, and subscribers auto-traded alongside them.

The System

Three actors. Two journeys. One platform connecting them.

TradingRooms wasn't a single-user product. It was a three-sided system — and every design decision had to work across all of them simultaneously.

Room Users
Retail investors who subscribe to Rooms, link their brokerage, and auto-execute trades. Never manually enter a trade.
Room Creators
Expert traders who build Rooms, set strategies, set pricing, and manage subscribers. Monetise their expertise.
Brokerages
Where execution actually happens. 10+ integrated via Open-API. TradingRooms is a relay, not a custodian.

“Users reasoned at the Room level, not the trade level. The product abstracted individual trades into a Room — and that abstraction was the design.”

Users didn't ask “what trades happened today?” They asked “how is my Room performing?” That distinction shaped every screen.

Room User Journey
01Discover Rooms
02Evaluate performance
03Subscribe
04Link brokerage
05Automated execution
😊😐😟
Curious
Hopeful
Excited
Anxious
Confident
Room Creator Journey
01Create Room
02Define strategy
03Set pricing
04Manage subscribers
05Iterate on performance
😊😐😟
Motivated
Focused
Uncertain
Engaged
Rewarded
The Trust Problem

You're automating decisions with real money. The design has to earn that trust before the system touches a rupee.

The hardest design constraint wasn't information architecture or two-sided marketplace logic. It was trust. “Automation without loss of control” wasn't a design principle I wrote down — it was a constraint I kept running into.

What that principle meant in practice:

Users can see every trade executed in their account · Users can pause or exit a Room at any time · The brokerage account stays in the user's name — TradingRooms never holds or touches funds · Execution happens at the user's broker, using their existing account

TradingRooms was not a custodian. It was a relay. Expert strategy in → execution at the user's broker out. That architecture wasn't just technically cleaner — it was the trust model.

Key Decisions

Three decisions that shaped how the whole product works.

01
Rejected
Design around individual trades or signal feeds

Users follow specific calls — fine for power users, but requires constant attention and creates no stickiness.

Chosen
The Room as the core mental model

A Room is a container: strategy + creator + subscribers + performance + community. Users subscribe to a Room — and everything inside it follows. Discovery, performance, and trust all operate at Room level, not trade level.

AboutFeedPortfolioPerformance
02
Rejected
Generic help docs for brokerage linking

Different brokers had different flows, API setups, TOTP requirements. Users were dropping off because docs weren't specific enough.

Chosen
Contextual broker-specific video at the friction point

When a user selects a broker, a short video showing exactly how to link that broker appears inline — right next to the selection, before they start. Not a redirect. A contextual walkthrough at the exact moment of friction.

Brokerage linking with inline contextual video

Contextual help at the exact moment of highest drop-off.

03
Rejected
Full automation — set it and forget it

Automating real money decisions without user visibility creates a trust cliff: everything feels fine until it doesn't, with no context or recourse.

Chosen
Automation with full transparency

Every trade is visible. The automation runs, but the user can see it running. Pause and exit controls are always accessible. The system executes; the user stays informed.

Room detail — trade log and automation controls

The automation runs, but the user can see it running.

What Was Validated — and What Stopped It

The thesis held. The distribution problem didn't.

TradingRooms validated the core thesis: retail traders would delegate execution to experts they trusted, and expert traders would pay to monetise their strategies. Rooms were created, subscriptions activated, trades executed automatically in real brokerage accounts. The system worked.

“The cold-start problem on the creator side, and the trust gap on the user side, were product problems that design alone couldn't close.”

What it also surfaced was a harder problem. Trust at scale requires track record. Track record requires time. An early-stage platform — even a well-designed one — can't manufacture the kind of verified performance history that makes a retail investor comfortable automating their savings. Without the distribution to solve both simultaneously, the platform couldn't reach the scale where network effects would have kicked in.

TradingRooms was sunset as part of broader strategic prioritisation within Rain. The three-sided system thinking, the two-sided marketplace instincts, and the “automation with transparency” design principle carried into everything that followed.

Reflection

What I learned designing a product I also used.

To better understand the creator experience, I created a Room on TradingRooms. That wasn't just a test account — I was a creator on the platform I was designing. That dual perspective changed how I thought about the product. Designing the Room creation flow, I knew exactly where the friction was because I'd felt it myself.

The broader lesson: in marketplaces, the designer needs to understand both sides of the transaction at depth. The experience of the Room Creator directly shapes what the Room User sees, trusts, and acts on. Optimising one side in isolation breaks the other.

What I'd do differently: more structured validation of the trust threshold before building. What does it take for a first-time user to hand over trade execution to a stranger on the internet? That's not a UX question — it's a product question. Answering it earlier would have shaped the go-to-market as much as the design.

0→1Consumer FintechTwo-sided MarketplaceAutomationTrust Design