Lucid · Product Design Internship
Bringing Lucid AI to the homepage
How might we help people find and act on their work from the homepage when they remember the document, not its title?
- Discover
- Scope
- Prototype
- Release
- Handoff
Discover
Act 01: People remembered the document, not its title
When I joined Lucid, finding documents created a lot of friction, especially for enterprise users who belonged to multiple teams and had years of document history.
The existing search relied on keywords from document titles. If someone could not remember the title, finding the right document became difficult. Their alternatives were to scroll endlessly through recent documents or use advanced filters that many users found confusing and cumbersome.
What people could remember instead of a title. Illustrative, not quotes.
the pricing one with the big comparison table, finance made it I think
our onboarding flowchart, the one with all the red decision diamonds
the offsite retro from spring, three columns of sticky notes
This sparked a key question:
How might we let people find a document by whatever they remember about it?
I started scheduling discovery calls as quickly as possible so I could better understand the problem. Across conversations with users from around the world, I noticed a consistent pattern: people often remembered what a document was about or specific content inside it, but they rarely remembered its exact title.
This created two problems. Users could not translate what they remembered into a keyword search, and document titles alone did not give them enough information to confidently identify the correct result.
Success meant someone recognizing the right document from what they remembered, without ever knowing its title.
Who it was for three kinds of homepage visitor
The enterprise user
Belongs to multiple teams, with years of document history to search through.
The manager
Wanted a faster way to understand what their team was working on.
The product leader
Wanted visibility across the organization and quick summaries of roadmaps and planning documents.
Define
Act 02: Lucid AI could help before users opened a document
Lucid AI already allowed users to generate diagrams and flowcharts inside a document, but none of that natural-language functionality existed on the homepage. We saw an opportunity to bring Lucid AI into this part of the product, helping users find existing work and accomplish more before opening a document.
The starting point the homepage before Lucid AI
- 1Title keywords only
Search matched keywords in document titles and nothing else. - 2Nothing here yet
Lucid AI existed only inside the editor. The homepage had no natural-language entry point. - 3Scroll to find
Without the title, the fallback was recent documents, which run for pages.
Before and after one new entry point, beside search
The old homepage. Search matched keywords in titles and nothing else.
Develop
Act 03: Search was only the starting point
My discovery interviews showed that search was only one of the tasks users struggled with from the homepage. Managers wanted a faster way to understand their teams’ work. Product leaders wanted visibility into what was happening across their organization and quick summaries of roadmaps and other planning documents. More broadly, users wanted the assistant to help them get started, not only find files.
That expanded the scope of the project. We rapidly prototyped and tested more than 20 potential capabilities before narrowing the experience to four core skills: Find docs, Summarize, Build a diagram, and Catch up.
Ideation twenty candidates, from the design file
Twenty of the candidate capabilities, from the design file, before the cut to four.
Four core skills what shipped
Find docs- Locate a doc by topic, person, or what is inside it.
Summarize- Get the gist of a doc or a group of them.
Build a diagram- Create flowcharts and visual layouts from a text prompt.
Catch up- See what changed recently or what you missed.
People could not turn what they remembered into keywords
Search by collaborator, timeframe, or what is on the canvas
Find docs is the skill the whole project started from. Instead of a keyword that has to match the title, it accepts whatever the person remembers: a collaborator, a timeframe, or the content written on the canvas.
A title alone did not tell people whether a result was the right one
A compact result with a one-line AI summary
In response, I designed a compact document result with an AI-generated summary that explained the contents of each document. Hovering over a result revealed additional information, including when the document was last modified, who owned it, and which team it belonged to. This gave users enough context to recognize the right document and verify that the assistant had understood their search.
- 1Compact rows
Up to seven results in view, ranked strongest match first. - 2AI summary
One line on what is inside, so the title is not the only clue. - 3Next step
Every answer ends with an offer to narrow or open.
The assistant guessed wrong when people named a collaborator
An @mention that resolves the person before the search runs
Releasing early exposed friction we had not fully anticipated. The assistant sometimes guessed incorrectly when users referred to a collaborator. Instead of asking the AI to make that assumption, I designed an @mention interaction that allowed users to reference a specific team member they had collaborated with on a document. This removed ambiguity and gave users more control over the assistant’s response.
The mention tool shipped in both surfaces: the assistant panel and the keyword search bar.
What I owned across both surfaces the other half of search
Search kept its keyword bar. Past four words, it also returns an AI answer above the results, so a sentence gets an answer and a keyword still gets a list.
My manager owned the design of that AI answer section, and I contributed to it. Across both surfaces I owned the mention tool, the document search results, and the interaction that opened the chat from inside the answer and led into the full Lucid AI experience.
- 1Mention, in search
The same resolver as the panel, inside the keyword bar. - 2Document results
One line per document, so a title is never the only clue. - 3Into the chat
Typing here opens the full assistant, carrying the answer with it.
Beyond search the same panel, two more skills
Summarize and Catch up answer in the same panel as Find docs. Each one opens by saying what it can do and offering a prompt to start from.
Build a diagram the one skill that leaves the panel
Build a diagram runs as a conversation. The assistant asks what kind of diagram, takes a prompt, and assembles the board in its own tab while the panel reports progress.
Release
Act 04: Releasing early exposed problems we could not predict
AI also changed how quickly we could move. By using it throughout prototyping and development, we got the assistant in front of internal users on July 20 and began learning from real usage.
Internal users on July 20. General availability on August 5, across every Lucid tier.
- May 7: Research and design start
- May 20: Development and design QA
- Jul 20: Internal release
- Aug 5: General release, all tiers
Side panel or full page two layouts, one assistant
I explored multiple layouts for the assistant. The side panel allowed users to continue viewing and interacting with their documents while chatting with AI. For people who needed more room for longer conversations, I also designed a full-page state that was accessible from the panel.
Docked: ask without leaving your documents. Every skill is one tap from the panel.
Handoff
Act 05: The release created a foundation for what came next
On August 5, we released the experience to general availability across every Lucid tier. Over the course of my 12-week internship, I helped take the project from a blank page through discovery, prototyping, internal testing, and an external release.
My internship ended shortly after the external release, so I do not have access to long-term adoption data. However, I built the foundation for future iterations. Before leaving, I also designed and implemented an A/B test comparing the side panel and full-page experiences and measuring which capabilities performed best. This gave the team a clear way to use real behavior to guide the next version.
- The side panel and full-page experiences
- The results component
- Four core skills: Find docs, Summarize, Build a diagram, Catch up
- Failure states, shipped with the release
- An A/B test comparing the two layouts and the capabilities within them
- Designs for memory controls and chat history
Every decision on this project involved tradeoffs between speed, cost, and usability. Having enough technical understanding to work through those decisions with engineers expanded what I was able to design.
We shipped quickly because the feedback loop never stopped. Users saw each round, engineers saw designs within days of their creation, and nothing waited for a big reveal.
One limitation remained: the AI inside the editor and the Docs List AI could not share context. Closing that gap was the clear next step. Before leaving, I handed off designs for memory controls and chat history so the team could continue building toward it.
What would come next?
- Shared context between the editor assistant and the homepage assistant
- Memory controls and chat history, from the designs handed off before I left
- Reading the A/B test to choose between the side panel and the full page, and to see which skills people reach for
