FYERS · Trading · 2024–25Hands-on4 min read

Orders: one home for every order

Orders used to be one tab inside the Account Manager. I designed FYERS’s first unified Orders section, every screen on web and app myself, so every kind of order a trader places can be found, tracked and acted on in one place.

The problem: Orders had no home of their own. They sat in one tab of the Account Manager, while each order type, from GTT to smart orders to mutual funds, had its own states and rules.
My role: I designed every Orders screen myself, on web and app, while managing the team, working with the product manager and the developers.
The call: One Orders section for every order type, the same structure on web and app, and each order’s status deciding what you can do with it.
The result: Shipped on web and app in January 2025. FYERS’s help centre documents it today as one unified section, with the same rules on both.

Orders on FYERS Web today, from FYERS’s own help-centre walkthrough

The situation

After placing a trade, the next thing a trader wants to know is what happened to it. Is it still pending? Did it fill? Was it rejected? Can I still change it?

Yet orders had no home of their own. They lived as one tab inside the Account Manager, alongside positions, holdings and funds. And “an order” no longer meant one thing: limit and market orders, after-market orders, GTT, smart orders such as trail, step and SIP, mutual fund purchases and IPO applications each have their own states, and their own rules for what can still be done.

The FYERS Trader Account Manager: tabs for Positions, Orders, GTT Orders, All Positions, Holdings, Funds and Trades, with the orders table below — The pattern Orders replaced, still used in FYERS Trader: orders as one tab of the Account Manager

My role

While managing the team, I took Orders on as its designer: every screen, on web and in the app. I worked directly with the product manager and the developers, from the first structure to the release in January 2025.

Showing only what is possible now avoids dead buttons and errors after a tap, which matters when the action moves money.

The decisions

There was a PRD, but it covered only the basics. I started with the information architecture, took it to the product manager for approval, and the decisions below came out of it.

Three app screens: a mutual fund order awaiting payment with a Retry payment button, smart orders marked Yet to start and Running, and a rejected GTT order — Status decides the action: Retry payment for a fund awaiting payment, live states for smart orders, a rejected GTT order

Three app screens: the Orders list on the Open tab, a pending order’s details with Modify and Cancel, and the modify sheet — In the app: find the order, open its details, modify it

Making change cheap

Orders spans many screens built from the same few patterns: an order row, a status, a details view, an action bar. Even on a shared design system, the usual workflow of wireframes, review, polished UI and more review made every piece of feedback expensive: find every affected screen, update each one, review the lot.

So I went straight to a polished working model, assembled from reusable components inside the project. A change to a shared pattern became one edit instead of a sweep across screens, and stakeholders reviewed something close to the real product, so their feedback was about the real thing.

Faster rounds of changes, with less repetitive screen-by-screen work
Stronger consistency across web and app
Feedback that landed on patterns, so it was easier to absorb

Outcome

Orders shipped on web and app in January 2025, the first time FYERS had one section for every order a trader places. It is still the structure FYERS documents in its help centre: one place to view, track and manage stocks and F&O, GTT, smart orders, mutual funds and IPO, where the web and the app follow the same rules.

The web Orders table with a pending order’s row actions open: modify, cancel, and a menu for symbol details, charts, option chain and market depth — On web, an order’s actions sit on its row

Orders in the FYERS app today, from FYERS’s help-centre walkthrough

What I learned

How finished a design looks is a cost decision, not only a presentation one. I had treated it as a way to control how much detail a review carried. For a connected experience with repeated patterns, a well-built, finished-looking model can be the cheaper place to make changes.
It is not a rule for everything. The right level of finish depends on the problem, how mature the system underneath is, how much the UI repeats, and whether stakeholders need to see the final experience to give useful feedback.
Managing and making don’t pull against each other. Designing a core product myself showed me what the systems and processes we were building actually cost the people using them every day.