AI Copilot UX: Sidebar Panel or Inline Suggestions

For most AI copilots, inline suggestions beat a sidebar panel. Put the suggestion next to the field it would change, and let a person accept it with one click or one key. Keep a sidebar only for questions that have no single field to land in, like which deals slipped this month.

A copilot is usually the reason an AI-native product exists, and the reason it raised, which is why this placement decision carries more weight than it looks like it should. If the useful output sits in a panel people do not open, the product looks like a chat window bolted onto a CRM. The founder knows where the good answers are. His users do not.

The Oct 14 suggestion that sat three scrolls down

Picture a CRM built for small sales teams. A rep opens the deal page for Northwind Logistics. On the left are the fields: Stage set to Negotiation, Amount $48,000, Seats 10, Close date Sep 30. Below them is a Notes box. She types her call notes: legal review pushed to mid October, buyer wants two more seats.

On the right is a 360px panel with the label Ask Copilot at the top. It holds a thread from last week. First an account summary, then a list of open tasks, then a draft follow-up email. Three scrolls down, under all of that, the model has added a new message. It reads: based on your latest note, consider moving the close date to Oct 14 and the seat count to 12.

That is exactly right. It is also invisible. The rep never scrolls the panel, because she is typing in the Notes box. The close date stays at Sep 30. On Friday the pipeline review counts Northwind in this month's forecast, and the forecast is wrong. The copilot did its job. The interface put the answer somewhere the work was not.

What the founder sees from his side

The founder built the panel in two sprints and demos it on every sales call. He opens it, types what changed on this deal, and the answer is sharp every time. He has shown it to his board as the core of the product.

His usage dashboard tells a smaller story. It counts panel opens per week, and the line is flat. So he adds a pulsing dot to the Copilot button. Then an announcement email. Then a tooltip on first login that points at the panel. Each change bumps opens for a week and then the line settles back. He reads this as an awareness problem. It is a placement problem. People are not ignoring the copilot. They are busy in the fields, and the copilot is talking to them from across the room.

Why the sidebar versus inline debate starts in the wrong place

Most advice on this question treats it as taste. Sidebars for depth, inline for speed, offer both and let users choose. That sounds balanced and it ships a chat product glued to the side of a host tool. Our view is simpler and less polite: the default is inline, and the panel has to earn its space.

The test is where the output lands. If a suggestion ends in a change to one field, one sentence, or one row, it belongs next to that field, sentence, or row. Making someone read it in a panel and then retype it on the left is a copy and paste job you designed on purpose. If the output has no home on the current screen, a panel is fine. Most copilot output in a CRM, an editor, or a project tool has a home. That is why most of it should be inline.

This is the same idea as contextual prompts in feature adoption work, with one difference. A feature prompt points at a tool. A copilot suggestion is the finished change, so the cost of putting it in the wrong place is higher. It is not a hint the user missed. It is work the model already did and nobody used.

When a sidebar panel earns its 360 pixels

A panel is the right call in four cases. Each one is about the shape of the task, not about how clever the model is.

• The question spans many records. Which deals over $20,000 have not had a call in two weeks has no single field. It needs a list, and a panel is a good place for a list.

• The work takes several turns. Drafting a proposal, where the rep says shorter, then more formal, then add pricing, needs a thread. Inline suggestions cannot hold a conversation.

• The user needs to compare. Two versions of an email side by side, or the old and new forecast, need room that a field does not have.

• The model is acting, not suggesting. If it is updating twenty records, the user needs a place to watch the steps and approve them. Our post on designing for AI agents covers that review pattern.

Even then, the panel should push its results back into the page. If the panel finds three stale deals, each one should link to the deal and highlight the field that needs attention. A panel that only talks back to itself is a second product living on the side of the first.

Ghost text or a chip: match the suggestion to the field

Inline is not one pattern. It is at least two, and picking the wrong one causes its own problems.

