aioff.
中文
Product design
PRODUCT DESIGN·4 min

Notion: recover the content you need after a document goes wrong

Notion is a shared workspace for documents, information and tasks. Version history helps a team compare changes and choose what to recover after an accidental edit.

Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.

01
DESIGN QUESTIONIntermediate

How should recovery work when only one passage is missing?

Scenario: You are designing a shared event document. Yesterday it contained registration rules. Today those rules have been deleted, but a colleague has added the correct venue and contact person.

  1. Available material: The old version contains “rule A and old venue.” The current version contains “new venue and contact person.” The user wants only rule A back.
  2. Your decision: Design the path from opening history and comparing content to confirming recovery. Explain when to offer a partial recovery and when to offer a whole-page restore.
  3. Cases to handle: The user chooses whole-page recovery by mistake; the selected passage depends on another old passage; a colleague updates the contact person before recovery is confirmed.
  4. Deliver: A flow sketch, the exact confirmation text, and two ways to observe whether users understand the affected scope. This is your own product design, not a claim that Notion already provides these interactions.
Explore the reasoning
  1. Define what must be preserved first. The rules must return; the new venue and contact person must remain. Evaluate options against those results before deciding how many buttons to show.
  2. Explain both scopes as concrete changes. A partial recovery should identify the passage being added. A whole-page restore should explain which current content will be replaced. Flag dependent passages rather than silently combining them.
  3. Handle edits made after comparison. Refresh the differences or flag a version change before confirmation. An earlier preview does not stay valid indefinitely.
  4. Test understanding rather than memorized steps. Ask participants to describe what will remain after recovery before they act. Observe whether they remove new information by mistake and whether they can explain the two scopes.
02
DESIGN QUESTIONIntermediate

What should the page say when an old version cannot be found?

Scenario: A user wants a plan from three weeks ago, but the account provides only the last seven days of page versions. The system cannot recover versions outside its retention range.

  1. Known information: The system knows the earliest currently visible version time and the user’s viewing permission. It does not know whether the user saved a separate copy.
  2. Design: For empty history, insufficient permission and a date outside the available range, write a message and one useful next step.
  3. Constraints: Do not describe “no permission” as “content does not exist.” Do not promise that upgrading will bring back versions that have already expired.
  4. Deliver: Sketch the three page states and explain the difference between being able to view a version and being able to restore it.
Explore the reasoning
  1. Separate what the system knows from what it does not. It can establish permissions and the visible time range. Missing history does not prove that nobody ever edited the page.
  2. Match the next step to the cause. A user without permission can contact someone who has it. Someone outside the available range can check saved copies. A purchase link is not a recovery promise.
  3. Use dates rather than vague limits. Show the earliest available time with a consistent time zone, so users do not have to calculate what “seven days” means.
  4. Check the wording with a counterexample. Have a user request a date that is unavailable. Confirm that the message does not imply the system has saved that content.