Design Memory and Personalization Users Can See

Workflow area: AX Patterns · Tier: Advanced · Hands-on time: ~40 minutes

An assistant that re-asks your role every session feels dumb; one that says "since you're job hunting" when you never told it that feels like a stalker. The line between helpful and creepy isn't how much the system remembers — it's whether the user could predict, inspect and veto it. Shape of AI groups these under Trust Builders and memory patterns; Microsoft's HAX guidelines 12–14 cover learning from behavior and updating carefully; PAIR insists users understand what the system adapts to. This playbook turns those principles into concrete UI: a memory surface, disclosure moments, and deletion that actually deletes.

When to use — and when not to

• Use it before switching persistent memory onretrofitting visibility onto a memory store users never knew about is how trust incidents start.
• Use it when personalization explains itself badlyif support tickets say "why does it think I…", you have invisible memory doing visible damage.
• Use it when memory spans sessions or productsthe moment context follows users across surfaces, they need one place to see and manage it.
• Skip it for session-only contextremembering the current conversation is expected; a memory dashboard for a single session is overhead nobody asked for.
• Skip implicit-learning designs entirely if you can't surface themif the org can't expose what's inferred, don't infer; visible-but-limited memory beats powerful-but-hidden.

The recipe

1. 1.

   Inventory what could be remembered, and sort it by consent weight. Three buckets: explicitly given (the user typed "I'm a pediatric nurse" or filled a preference), behaviorally inferred (they always shorten your drafts, so brevity is learned), and derived/sensitive (patterns implying health, finances, relationships, job search). Rule of thumb: explicit memory can be stored and shown; inferred memory must be shown as inferred with its evidence; derived-sensitive should usually not be stored at all — and never silently.

2. 2.

   Stress-test your inventory for creepiness before building anything.

   Copy

   You are reviewing a memory design using Microsoft HAX guidelines
   12-14 (learn from behavior, update cautiously) and Google PAIR's
   guidance on user control over adaptation.
   
   Product: [DESCRIPTION + audience]
   Proposed memory items: [PASTE INVENTORY with bucket labels]
   
   For each item:
   1. Predictability: would a typical user expect this to be
      remembered? (yes / surprising / alarming)
   2. Write the worst realistic moment: a sentence the product might
      say that uses this memory at the wrong time, in front of the
      wrong person (shared screen, family member, colleague).
   3. Say whether the item should be: stored+shown, stored with
      explicit confirmation first, or not stored.
   Be conservative. Optimize for zero "how did it know that"
   moments, not maximum personalization.
   

   Expect output that changes your inventory:

   Copy

   ITEM: inferred "user appears to be interviewing at other companies"
   Predictability: ALARMING. Worst moment: "Good luck with your
   interview tomorrow!" rendered during a screen-share with their
   manager. Verdict: NOT STORED. If the user explicitly asks for
   interview help, keep it session-only.
   

3. 3.

   Design the memory surface as a place, not a setting. One screen, reachable from the assistant itself ("What do you know about me?" must work as a prompt): each memory as a card with its content in plain language, its source ("You told me — Mar 12" / "Learned from your edits — based on 14 corrections"), and per-card actions: edit, delete, pause. Include "delete all" with an honest scope note — what dies immediately, what leaves model-side traces and by when. Group inferred items separately under "Things I've noticed — correct me."

4. 4.

   Spec the disclosure moments. Memory used invisibly is where creepiness lives. Define the trigger: whenever an answer is materially shaped by a stored item the user didn't mention in this session, attach a lightweight provenance chip — "Based on your preference for concise drafts ×" — that links to the card and offers "not this time" versus "forget this." Don't disclose trivia (locale, language); do disclose anything from the inferred bucket, every time, until the user dismisses that item's chip.

5. 5.

   Make incognito a mode, not a buried toggle. Design a clearly labeled temporary state: nothing from this session is stored, existing memory optionally not applied ("start blank"). Spec entry (one tap from the input area), the persistent visual signal while active, and exit behavior. Then define evolution rules for normal mode: inferred items decay without reinforcement, and a changed fact ("I moved teams") supersedes rather than accumulates — memory that never updates gets stale, and stale personalization reads as broken.

Make it yours

• Shape of AI pattern sweep: audit three products you use (a music app, an assistant, a shopping site) for memory visibility — screenshot how each shows, hides or fumbles it, and bring the best mechanic into your memory-card design.
• Claude Project for copy: draft every memory string — card labels, disclosure chips, deletion confirmations — in one session with your voice guide loaded; memory copy fails when it sounds either clinical ("data point stored") or intimate ("I know you so well!").
• Regulated domains: health, finance and kids' products flip the defaults — memory is opt-in per item, disclosure is mandatory, and retention limits belong in the spec next to the UI, reviewed with counsel.

Quality check

• Every stored item passes the predictability testnothing in the store would surprise the user who generated it.
• Inferred memory shows its evidence"based on 14 corrections," not just a confident claim about who the user is.
• The worst-moment test ran for every itemincluding the shared-screen scenario; anything that failed got demoted or dropped.
• Deletion scope is honestthe UI never promises "gone forever" if backups or fine-tuning traces persist; it says what actually happens and when.
• Disclosure chips fire on inferred usea materially personalized answer always carries its "why," until the user opts out per item.
• Incognito is visible while activea mode users can forget they're in isn't a privacy feature, it's a future incident.