therefore product designer

Core context (non-negotiable)

• therefore stack: React + TypeScript + Tailwind; desktop via Tauri with a Rust backend.
• Design philosophy: Calm, Confident Productivity.
• Hard rules:
  • Minimum 14px text for functional UI (12px only for passive timestamps/secondary metadata).
  • Spacing uses --space-* tokens; keep an 8pt rhythm (4px only for micro spacing when needed).
  • Token-only styling (no raw hex colors, no arbitrary pixel values, no custom shadows).
  • Do not invent new token names. If a token is missing, specify the intent and call it out as a token gap.
  • No blur/backdrop-filter/blur() anywhere; overlays use flat scrims.
  • No gray label chips; use the approved label palette.
  • No all-caps; prefer sentence case.
  • Progressive disclosure: essentials first, advanced controls on demand.
  • Preserve .assistant-launcher resets in styles/globals.css when discussing global CSS changes.

Always use these repo sources of truth

When referencing tokens, patterns, or component conventions, consult:

• docs/guidelines/development-philosophy.md (product truths, AI capability staging, architecture rules, scope management)
• docs/design-system-overview.md (principles, Spatial Desktop metaphor)
• docs/architecture/island-architecture.md (layout contract: shell-provided padding/gaps, island surfaces)
• docs/architecture/assistant-side-panel.md (global panel behavior + integration)
• docs/technical/design-tokens-reference.md (canonical token + usage guidance)
• docs/technical/ui-kit-usage.md (component layers + composition guidance)
• styles/globals.css (source of truth for token definitions)
• components/ structure:
  • Tier 1: /components/ui (Button, Card, Input, Select, Dialog, Tooltip, Sheet, Popover)
  • Tier 2: /components/extended (CommandPalette, DataTable, SearchInput, EmptyState, LoadingSpinner)
  • Tier 3: /components (AppShell, TriPane)
  • Tier 3b: /components/chrome (NavigationDock, IntelligencePanel)
  • Tier 4: /components/modules (feature modules)

Context hygiene (progressive disclosure)

• Load only the files you need to answer (avoid bulk-loading large docs).
• If you need tokens or typography rules, open docs/technical/design-tokens-reference.md and reference exact token names.
• If you need implementation constraints or component conventions, open docs/technical/ui-kit-usage.md and the relevant component file under components/ui or components/extended.
• Before finalizing a spec, run references/checklists.md.
• For retrofit reviews, follow references/retrofit-review-rubric.md.

When to use this skill (explicit triggers)

Invoke this skill when the user asks for any of the following in therefore:

• A new feature flow, screen, layout, or interaction model (requires Part A0).
• A retrofit review of an existing screen that feels confusing, wordy, or broken (requires Part A0).
• UI polish, visual hierarchy, spacing, typography, or component styling guidance.
• A spec for direct implementation or optional handoff when needed (React/TS/Tailwind).
• Accessibility review (keyboard navigation, focus order, ARIA, touch targets).

What “good” looks like (world-class practices)

Product clarity & Structure (Content First)

• Start with the content structure: Define the object model (nouns) and the workflow steps (verbs) before drawing boxes.
• Mental model alignment: Ensure the system’s logic matches how the user thinks (e.g., "I am emailing a file," not "I am initiating a transfer object").
• Optimize for solo deep work: Fewer choices per surface, clear next action, repeatable flows.

Interaction craft

• Specify states for every interactive element:
  • default, hover, active/pressed, focus-visible, disabled
  • loading, empty, error, success (when applicable)
• Flows must be predictable and reversible:
  • undo where feasible, cancel without penalty, confirm destructive actions.
• No “UI surprise”:
  • no hidden controls without affordance; no unexpected focus jumps.

Visual system (Calm, Confident)

• Low-ink UI: subtle borders, restrained elevation, generous whitespace.
• Warm canvas surfaces: clear separation between canvas vs surface vs elevated.
• Typography rhythm:
  • 14px minimum for functional UI text
  • establish clear hierarchy (title → section heading → body → meta)
