| Product | Google NotebookLM |
| Author | Mohd Yunus (LinkedIn · GitHub) |
| Status | Draft — design proposal accompanying the PRD |
| Date | June 2026 |
| Related docs | 01-PRD.md · 03-engineering-rfc.md |
This proposal covers the UX side of the issue documented in the PRD: NotebookLM's two URL-import paths produce inconsistent outcomes when the target page requires sign-in, and the more commonly used path (Add sources → Website) fails silently. This document defines the design goals, walks through the current and proposed experiences with wireframes, proposes a three-state visual model for source status, and flags open design questions for the team to resolve.
- Never let a failed import look successful. A source row's visual state should always be an honest signal of whether usable content was actually retrieved.
- Guide, don't just block. A failure state should always offer the user a next step, not just an explanation.
- Add a state, don't just recolor one. "Authentication required" is semantically different from both "fetch failed" and "imported successfully" — it deserves its own visual identity, not a repaint of an existing one.
- Respect existing patterns. The fix should extend the visual language already established by the red error state in Evidence 02, not replace it.
- Say what happened, not what the system did internally. Per NotebookLM's own existing error copy ("Upload failed due to an error fetching the URL"), the product already favors plain, action-oriented language over technical jargon — the new state should follow the same register.
Step 1. User opens Add sources → Website and YouTube URLs and pastes a URL.
Step 2. User clicks Insert. The dialog closes immediately. Nothing in this step signals that anything could go wrong beyond the existing static caveats list (which already mentions paid articles aren't supported — see Evidence 03).
Step 3. The source appears in the list, fully checked, with the same visual treatment as every other successfully-imported source (Evidence 04).
Step 4 (the only way to discover the problem). User opens the source. Only here does the truth become visible: the title is "Sign in | Google Skills," and the Source Guide describes a login interface (Evidence 05).
There is no Step 5 in the current flow that tells the user anything went wrong, unless they go looking for it.
This already works well and isn't part of this proposal's scope. Included here only to anchor the new state against it.
Triggered when NotebookLM detects that the page it actually retrieved doesn't match the page the user requested — either because of a redirect to a different host/path, or because the retrieved page itself has the structural signature of a login or sign-in wall (see the RFC for the proposed detection signals).
Key properties of this design:
- A third color, not a reused one. Amber/warning, distinct from the red used for hard fetch failures and from the neutral, unstyled treatment of a normal successful import. This gives users a consistent, learnable color vocabulary across all three states.
- The source is never added in this state. Unlike the current Method B behavior, nothing gets written into the Sources list as a placeholder. The footer copy ("This source was not added. No content was imported.") makes this explicit, since users coming from the Method A red-error pattern already expect a clear yes/no answer.
- Every option is a verb, not a noun. "Upload PDF instead," "Paste page content," "Retry" — each names the action the user takes, not a system concept. This follows the same logic as the existing error message, which already says what failed and implies what to do next ("try again").
- The unavailable option is visibly different, not hidden. "Connect account — coming soon" is shown with a dashed border and muted text rather than omitted entirely. This sets expectations honestly: it signals the direction the product is headed without overpromising a capability that doesn't exist yet (see Phase 3 in the PRD).
A consistent three-state system across both ingestion paths:
| State | Trigger | Color | Source added to list? | User action available |
|---|---|---|---|---|
| Imported | Fetch succeeds and content matches the request | Neutral (current default) | Yes | None needed |
| Fetch failed | Non-2xx response, DNS/network error, timeout | Red (existing) | Yes, flagged red | Retry |
| Authentication required (new) | Redirect to a different host/path, or structural login-page signature detected | Amber (new) | No | Upload PDF / Paste content / Retry / Connect account (future) |
The "Authentication required" state intentionally does not add a flagged row to the Sources list the way the fetch-failed state does, since there's nothing useful to flag — no partial content exists, and showing an empty or near-empty row risks the exact silent-failure problem this proposal is trying to remove. The dialog-level interaction is the appropriate surface for this state.
Suggested strings, written in the interface's own voice — plain, specific, and consistent with the existing error message's register. These are starting points for the product writing team, not final copy.
- Heading: "Authentication required"
- Body: "NotebookLM could not access this page because it requires you to sign in: [URL]"
- Footer: "This source was not added. No content was imported."
- Buttons: "Upload PDF instead" / "Paste page content" / "Retry" / "Connect account — coming soon"
Two things worth calling out: the body sentence states the cause before the URL, so a user scanning quickly gets the "why" without needing to parse the link first. And the footer explicitly disambiguates "not added" from "added but empty," since that distinction is the entire point of this proposal.
- State should never be color-only. Each of the three states already pairs its color with text and (for the new state) an icon, which is necessary, not optional — color-only status signaling is unreliable for users with color-vision deficiencies and unavailable to screen-reader users entirely. The new dialog needs a proper accessible name/role (e.g.,
role="alertdialog") and the icon needs alt/aria text equivalent to "warning," not just a decorative glyph. - Localization. Evidence 08 shows the underlying Google Skills sign-in page itself supports at least 19 locales. NotebookLM already supports a large number of interface languages, so the new strings should go through the same localization pipeline as the existing "Upload failed" error message, not ship English-only.
- Mobile. All evidence in this proposal includes both desktop and mobile capture (Evidence 02 and 04 are mobile views), confirming the existing Sources panel is responsive. The new dialog should follow the same responsive treatment already used for the existing Website-URL insert dialog (Evidence 03).
These are intentionally left open for the team, rather than asserted as settled:
- Should "Authentication required" results from the search-based path (
site:queries) use this same dialog, or keep its current inline red-row treatment? Unifying both paths behind one component would be the more consistent long-term answer, but is a larger change than fixing Method B alone. - For users on a Google Workspace or Education account, should the "Connect account" option be enabled sooner for first-party Google properties, ahead of any third-party OAuth work? This is flagged as a possibility in the PRD's Phase 3 but not assumed here.
- How should this state interact with bulk URL import, where a user pastes multiple URLs at once and only some are authentication-walled? A single modal interrupting a multi-URL paste may need a different, batched presentation.
The PRD's Phase 3, "Connected Sources," would let users pre-authorize NotebookLM to read specific services via OAuth, turning the "Connect account — coming soon" button in the mockup above into a real action. That is a substantially larger initiative — partner agreements, per-service API integration, and its own dedicated security review — and is intentionally kept out of scope here so that this proposal's narrower, well-evidenced fix isn't held hostage to a much bigger and slower-moving piece of work.