Watch a relationship manager place an order and you see the actual job. They are not browsing. They have a client on the phone, a number in their head, and a compliance window closing. The interface is standing in the middle of a conversation.

Three things were costing them time.

I led design with one junior designer reporting to me, and built the frontend and the coded component library myself against APIs from a separate backend team. That shaped how I spent my time: I kept the decisions that set direction, the order shell, the onboarding model and the system architecture, and handed over work that would grow the junior designer, reviewing it before it reached the build.

By screen count, I designed about 80% of what shipped and the junior designer about 20%. Within two months they were owning flows on their own and shipping them without my edits.

Being clear about these early is what kept the work honest. None of them were negotiable.

• KYC is statutory. CVL KRA registration, FATCA and CRS declarations, nominee records and BSE STAR MF onboarding are legal requirements, not form fields I get to trim for elegance.
• PAN and client name are immutable once a client record exists. That is a regulatory and database fact, and the interface has to carry it.
• Twelve asset classes hold genuinely different data. A mutual fund has an ISIN, a NAV and an AMC. A pre-IPO holding has a lot size and a settlement date. Insurance has a premium term. Forcing them into one schema is a lie that surfaces later as an error.
• One screen, four roles. An in-house RM, a distributor, a distributor’s employee and an intern all see the same page with different data scope.

The same page is read by four people with four different rights to the data on it. Getting the scope wrong does not produce a bad layout, it produces a compliance incident.

Six inputs shaped the brief, and they disagreed with each other in useful ways. Advisors described one problem, the support queue described another, and the codebase held a third that nobody had written down.

In total: 10 interviews, 20 shadowing sessions over six weeks, about 100 tickets, and three rounds of testing with 10 advisors. I planned the research and led synthesis; the junior designer supported it, taking notes and helping synthesise.

Watching the existing flow in use is where the drawer decision came from. The problem was never that the onboarding form was long, it is long because the law says so. The problem was that it lived somewhere else, and the advisor had to abandon a live conversation to get to it.

The codebase was the input nobody expects. Stakeholders describe the happy path; nobody volunteers the sixteen ways an order gets stopped, because those rules live in the implementation and in support tickets rather than in anyone’s head. I read the Add Order implementation and enumerated every gating condition it enforced, separating what blocks an order from what merely warns. That list became a design artefact, MF Place Order, Conditions & States, and it is why the flow holds up under real data.

Every number on this page, before and after, with where it came from. One is still open, and I would rather show that than fill it.

Three hypotheses came out of the research. Writing them down as bets rather than requirements meant each one had a visible way to be wrong, and each maps to a decision further down this page.

Sixteen modules, with the order pipeline carrying the weight. The navigation is flat on purpose: an advisor mid-call should never have to remember which parent a screen lives under.

The obvious move is a screen per asset class. I resisted it. Twelve screens is twelve maintenance burdens and twelve chances for the pattern to drift.

So the asset class became a filter, not a destination. One table shell: identity columns (order number, date, client, distributor) hold still, and the product-specific columns resolve per class. The status vocabulary is shared across all twelve, so Open, Pending, Completed and Cancelled mean the same thing whether you are looking at an insurance policy or a bond.

This is the change behind the 6× number, and most of it is not about the form itself.

The old flow sent the advisor away to onboard the client, and the order context died on the way. So the entire UCC journey moved into a drawer that opens over the Add Order screen. Look at the screen at the top of this page: the Add Order list is still there behind the drawer. The advisor never left.

The drawer is titled Update Profile rather than Onboarding, and the distinction matters. The client record already exists with a client code. What is missing is the UCC, the BSE STAR MF code that lets that client transact in mutual funds. So the job is not creating a person, it is completing a person, and the title says so.

Inside, the journey is sequenced by dependency rather than by convenience: Client Details, Bank, KYC Capture, Nominees, Documents, FATCA, Review. Each section carries one line explaining why it exists, like “These details create the client record and link a Mutual Fund investor profile.” That is not decoration. An advisor who understands why a field is required stops raising a support ticket about it.