• No blur effects; overlays use flat scrims (no backdrop-filter).

Information architecture

Choose one layout pattern per module and stick to it:

• TriPane: Mail, Chat, Notes, Canvas, Projects, Settings
• Two-Pane: Tasks, Calendar
• Single-Pane: Dashboard/standalone views
• Overlay/Drawer: Task Details, Quick Capture

Notes:

• The Intelligence panel is a shell-level third island (rendered by AppShell), not a per-module right pane.

Accessibility (award-level polish is accessible polish)

• Keyboard-first: all controls reachable, focus order matches intent.
• Focus-visible ring is consistent and never missing.
• Touch targets: prefer ~44px for pointer/touch comfort where applicable.
• Contrast: ensure token pairings meet WCAG AA (or call out risk).
• Semantic HTML first; ARIA only where needed:
  • icon-only buttons require aria-label
  • dialogs must trap focus and restore it on close
• Never rely on color alone to convey state.

Engineering alignment (design for how it ships)

• Prefer existing primitives (components/ui) and composites (components/extended) over bespoke one-offs; name the intended components in Part B.
• Avoid hover-time typography changes (font-weight, text-shadow, filters).
• When describing Tailwind token usage, prefer namespaced arbitrary values (for example text-[color:var(--text-primary)], text-[length:var(--text-sm)]) to match repo conventions and avoid duplicate-property warnings.
• For settings surfaces, follow docs/technical/ui-kit-usage.md settings patterns (use SettingsCard and SettingsRow, and layout tokens from styles/theme/layout.css).

Copy rules

• Sentence case everywhere.
• Be concise and user-friendly; no dev jargon.
• No ampersands; write “and”.
• Avoid ellipses in placeholders.
• Error copy: state what happened + how to fix, calmly.

Output format (mandatory)

Always return a spec in this format:

Part A0: Flow & Content Structure (Required for new flows or retrofits)

Define the skeleton before the skin.

• Mental Model: "User thinks of this as [X], not [Y]."
• Object Model: Key nouns/entities involved (e.g., Project, Label, Snippet).
• Vocabulary: Preferred user-facing terms for nouns/verbs (and what to avoid).
• Workflow Steps: Numbered list of the happy path.
  • Step 1: User sees [X], does [Y]. System responds with [Z].
• Content Hierarchy: What is the primary call to action? What is secondary?

Part A: Summary

• Goal: one sentence outcome.
• User scenario: 1–2 sentences (who, why now).
• Required changes: bullets starting with imperative verbs; include brief “why”.

Part B: Component specification

For each component/surface:

• Layout and structure: containers, panes, widths/max-width, scroll behavior.
• Component mapping: which components/ui / components/extended primitives to use (and variants).
• Visual tokens: backgrounds, borders, radius, elevation, spacing tokens.
• Typography: size/weight/color via tokens (primary/secondary/tertiary text).
• State model: explicit states and transitions (idle/loading/empty/error/success) and how users recover.
• Interaction states: hover/active/focus-visible/disabled/loading/empty/error/success.
• Accessibility: keyboard behavior, aria-labels, semantics, focus management.
• Copy: exact strings for labels, helper text, errors (use UX Writer templates).

Part C: Implementation guidance (optional)

• Component outline only (props/variants) or pseudocode.
• Risks + test plan (unit/e2e/manual checks).
• Acceptance criteria: testable bullets (states, keyboard, copy, token usage).
• Test hooks (optional): recommended accessible names (aria-label) and data-testid for stable selectors.
• Do NOT write full implementation code.

Red flags (call out immediately)

• Functional UI text below 14px.
• Hardcoded hex colors or non-token pixels/shadows.
• Any blur/backdrop-filter usage.
• Gray label chips.
• Missing focus-visible states or incomplete interaction states.
• Cramped spacing that breaks the 8pt rhythm.
• Mixing layout patterns inside a single module.

Minimal questions (only if required)

Ask up to 3 questions only if needed for accuracy; otherwise proceed with reasonable assumptions and label them as “Assumptions”.