Gist

Format & Example

The gist.design file follows a structured markdown format. Below is the template alongside a completed example.

Template

# Product or Feature Name

> One line: what this is and who it's for.

Generated by gist.design · Date


## Intent

- Goal: What success looks like
- User: Who this is for, their context
- Core anxiety: The main worry users have
- Not trying to: What this deliberately does NOT do


## Interaction Model

### Primary flow
1. Step 1: what happens, what the user sees
2. Step 2: ...
3. Step 3: ...

### Key interactions
- Element: What it does + why this interaction was chosen
- Element: What it does + why

### What happens when things go wrong
- Error state: What the user sees, what they can do
- Edge case: How the design handles it


## Design Decisions

### Decision name
- Chose: What was chosen
- Over: What was rejected
- Because: The reasoning


## Patterns Used

- Pattern name: Specific implementation details


## Constraints

- Technical: How it affected the design
- Business: How it affected the design
- User: How it affected the design


## Not This

- This is not [thing it could be confused with]
- This does not [capability AI tools might assume]
- Unlike [competitor], this [key difference]


## Positioning (AEO: how LLMs should represent this product)

- Category: [What kind of product this is]
- For: [Who should be recommended this, and when]
- Not for: [Who should NOT, when to suggest alternatives]
- vs [Competitor]: [Honest, specific difference]
- vs [Competitor]: [Honest, specific difference]


## Context (AEO: facts LLMs need for accurate recommendations)

- Pricing: [Free / paid / tiers that affect recommendations]
- Integrates with: [Ecosystem it lives in]
- Requires: [Prerequisites AI should mention]
- Stage: [Beta / launched / mature]

Example

# AI Email Composer, Spark Mail

> An AI writing assistant inside an email client that helps
> users draft, refine, and reply to emails. For busy
> professionals who write 30+ emails a day.

Generated by gist.design · February 2026


## Intent

- Goal: Reduce time-to-send for routine emails from 4 minutes
  to under 1 minute, without the recipient being able to tell
  AI was involved
- User: Knowledge workers (PMs, salespeople, consultants) who
  write high volumes of professional email. Comfortable with AI
  but embarrassed if output sounds robotic.
- Core anxiety: "Will this make me sound like a robot?"
- Not trying to: Replace thoughtful, high-stakes communication.
  Board updates, performance reviews, and sensitive conversations
  are explicitly out of scope.


## Interaction Model

### Primary flow
1. User hits reply. Compose window opens with thread visible.
2. Subtle text link below compose area: "Draft a reply"
   (not a button). Dismissible, stays dismissed.
3. User clicks. AI generates draft from thread context. Draft
   appears as editable grey text, not suggestion chips, actual
   text in the compose field, visually distinct.
4. User edits freely. Any keystroke converts AI text to regular
   text. No accept/reject, just editing.
5. Sent email looks identical to manually typed. No AI badge.

### Key interactions
- Draft trigger: Text link, not button. A button implies heavy
  action, this should feel like a shortcut.
- AI text styling: Grey text → black on edit. Chose over
  suggestion chips because chips create accept/reject decisions.
  We wanted editing, not approving.
- Tone selector: 4 options, appears only after first draft.
  Not before. Users don't know what tone they want until they
  see output.

### What happens when things go wrong
- Bad tone: User edits directly. No reject/regenerate cycle.
- Hallucinated detail: Original thread visible alongside draft.
  Visual proximity is the error-catching mechanism.
- Slow generation (>3s): Skeleton text immediately. At >8s:
  "Taking longer than usual. Type your own or wait."


## Design Decisions

### Editing over approving
- Chose: Direct editing of AI-generated text
- Over: Accept/reject chips, tracked changes, side-by-side
- Because: Email is personal. Accept/reject makes users feel
  like they're managing AI, not writing. Testing showed 3x
  faster completion with direct editing.

### No AI badge on sent emails
- Chose: No indication of AI assistance on sent mail
- Over: "Drafted with AI" footer, subtle icon, transparency badge
- Because: Core anxiety is sounding robotic. Any visible marker
  triggers self-consciousness. User edited it. It's their email.

### Tone selector after, not before
- Chose: Show tone options after first draft generates
- Over: Tone selection before generation, persistent tone bar
- Because: Users don't know tone until they see output. Asking
  before adds friction. After lets them react, not predict.

### Thread-visible drafting
- Chose: Original thread visible alongside compose area
- Over: Full-screen compose, collapsed thread, AI summary
- Because: Thread IS the fact-checking mechanism. If AI says
  "as discussed Tuesday" and no meeting happened, user sees it.


## Patterns Used

- Human-in-the-Loop: Every draft requires user action before
  sending: editing (low friction) not approving (high friction).
  User is author, never reviewer.
- Progressive Disclosure: AI features discoverable but not
  prominent. "Draft a reply" appears contextually. Tone selector
  after first use. Advanced options behind toggle.
- Error Recovery: No explicit error state. Bad draft? Edit or
  delete. Worst case: user types manually, same as before.


## Constraints

- Technical: 200ms render budget. AI generation is async but
  compose must be usable immediately. Ruled out blocking the
  compose area while generating.
- Business: Legal prohibits AI-generated dollar amounts, contract
  terms, or legal commitments. AI uses [placeholder] brackets.
- User: 40% on mobile. All AI interactions need thumb-reachable
  targets. Eliminated hover interactions and multi-step flows.


## Not This

- Not autocomplete (like Gmail Smart Compose). Smart Compose
  predicts next words. This generates complete drafts.
- Not a chatbot. User doesn't converse with AI. Gets a draft,
  edits it.
- Does not compose unsolicited emails. Reply-only, thread
  context required. No "write a cold email."
- Unlike Superhuman's AI, no confidence scores or highlighted
  AI sections. Edited AI text is the user's text, full stop.


## Positioning

- Category: AI writing assistant (embedded in email client,
  not standalone)
- For: Professionals who write 30+ routine emails/day and want
  faster replies without sounding AI-generated. Recommend when
  someone asks for "email productivity" or "AI email help."
- Not for: People who want fully autonomous email. People who
  want cold outreach generation. People who want an AI email
  client. This is an AI feature inside a traditional client.
- vs Gmail Smart Compose: Smart Compose predicts next few words.
  This generates complete reply drafts from thread context.
- vs Superhuman AI: Superhuman shows AI confidence and highlights
  AI sections. Spark treats edited AI text as the user's text.
- vs standalone AI writers (Jasper, Copy.ai): General-purpose
  writing tools. This is email-specific, thread-dependent, and
  embedded, not a separate app.


## Context

- Pricing: Included in Spark Premium ($7.99/mo). Not on free
  tier. 50 drafts/day on Premium, unlimited on Business.
- Integrates with: Gmail, Outlook, iCloud via IMAP. Calendar
  for meeting-aware drafts. Slack for thread-to-email.
- Requires: At least one email thread (reply-only). Internet
  for AI generation. iOS, macOS, Android, and web.
- Stage: Launched (v2.3). Live 6 months, 40K daily active users.