Investment Baskets

Q3 2024 · Product Designer · designed from scratch

marketfeed · iOS / Android

Curated ETF baskets users can buy in the app, then pledge for a second return.

Team

Parvez Musharraf (Product Manager)
Nikhil DS (Product Designer)

Problem

marketfeed only ran automated options trading. Returns arrived weekly from that one volatile stream, so users felt every fluctuation, panicked on bad weeks and withdrew easily. The product needed something slower alongside it: a long-horizon investment that steadied the account instead of competing with the trading.

It also had to run itself. No one is in the loop at the moment of purchase, so the app had to confirm the order on its own, keep every order and every failure in one place, and explain the broker's rules in plain language when an order could not go through.

Design

1. Explore baskets

Dashboard0:00

0:00 / 0:38

Dashboard to basket detail, ending where the purchase begins.

The app had never sold an investment before. marketfeed only ran automated options trading, so there were no investing screens, no portfolio patterns and no user habits to build on. The landing page had one job: make a new product easy to choose in a single screen.

Sorted by risk, not ranked by return. The baskets are tiered by risk and horizon, from a debt-only Conservative Model at the low end to an equity-and-gold Growth Model at the high end. Every card carries the same four things — risk, horizon, current basket value, and return since inception — so users compare the baskets in the list instead of opening each one.

The detail sits one level down. Basket detail splits into two tabs, because two different questions need answering. ETFs and Weights covers what you are buying: each holding, its weightage, its 3Y or 1Y CAGR, the rebalance frequency and the next rebalance date. About covers who is behind it, down to the named SEBI-registered analyst and their registration number. Nothing is removed, only sequenced.

The full explore path: dashboard, the basket list with each risk tier, basket detail with ETFs and weights, then the amount screen — The whole choice in one screen: the risk tiers, then the ETFs, weights and rebalance dates behind whichever one a user opens.

2. Purchase

Enter amount0:00

0:00 / 0:50

Review to confirmation, then the order tracked to execution.

The flow. Amount entry with live unit estimation, review, confirm — picked up here from where the last recording ended.

No one is in the loop. Purchases execute without a person on either side, so every failure has to explain itself at the moment it happens. That constraint is where most of the design work went.

Every basket order can be multiple ETF orders. A purchase places one order per ETF in the basket and each fills independently, which is why partially fulfilled is a state users have to understand rather than a rare error. The confirmation screen shows the orders initiating one by one instead of a single spinner.

Broker rules appear where they bite. Review Order carries the rule and the reason for it: one basket order per day, because IIFL settles margin at end of day and that can move the user’s available balance. A user meets the rule before the order instead of discovering it in a rejection.

The happy path: amount, review order, orders initiating one by one, order initiated successfully, then Order History — Amount to confirmation, with each ETF order initiating separately before the basket is placed.

Review Order in three market states: market open, market closing in fifteen minutes with a countdown, and after market hours — The same Review Order screen in three market states. Near the close it carries a countdown; once the market shuts, the order is queued for the next open rather than blocked.

Amount field states: focus, below the minimum, cleared, short of funds with the add-funds walkthrough, an active order in progress, and multiple basket orders not allowed — The amount field carries more states than the happy path. Each error carries its own fix, and the one-order-per-day rule surfaces here too, as an active order in progress or a second order refused.

3. Order states

The amount field has more states than the happy path suggests — below the minimum, cleared, short of funds — and each error carries its own fix, so the recovery happens in place. The rejection turns on one question, whether the user has enough money, and routes to the shortest recovery from each answer. The order states cover everything an order can end up as — fulfilled, partially fulfilled, rejected, waiting for market, cancelled — and each one names its own next step: pledge once filled, retry only the failed orders on a partial, retry the whole order on a rejection, cancel while it is still waiting.

Order History states: fulfilled, partially fulfilled, rejected, waiting for market, and cancelled, each with its own action — Every state an order can end up in — fulfilled, partially fulfilled, rejected, waiting for market, cancelled — each carrying its own next step: pledge, retry the failed orders, retry the whole order, or cancel while waiting.

Order rejected flow: a decision point splitting into retry directly, or add funds in the broker terminal and then retry — A rejection turns on one question, whether the user has enough money, and each answer routes to the shortest recovery from there.

The partially fulfilled path: filled and failed legs listed separately, then retry, with an add-funds detour when the balance is short — A partial fill keeps what executed and retries only what did not, with the add-funds detour folded into the same path.

Order cancellation: waiting for market, the confirmation sheet, order cancelled, and the cancellation failed state — Cancelling is permanent, so Keep Order is the filled primary — and cancellation can itself fail, which the screen says out loud rather than hiding.

4. Pledge

Collateral rules0:00

0:00 / 0:33

The pledging rules, then the handoff to the broker’s app once the order fills.

A filled basket is not the end of the flow. The same holdings can be pledged for trading margin, which is what makes the capital earn twice — the reason baskets sit inside a trading product rather than beside one.

Explained before it is regulated. Pledging arrives as a model people already hold — “like getting two returns from the same capital, similar to pledging your gold and getting cash without paying interest” — and only then as collateral type by basket, the haircut, a 10% liquidity buffer, and the 40% non-cash limit.

Pledging happens in the broker’s own app, and only three days after execution. marketfeed cannot complete it, so the screen does the next best thing: it states the eligibility window up front, sets the expectation — up to 90% extra margin, holdings stay in the user’s Demat, margin in 24 to 48 hours — lists the five steps including the OTP, and hands off with a deep link. When the final action in your funnel happens in someone else’s app, the handoff has to be the most explicit screen in the flow.

The order fulfilled confirmation, carrying the unlock-extra-margin offer and the entry into Pledge Holdings — The moment an order fills is also the moment pledging becomes possible, so the margin offer sits on the confirmation itself.

5. Ownership

Basket composition, ETF selection, weightage and rebalance rules belong to the Portfolio Management team. Mine is everything between that portfolio and the user: how it is understood, compared, bought, recovered when it fails, and pledged afterwards.

Outcome

₹110 Cr of ₹330 Cr, by March 2025. From launch to March 2025, a third of the platform’s AUM moved into Investment Baskets — the long-horizon counterweight the account never had.

And it did not sit there. Users pledged those holdings for trading margin, which is what the product was built to make possible: the same capital earning long-horizon returns inside the basket and weekly returns in the options that margin funds. Basket to pledge to trade, running end to end.

What's Next

Pledge Transparency

An in-app view of how much is pledged, and an easy way to track it.