Two details matter more than they look:

• Save & Exit sits beside Save & Continue. Onboarding a real client takes two phone calls and a document scan. A flow that cannot be paused is a flow that gets abandoned, and an abandoned flow is a lost order.
• Locked fields explain themselves. PAN and client name render disabled with an inline note saying they cannot change after creation. The alternative, letting someone type and rejecting it on submit, is the same constraint delivered as a failure.

The final step does not say “Success”. It says what actually happened, and names the registries it happened in.

Data-heavy B2B products do not fail on the happy path. They fail at three in the afternoon when a filter returns nothing and the user cannot tell whether the system is broken, still loading, or simply correct.

So every Order Management screen has a designed empty, loading and error state, plus selection with bulk actions and a filters-applied variant. They are named frames in the file, not afterthoughts left to implementation.

The revenue sheet carries commission structures for every product category that pays one, and 1,710 mutual fund schemes underneath the first of them. Rendered flat, it is not a table, it is a wall.

The list from the code audit had sixteen entries: seven validation toasts, six inline scheme and amount alerts, three blocking states inside the form. They fold down to six decision points on the main path, any of which can stop an advisor mid-call.

The left column below is the path when everything passes. The right column is what the advisor sees when it does not, and how they get moving again without leaving the screen.

Every one of the sixteen got its own response rather than sharing a generic error. The full set lives in one documentation frame, so engineering and design were arguing about the same list.

Prototypes went in front of real advisors before engineering built anything, and what they did changed the flow. The numbers below are from those sessions; the two rows after them are the changes I would point to first.

None of this scales without a shared vocabulary. I built the component library and token set from scratch, shared across NeoFinDesk and InvestValue Capital.

It runs to 53 component families and 2,077 variants, built on explicit variant properties (size, style, state) rather than duplicated layers. Two of those families are not components at all, they are usage documentation, because a library nobody knows how to apply drifts within a quarter.

The tokens are semantic rather than literal. The value is --color-bg-brand, not --color-blue-600. That is the difference between a theme you can change and a find-and-replace you have to survive.

Leading meant more than the screens: growing the junior designer, setting the team’s working rhythm, and holding a position when it was contested.

I handed over ownership in stages over about two months: research support first, then the system’s states, then whole flows.

Three bets, three different states of evidence. I would rather list them that way than dress the unmeasured ones up as results.

• H1, onboarding in a drawer: 6× faster. About 30 minutes, often finished on a call-back the next day, down to under 5, measured by system timestamps over the first three months after launch. The mechanism matters as much as the number: the advisor stopped losing context, and a flow that can be paused stopped being abandoned.
• H2, one shell for twelve classes: shipped, judged by absence. The falsifier is a class that needs its own screen, or a per-class exception to the shared status vocabulary. Absence of that is weak evidence, and I present it as that rather than as a win.
• H3, designed states cut support load: not yet measured. The sixteen states are live. The ticket comparison against the previous quarter is the next thing I want from ops, and until I have it this bet is a bet.

The platform serves 540 or more institutional and distribution partners. That is the scale the design has to hold at, not a result of the design, so it lives at the top of the page and not here.

Three things I am not satisfied with, in the order they bother me.

• The seven-step stepper is honest but daunting. Showing the full length is the right call for trust, but it still reads as long on first contact. I would test a two-phase framing, identify the client and then satisfy compliance, to shorten the perceived distance without hiding anything.
• The dashboard serves the power user well and the new distributor poorly. It is dense because experienced RMs asked for density. A role-aware default layout is the obvious next move, and I should have pushed for it sooner. The single-segment donuts under Product Wise AUM are the visible symptom: a chart with one slice is a number wearing a costume, and it should render as a number.
• Partial failure is still underspecified. I covered empty, loading and error thoroughly. But the real multi-issuer failure mode is one issuer’s API being down while eleven are fine, and the interface does not yet say that clearly. That is the next piece of work.