Where AI lives in an institutional investment platform — Nayara Marques
AI surfacesAI platform · private capital markets2026

Where AI lives in an institutional investment platform

The platform's AI lived on a separate chat page and answered every question the same way. I moved it into the surfaces where allocators and fund managers already work (the dashboard, reports, documents and meeting notes) and gave it two modes: analysis, for asking about what is on screen, and edit, for changing it with a review step. The composer (the box where users type to the AI), the two modes and the review step are now components in the design system, so engineers and AI tools build the next AI screen from them instead of drawing new ones.

The platform's AI lived on a separate chat page. I moved it into the screens where allocators and fund managers already work, with two modes: analysis, to ask about the screen, and edit, to change it.

Role
Senior Product Designer. Interaction design, working prototypes, delivery spec.
Users
Institutional allocators and fund managers: time-poor, sceptical of automation.
Timeframe
2026, ongoing.
Built
In Claude Design on the current design system, handed to engineering through Claude Code.

01 — Context & my role

Allocators and fund managers use the platform for diligence, manager tracking and investment committee prep. Their work is documents, and the decisions carry real money.

AI had arrived as a separate chat page, one click away from that work. I was the designer of every place where users meet the AI. I audited the existing AI, decided where it should appear, designed how it behaves in each place, built coded prototypes and wrote the spec engineering built from.

I worked alongside the product team, who held the client relationships. Their conversations with clients showed where AI was most useful: helping users refine the reports the platform generates from its data. The feedback so far is qualitative, from those conversations.

The work is still shipping, so the figures are wireframes from the delivery spec, with invented labels. The composer, the box where users type to the AI, has its own case covering all its states: Composer spec.

02 — The problem

The audit and client feedback showed two problems, one about where the AI lived and one about how it behaved.

AI lived on its own chat page. Using it meant leaving the report, and the AI knew nothing about where you came from. People came to ask about what they saw, or to change what they were working on. The chat treated both the same.

Problem A: AI as a destination

Dashboard
Reports
Documents
Meeting notes
AI chat
AI chat
How can I help?
Ask anything…

The AI chat before the redesign. The AI had its own item in the navigation and its own page, with one input box and nothing else. A user reading a report had to leave it to ask anything, and arrived on an empty page.

Using the separate chat cost the user three things on every question.

The answer is not where the work is. Re-type context the platform already had. The answer came without its sources, and if the AI got one step wrong, the only fix was to start the conversation again.

Problem B: one behaviour for two situations

Users came to the AI at two different moments, and each needs different behaviour.

While reading, comparing or checking, the user wants information, and the page should stay as it is. While rewriting, correcting or restructuring a report, a document or meeting notes, the user wants a change. They need to see it, review it and be able to undo it before it is saved for others to read.

Where the problem came from

I catalogued every AI state in the product as it was. The audit found the separate chat page, and found no way for users to correct an answer. The platform has a small number of institutional clients. The product team talks to them most often and passed on what they asked for. I compared where users' questions come up in their work with where the AI was. That comparison decided where the AI should appear.

03 — Constraints

Four conditions shaped the work: who set the direction, how many places the AI had to live in, what happened to anything the AI changed, and which copy of the design system could be trusted.

The requirements came from what clients told the product team, so the design had to answer those requests first. If the AI behaved differently in each of the four places, users would have to learn it four times. So every entry point had to behave the same way and share the same components. Other people act on reports and notes. Any AI change had to be reviewed before it was kept, and recoverable after. The copy of the design system in the codebase was out of date, so I built the work on the current version, which lived in Claude Design.

04 — Process

The work has gone through five stages so far. Each stage followed from what the previous one found; there was no fixed plan at the start.

I listed every AI state in the product and where it appeared.I decided where the AI should appear on each surface.I separated analysis from edit and defined how each behaves.I built a working coded prototype of each surface on the current design system.I added the new patterns to the design system as components with rules.

05 — The solution

This section shows where the AI now appears in the platform, then how it behaves in each of its two modes, analysis and edit.

Entry points

In the proposed solution the AI appears in four places. On the dashboard, users ask questions that are not about one file. Inside a report, a document or meeting notes, the AI already knows which file the user has open, so they can ask about it without explaining what it is.

A user's question about a report is about that report. On a separate page, they had to describe the report again, although the platform already had it.
Chat centralised · previous work
Dashboard
Reports
Documents
Meeting notes
Leave the surface
One AI panel
Knows nothing about where you were
Chat distributed · proposed solution
DashboardComposer
ReportsIn context
DocumentsIn context
Meeting notesIn context

Previous work and proposed solution. In the previous work, each of the four surfaces sends the user to one chat page. In the proposed solution, each surface has its own entry point to the AI, so the user asks from the page they are working on and stays there.

Analysis mode

Analysis mode is for reading: comparing figures or checking a report. The composer is shown on top of the page (the dashboard, a team view or a report) and already knows what is on it, so the user can ask straight away and carry on reading.

Asking a question never changes the page. For a longer conversation, the user can expand the composer into a full chat that stays attached to the page. Every answer shows its sources: allocators and fund managers make decisions with real money, and an answer they cannot check is worse than no answer.

