AI features inside an institutional investment platform
Institutional investors were offered a chat box and asked to change how they work. I put the AI touchpoints inside the surfaces they already use, and specified the patterns state by state so the team could ship.
Senior Product Designer. Interaction design, working prototypes, and the delivery spec.
Institutional allocators and fund managers. Sophisticated, time-poor, sceptical of automation.
Ongoing. AS-IS audit through specified states and prototypes.
Designed in Claude Design on the current design system, and shared with engineering through Claude Code.
01 — Context & my role
The platform serves private capital markets: allocators and fund managers running diligence, tracking managers, and preparing for investment committee. Their work is documents — memos, reports, meeting notes — and the decisions that come out of them carry real money.
AI had arrived in the product as a chat panel bolted beside that work. I was the designer on the AI surfaces: the audit of what existed, the interaction patterns, the prototypes in code, and the spec engineering built from.
It was built with the product team rather than handed to them. Regular conversations about how clients actually work located where AI was worth putting: report editing. With the data already in the platform, a report can be generated more precisely, and the value is in what happens next — editing and refining the generated paper in place. That is where the team told us it mattered, and that is where the surfaces went. The feedback so far is qualitative; nothing is measured yet.
The work is still shipping, so this case is illustrated with the wireframes from the delivery spec rather than product screenshots. Labels are invented; structure, states and behaviour are as specified.
02 — The problem
Two problems, not one. The composer asked the user to choose before they could ask, and a single chat panel was answering two situations that need different behaviour.
Every existing AI state catalogued against the surfaces it appears in — the overloaded first layer and the missing correction path are findings, not opinions.
Product sits closest to these clients and the field is narrow. What the experience had to do was decided on their feedback rather than on a generic AI-chat pattern.
Where questions arise — in a report, a document, a meeting note — mapped against where the AI lived. The gap between the two is the placement argument.
I audited the as-is composer and thread. The first layer of the composer carried too much: a shortcuts row and an all-shortcuts grid, a context picker, a source selector, research, web, history, workflows and send — all exposed before the user had typed anything. Choosing was harder than asking. And once something was selected — a document, a team, a generated output — it was rendered inside the composer itself, mixed into the text the user was still writing, so the question and its context were indistinguishable.
Ask anything…
The as-is composer. Nine controls on the first layer, and selected context rendered inside the input. Drawn in grey throughout; every redesigned bar further down is drawn in ink.
The second problem was entry. Chat was treated as one destination, while users arrived at it in two different situations: asking about something they were looking at on a page, and changing something inside an output they were already editing. Those need different behaviour, and the as-is design gave them the same one.
The question is always about one of these.
It knows the product. It does not know where you were.
Leave the surface. The answer is not where the work is.
Describe it again. Re-type context the platform already had.
Take back an answer with nothing attached. No provenance, and no way to correct a wrong step short of starting over.
Where the work happens on the left — reports, documents, meeting notes — against where the AI lived on the right: one chat panel with no context attached. Below, the three costs that fell on the user every time.
03 — Constraints
04 — Process & key decisions
The work is ongoing and the method was not set out in advance. So far it has moved through four stages: the audit, the placement decision, the state specification, and prototypes built against the system.
Every AI state that existed, catalogued against the surface it appears in.
Where questions actually arise, mapped against where the AI lived.
Every control written out state by state. The inventory is section 06.
Each surface built as a working frame on the current design system, not the drifted one.
Centralised on the left: four destinations feeding one panel that holds no memory of where the user was. Distributed on the right: the same four surfaces, each with its own entry point already attached to what it sits in, and what the move gained and cost underneath.
05 — The solution
One field for the question, and two doors into the chat instead of one.
Two moves. The composer's first layer comes down to a prompt, a plus, a model selector and send — commands live behind / and context behind +. And everything the user has attached moves out of the input into a row of context tags below it, where it stays visible without competing with the question being typed.
One prompt, a plus for context, the model, send. Commands sit behind the slash the placeholder names and context behind the plus — the figure opens that second level and closes it again.
Why — the dashboard is where open questions start, and it was the one surface with no room for a new column, so the composer had to sit in the existing composition.
The entry point sits in the report and already knows what it is reading.
Why — the question a user has about a report is about that report. Asking them to restate it in a side panel is asking them to describe context the platform already holds.
Action: follow up with the manager on the allocation question.
Action: send the revised allocation question before the committee date
Inline editing, with human-in-the-loop review before anything is saved.
Why — notes become the record other people act on. Review is the state that makes generated text safe to keep.
Neither answer is worth much if the output cannot be trusted or fixed. The response streams with its sources attached, and a passage the user disagrees with is edited in place rather than re-prompted.
Progress shown honestly, with provenance attached as the answer arrives.
Why — an unattributed answer is worse than no answer for this audience, so the source arrives with the text rather than after it.
06 — The states
The composer was specified as twenty-six frames across six families, each carrying the one line an engineer can pass or fail.
The first layer is a field, a plus, a model read-out and send. Everything behind it has states of its own, and most of them had never been drawn: an attachment that fails to upload, a picker on first run with nothing to pick, a microphone that is not there, a model control that disappears when a flag is off.
Where the machine already had numbers, the spec uses them rather than approximations: a 120-second recording cap, a countdown that appears with fifteen seconds left, a 44-bar waveform. Seven keyboard bindings are written out as a contract, and Escape is still an open question — two panels can be open at once, and only the innermost should close.
Passes when — the field grows to its cap and then scrolls; the toolbar row never leaves the bottom of the bar, and the attachment bar stays attached beneath it.
board-pack-final.pdf could not be read. Remove it or try a different file.
Passes when — the failed badge is destructive and keeps its ×, and the reason is spelled out below the bar rather than in a toast.
A target-state board is only half a spec. Eight parts of the composer exist today, and each one carries a disposition. Two of them are marked decide because they are genuinely open: whether the plus keeps sources mutually exclusive the way the old dropdown did, and what happens to the two sources that are written into the spec but have no endpoint behind them.
07 — Impact
The surfaces are rolling out, so what can be claimed today is structural: three things are true of the design that shipped. Adoption and time-to-answer are being measured and I would rather publish them once than estimate them here.
Adoption and time-to-answer are being measured as the surfaces roll out. I'd rather publish those numbers once than estimate them here.
08 — What I learned
09 — What this case doesn't cover
The work is live and unfinished. Five things are outside what is shown here.
Let’s build AI into a product with the structure to grow it.
AI changes how a product behaves, not just how it looks. I design the surfaces, specify the states behind them, and leave a structure the team can extend rather than rebuild.
Let’s talk