Bringing Lucid AI Out of the Canvas

Lucid is a visual workspace: Lucidchart for diagramming, Lucidspark for whiteboarding. The docs list is home base. It is where every document lives and where every session starts.

Lucid AI existed before this project, but only inside the editor canvas, working on one open doc at a time. The docs list, where you decide what to open in the first place, had no intelligence at all.

Docs list search ran your keywords against document titles. If you remembered the exact name, you found your doc. If you remembered anything else about it, who worked on it with you, roughly when, what was inside, you were out of luck. Advanced filters existed but were hidden, slow to fill out, and still could not see inside a doc.

The team defined the metric before any design work: search-to-open success rate. A search works if you open something it surfaced.

Two things went to general availability on August 5. The AI chat panel was my design end to end: a docked side panel that expands to a full page, carrying three skills at launch. Find docs, Summarize, and Build a diagram.

The second piece is the AI summary section inside the regular search bar: direct answers above the keyword results, triggered when a query runs four words or longer. My manager led that design. I contributed ideation and some of the UI.

The problem was already validated when I joined, so my research was evaluative, not generative. I ran 20 interviews with external users across the US, UK, Chile, India, and New Zealand, putting concepts and iterations in front of them to answer two questions. Are we building the right thing. Can people use it.

Every design round went back in front of users. The loops stayed short because the questions stayed small.

The entry point is an AI icon directly beside global search. People already look there when they are looking for something, so the new capability sits exactly where the old habit points. No new surface to discover, no education campaign. A one-time callout introduces it, then gets out of the way.

I prototyped four layouts in code and tested them: side panel, modal, floating panel, inline bar. The side panel won because it kept the docs list usable while you asked. You could see the results it referenced without the answer covering them.

Clicking a skill tile in the zero state does not run the skill. It returns a hardcoded explanation of what the skill can do, with concrete examples and quick-start chips. These are brand-new capabilities, and the first click is the best teaching moment you will ever get. I accepted a slower first turn so people learn what each skill can do and get more from every turn after.

Find docs is the clearest case: it searches by content, date, and collaborator. None of that is guessable from an empty text box.

Testing pushed the result count from a fixed 3 to up to 7, chosen by the AI on confidence. The existing 24px button component bloated at that count, especially in the 400px side panel. So I designed a 16px inline component: a doc chip plus a one-line description, keeping a full result set scannable in one glance.

Collaborator was the detail people remembered most, and the one free text handled worst. I designed an @-mention that resolves the person before the search runs: autocomplete mid-type, a resolved chip in the query. It removes a whole class of failed searches instead of improving their error message.

Research kept surfacing the same anxiety: what is this thing reading? So every response names the skill that ran, as a pill on the message, and shows what it searched in an expandable chip. Searched users, plus two more. Tap to see the full list. Trust came from receipts, not reassurance.

Generated work follows the same principle of staying in your control. Build a diagram creates in a new tab and returns a clickable chip. The canvas never ambushes you; you choose when to enter it.

Midway through the summer, Lucid ran its internal hackathon. My team entered the AI category and took third place.

What we built stays inside Lucid. The prism below stands in for it: a glass pyramid raytraced live in your browser by a WebGL2 fragment shader I wrote for this site, with real refraction, dispersion, and total internal reflection.

Every decision on this project traded off speed, cost, and usability. Being technical enough to hold those conversations with engineers changed what I could design: the working-state reuse, the confidence-based result count, and the teaching turn all came out of those trade-off discussions, not from a spec.

We shipped fast because feedback was constant. Users saw every round, engineering saw designs days after they existed, and nothing waited for a big reveal. The speed came from communication, not from skipping steps.

The honest limitation: the editor assistant and the docs list assistant do not share context yet. Closing that gap is the obvious next chapter.