Analysis modeReport · Q3 manager review · 4 of 18
Ask AI

Attached: this report · Q3 manager review · 18 pages

Summarise this page Compare to prior quarter Flag inconsistencies
Ask about this report
Ask AI

Analysis mode. When the user is reading a report, they don't need to leave the page. The AI is already in context, attached to this report, and helps with whatever they need while they read, without changing the report.

Why: It lives here because reading the report is the task the user is doing.

Edit mode

Edit mode is for when the user is changing their work. They are building a report, a document or meeting notes, and need help refining parts of it.

The user opens it from the toolbar of the file they are editing. Inside edit mode there are two ways to edit, and both are open at the same time. Inline, the user refines the AI output line by line, right in the text. In the edit chat beside the file, they describe a larger change in their own words, and the AI proposes it in the chat, where they accept it. Either way, the user sees the new wording next to the original before anything changes. Nothing is saved until the user has reviewed it, and every accepted change is saved as a version they can go back to.

Edit mode works the same way in reports, documents and meeting notes, so users learn it once.

Report editing modeDocument editing modeMeeting notes editing mode
Report · Editing modeQ3 portfolio review

Returns were mixed across the portfolio.

Private credit held up, while buyout funds lagged.

AcceptKeep mineInline edit
Meeting notes · Editing modeManager call

Follow up with the manager.

Send the revised allocation question before the committee date.

AcceptKeep mineInline edit

Inline edit, inside edit mode. The report and the meeting notes are AI output. With edit mode open, the user refines them line by line: the AI suggests a new line over the old one, and the user accepts it or keeps their own.

Why: Other people act on these files, so the user decides on each line before it becomes the record.

Edit chatQ3 manager review
Make the summary specific: how much, and who.
Here is the new summary:
Summary

Exposure rose in Q3.

Exposure rose 4% in Q3, led by two managers.

Accept change
Change this report…
Report · Editing mode

Edit chat, inside edit mode. In the same edit mode, the edit chat sits beside the report. The user describes a change, the AI proposes it in the chat, old line against new, and the user accepts it there. The report updates once the change is accepted.

Why: The request, the proposal and the decision stay in one place, so the report stays clean while the user works through a larger change.

Both modes share one composer. Its context tags and all twenty-six states are in the Composer spec case.

06 — Mapped for AI

The patterns from this case are now part of the design system, written so that AI tools can follow them.

Most new screens on this platform are first generated by AI tools. Because the composer, edit mode and the review step are components with rules, a generated screen uses them and never draws its own chat box. Four parts of the design system make generated screens follow these patterns. Three of them existed; the fourth, an automatic check, was missing.

The AI appears on four surfaces, in two modes. Whoever builds a new surface, a person or an AI tool, first picks the mode, then uses that mode's component. In analysis, the AI already knows which page the user has open and never changes it. In edit, the AI shows each change inside the text and never saves it before the user reviews it. When a generated screen contains a part the design system doesn't have, that part is called drift. A reviewer decides whether it becomes a new component with rules, or an existing component replaces it. Generated screens were checked by a person, by eye. This was the missing part: a harness, a set of automated checks, would test every screen against the rules and pass to a person only the questions a machine cannot settle.

How the design system is written so AI can follow it is its own case: Design system. Building that missing harness for other teams is now one of my services: Audit design system.

07 — Impact

The surfaces are still rolling out, so there are no usage numbers yet. The gains below describe what the design changes for users; adoption and time-to-answer are being measured.

Expected gains

Users ask about a report from inside it, with nothing to re-type. Users can check a figure without any risk of changing the report. When they do want a change, they see it and approve it before it is saved. When engineers use AI tools to build a new AI screen, the tools reuse these components, and anything new they draw goes to a person for review.

08 — What I learned

Three lessons, two about the product and one about the practice: where AI goes, why it needs two modes, and what was not mine to build.

Where AI belongs comes before anything is drawn. Get it wrong and every later state is wrong too. Asking a question and asking for a change look alike in a chat, but the first needs an answer and the second needs a review. Naming the two modes and giving each its own behaviour helped users more than any single button in the interface. Coded prototypes answered questions that static screens left open, so I built them. Building the product itself was different: showing an answer as it streams in, passing a task between AI agents and saving versions of a file are hard engineering problems, and that work belonged to engineering.

09 — What this case doesn't cover

The work is live and unfinished, so some things can't be shown yet. These are the gaps this case leaves open, and why.

Adoption and time-to-answer are still being measured. Retrieval, accuracy and prompts. This case is the interaction around the model. It drew on the audit, user feedback and the product team's knowledge of allocators and fund managers. The research itself is not mine to publish. The split fits the product today, based on feedback and workflow evidence, not tested over time. Specified frame by frame in its own case, Composer spec. Only the AI touchpoints. Diligence, manager tracking and reporting are out of scope.
AI product design

Let’s build AI into a product with the structure to grow it.

Adding AI changes how a product behaves as well as how it looks. I design where the AI appears, specify every state it can be in, and leave components with rules that the team can build on.

Let’s talk