Ghost text is grey text that appears after the cursor while someone types. Tab accepts it, and typing anything else makes it vanish. It works where accepting and ignoring both cost almost nothing, such as the Notes box, an email body, or a code editor. The user never has to stop to say no.

A chip is a small labelled button beside a field. Under the Close date on Northwind it would read Oct 14, from today's note, with Accept and Dismiss. Chips suit structured fields where a change has knock-on effects. A close date moves the forecast. A stage change can trigger a task for finance. Those should never fill in silently as ghost text, because one stray Tab rewrites the pipeline.

Two rules keep chips honest. Show where the suggestion came from, so the rep can check it in a second. And when one note implies several changes, show them as one grouped chip with a short list, close date and seats, so she accepts or rejects the pair together.

Let the host tool's layout decide

The screen the copilot lives in already has a shape, and that shape should settle most of the argument. A CRM deal page usually has a right rail for activity. A 360px copilot panel either covers it or squeezes the fields into a narrow column. Either way the product gets worse at its original job.

A document editor is different. The text is the main surface, so ghost text in the body and a small menu on selected text do most of the work. A table or grid view is different again. Suggestions belong in the cell, as a dot or a chip the user can review row by row. A dashboard has no input at all, so a sentence under each number, written by the model, does more than a chat box beside it.

A quick way to check: take a screenshot of your busiest screen and draw a circle around where the user's eyes are when the copilot has something useful to say. If the circle is not where the suggestion appears, the layout is fighting the model.

Count accepted suggestions, not panel opens

Panel opens measure curiosity. What you want to know is whether the copilot changed anything. The number for that is acceptance rate: suggestions accepted divided by suggestions shown, tracked for each field and each surface.

There is evidence this is the number users feel, too. A study of GitHub Copilot users found that the rate at which shown suggestions are accepted drove how productive developers felt, more than whether the code survived later (Ziegler and colleagues, 2022). That was measured on code completion, not on CRMs, but the logic carries. People judge a copilot by how often it hands them something they keep.

Log four events for every suggestion: shown, accepted, dismissed, and edited within a day. A chip with a high dismiss rate is wrong, noisy, or badly placed. A suggestion that gets accepted and then edited is close but not trusted. Both are design findings you can act on, and panel opens will never show you either one.

The money side is sharper for AI products than for older software. Measured on AI companies, gross margin runs around 52 percent against 70 to 80 percent for traditional software, because every model call sits in cost of goods. Each suggestion generated in a panel nobody reads was paid for and did nothing. Moving the same output inline does not cost more to run. It just stops wasting the spend.

What to change this week

You can do this without a redesign project. It takes a few days and your own logs.

• Pull the last two weeks of copilot output and sort it by what it asked the user to do. Most of it will be a handful of repeated suggestions.

• For each one, write down the field, sentence, or row it would change. If there is one, it goes inline. If there is none, it stays in the panel.

• For every inline candidate, pick ghost text or a chip. Free text gets ghost text. Anything that moves a forecast, a status, or money gets a chip with a source line.

• Add the four events: shown, accepted, dismissed, edited within a day. Report acceptance by field, not as one blended number.

• Watch five real sessions with the panel closed. Note every moment the copilot had something to say and the user was looking elsewhere.

• Keep the panel for cross-record questions and multi-turn drafting, and make each panel answer link back to the record it is about.

If you want more on the first thing a copilot says when someone does open the panel, our guide to conversational UI and the first response picks up there. If you are weighing outside help, this list of product design agencies that work on AI copilots shows what to ask them.

Studio Maydit is a product design studio for AI founders, and copilot placement is a common finding in our work. The model is usually good. The screens around it were designed for the founder, who already knows where to look. We map where users' attention actually is, move suggestions to the field they change, and set up the acceptance numbers so you can see the difference. Fixed-scope projects run three to four weeks and end with a diagnosis of what is leaking in the product. If your copilot does great work that nobody accepts, book a 30-minute call with Studio Maydit.