| name | kai-taste |
| description | Audit or design generative AI interfaces against three diagnostic pillars (deterministic-stochastic balance, interaction density, visual cohesion). Treats taste as a measurable control system, not subjective preference. Use when: 'taste audit', 'score this UI', 'design quality', 'interaction density', 'visual cohesion', 'refiner layer', 'correction cost', 'why does this feel off', 'polish this', 'design review', or building any user-facing AI product. |
Design Taste: Engineering Framework
Taste is a control system that converts stochastic model output into reliable user outcomes with minimal correction cost. It is not subjective preference — it has measurable proxies, diagnosable failure modes, and an engineering protocol.
Two modes:
- Audit — score an existing UI, product, or generated output against the Three Pillars
- Design — apply taste principles when building new features or interfaces
Iron law: Taste must remain subordinate to function. The moment the system's correction vector dominates the user's intent vector, the product crosses from high-fidelity to high-friction.
The Three Pillars
Every generative AI product sits in a 3-dimensional taste space. Score each pillar independently.
| Pillar | What It Measures | Control Knobs | Bad Signal |
|---|
| Deterministic-Stochastic Balance | Where entropy is injected in the pipeline — where the system is creative vs reproducible | Entropy budgeting across phases, multi-sample + rerank, structured outputs (schema), tool calls as determinism anchors | User says "why did it change?" or fights the AI's personality |
| Interaction Density | Affordances per cognitive load unit — the cost-per-outcome ratio | Progressive disclosure, correction as first-class UI, Chat-to-Canvas transition for persistent artifacts | User manages the interface more than their task |
| Visual Cohesion | Perceptual grammar consistency across outputs and states | Design tokens + component grammar, semantic structure before styling, affordance protection (buttons look like buttons) | Output looks "dropped in from another system" |
These pillars form a feedback system — adjusting one shifts the feasible region of the other two.
For detailed 1-10 scoring criteria: Read references/pillar-rubrics.md
Failure Modes
Too much taste is a system failure. Scan for all 8 modes during every audit.
| Failure Mode | Detection Signal | Antidote |
|---|
| Stochastic Over-Constraint | Revision entropy increases; users fight the AI's "personality" instead of steering it | Re-calibrate entropy injection points; let user steer creative vs deterministic |
| Density Paralysis | Choice overload; user's mental model fragments (Hick's Law violation) | Progressive disclosure; layer density spatially, not all at once |
| Cohesion Rigidity | Output locked in narrow aesthetic band; system fights user when intent diverges | Allow visual escape hatches; parameterize cohesion |
| Oracle Polish | Users over-trust because surface coherence bleeds into perceived correctness (halo effect) | Confidence-aware UI; expose uncertainty; never smooth caveats |
| Affordance Collapse | Users miss actions; can't tell content from controls (flat design trap) | Buttons must look like buttons; test discoverability with real users |
| Interaction Ceremony | Time-to-value inflated by forced wizards, confirmations, tone selectors | Remove any step that doesn't reduce correction cost; measure TTV |
| Trust Distortion | Users accept outputs because they sound right, not because they verified | Calibrate confidence to reliability; never use persona polish to mask uncertainty |
| Metric Gaming | Proxies improve but product quality degrades (Goodhart's Law) | Pair every metric with a counter-metric; run periodic qualitative audits |
North Star Metrics
Taste is an unobservable latent variable. Measure these proxies instead.
| Metric | Formula | Plain English | Bad Looks Like |
|---|
| Refinement Velocity | Vr = 1 / n_prompts | Fewer prompts to accepted final state | User needs 5+ turns to get something usable |
| Correction Density | Dc = manual_edits / generated_tokens | How much cleanup is needed | Heavy post-generation editing on every output |
| Kinetic Friction | Fk = t_action - t_render | Time between seeing output and first meaningful action | Too fast (no thinking, oracle trust) or too slow (navigation overhead) |
| Time-to-Value | Seconds to first artifact surviving >30s without modification | How quickly users get something useful | Slow first output; high churn in first session |
| Correction Effort | Edit distance between generated and accepted output | Total cleanup cost | Output requires heavy reformatting to become usable |
| Dismissal Rate | % of AI suggestions ignored, collapsed, or dismissed | Relevance + intrusion control | System is noisy; users suppress it to work |
| Clarification Burden | Average turns before a stable artifact exists | Interaction density tax | Users spend turns explaining instead of building |
Moderate kinetic friction is optimal. Too low = oracle trust (users accept without thinking). Too high = navigation overhead eats productivity. Target the zone where users think, then act.
Routing: Which Reference to Read
| Situation | Action |
|---|
| Scoring a pillar in detail | Read references/pillar-rubrics.md for 1-10 criteria with observable evidence |
| Building something new (Design mode) | Read references/refiner-protocol.md for the 10-step Refiner Layer |
| Want the theoretical "why" | Read references/theory-foundations.md for information theory, neuroscience, cognitive load |
| Auditing a live URL | Use browse daemon: $B goto <url>, $B snapshot -i -a, $B screenshot |
| Auditing code or mockups | Read files directly, score against pillar rubrics |
Audit Mode Protocol
Use this when scoring existing work.
Step 1: Identify the Subject
What are we auditing?
- Live URL — use browse daemon for snapshots (take at mobile 375px, tablet 768px, desktop 1440px)
- Code — read the source files and rendered output
- Mockup / design file — read or screenshot the design
- Generated output — evaluate the content directly
Step 2: Score Each Pillar (1-10)
Read references/pillar-rubrics.md for detailed scoring criteria. Quick reference:
Deterministic-Stochastic Balance:
- Where is entropy injected? Is it phase-aware (exploration vs execution)?
- Are structured outputs used where reliability matters?
- Can users toggle between creative and deterministic modes?
Interaction Density:
- How many turns/clicks to reach first useful output?
- Is correction cheap (edit-in-place, diffs) or expensive (re-prompt from scratch)?
- Are advanced controls hidden by default (progressive disclosure)?
- Is state persistent (canvas/artifact) or ephemeral (chat)?
Visual Cohesion:
- Does output render through a component grammar or raw text?
- Are affordances visible (buttons, links, actions clearly distinguishable)?
- Is typography, spacing, and hierarchy consistent across all states?
- Does generated content look native to the surrounding UI?
Step 3: Scan Failure Modes
Check all 8 failure modes from the table above. For each, mark Present/Absent with evidence.
Step 4: Measure Available Metrics
Which north star metrics can you compute from observation?
- Count turns to acceptance (Refinement Velocity)
- Estimate edit distance (Correction Density)
- Time the gap between render and first action (Kinetic Friction)
Step 5: Output the Scorecard
## Taste Audit: [Subject]
**Date:** [date]
**Auditor:** [name/agent]
### Pillar Scores
| Pillar | Score | Key Finding | Recommended Fix |
|--------|:-----:|-------------|-----------------|
| Deterministic-Stochastic Balance | /10 | | |
| Interaction Density | /10 | | |
| Visual Cohesion | /10 | | |
| **Composite** | **/30** | | |
### Failure Mode Scan
| Mode | Present? | Evidence | Severity |
|------|:--------:|----------|:--------:|
| Stochastic Over-Constraint | | | |
| Density Paralysis | | | |
| Cohesion Rigidity | | | |
| Oracle Polish | | | |
| Affordance Collapse | | | |
| Interaction Ceremony | | | |
| Trust Distortion | | | |
| Metric Gaming | | | |
### Metrics (if measurable)
| Metric | Observed Value | Assessment |
|--------|:--------------:|------------|
| Refinement Velocity | | |
| Correction Density | | |
| Kinetic Friction | | |
| Time-to-Value | | |
### Prioritized Fixes
| P | Fix | Pillar | Impact |
|:-:|-----|--------|:------:|
| 0 | | | |
| 1 | | | |
| 2 | | | |
### Grade
- 25-30 = **A** (taste is a competitive asset)
- 20-24 = **B** (solid, minor gaps)
- 15-19 = **C** (functional but friction-heavy)
- 10-14 = **D** (taste is actively hurting the product)
- <10 = **F** (taste is absent or harmful)
**Overall: [Grade]**
Step 6: Prioritize Fixes
Map findings to P0 (blocking UX) / P1 (significant friction) / P2 (polish). Fix P0s before shipping.
Design Mode Protocol
Use this when building new features or interfaces.
Step 1: Define the Taste Contract
Translate quality goals into testable constraints, not adjectives:
- What must be reproducible? (deterministic zones)
- Where is creativity allowed? (stochastic zones)
- What must never happen? (hard constraints)
- Reading level, verbosity ceiling, required sections, prohibited moves
- Citation rules, formatting grammar, interaction rules
Step 2: Pre-Score Against Three Pillars
Before building, predict where you'll land on each pillar. Identify the target score band and what observable criteria you need to hit.
Step 3: Apply the Refiner Layer
Read references/refiner-protocol.md for the full 10-step protocol. Summary:
- Define taste contract as constraints, not adjectives
- Separate divergence (exploration) from convergence (refinement)
- Generate structured intent representation before drafting
- Draft into intermediate representation, not directly into final UI
- Run critic pass with explicit rubrics
- Refine via diffs, not rewrites
- Anchor truth with tools, then re-render
- Compile to UI using component grammar
- Guarantee correction affordances at the surface
- Instrument taste as feedback loops
Step 4: Pre-Mortem Failure Modes
Run through all 8 failure modes as a pre-mortem: which could this design fall into?
- If adding polish: check for Oracle Polish and Cohesion Rigidity
- If adding features: check for Density Paralysis and Interaction Ceremony
- If reducing friction: check for Agency Collapse (IKEA effect loss)
- If showing confidence: check for Trust Distortion
Step 5: Plan Metrics Instrumentation
Decide which north star metrics you will track and how:
- Log time-to-first-value
- Track edit operations per session
- Count regenerations and diff rejections
- Monitor dismissal rates
- Pair every metric with a counter-metric (Goodhart protection)
Design Checklist
Run before shipping any user-facing AI feature:
Deterministic-Stochastic Balance
Interaction Density
Visual Cohesion
Anti-Failure-Mode Gates
Common Mistakes
| Mistake | Reality |
|---|
| "Taste is subjective, can't be scored" | Taste has measurable proxies: correction cost, time-to-value, dismissal rate |
| "More polish = more taste" | Oracle Polish is a failure mode. Polish that outpaces reliability destroys trust |
| "Minimize all friction" | Selective friction (IKEA effect) builds ownership. Remove friction only where it doesn't reduce understanding |
| "The model output IS the product" | The model is a probabilistic component. The Refiner Layer makes it feel authored |
| "Chat is good enough" | Chat serializes multi-dimensional state into a 1D stream. Canvas externalizes memory |
| "Make it beautiful and it's tasteful" | Cohesion Rigidity and Affordance Collapse are both beauty-caused failures |
| "Users want everything instantly" | Optimal pacing is layered: immediate ack (0.1s), provisional structure (1s), deferred commitment (seconds) |
| "Show confidence to build trust" | Uncalibrated confidence creates the Uncanny Valley of Agency. Transparency builds trust |
Source Material
For the full 40,000-word theoretical foundation, see:
taste/taste.md — Foundation taxonomy, North Star metric, 5-step Refinertaste/chatgpt_taste.md — Engineering framework, 10-step Refiner, proxy metricstaste/deep-research-report.md — Neuroscience, cognitive load, agency, RLDF spectaste/AI Design Taste_ A Systems Approach.md — Information theory, SDEs, style weightstaste/Engineering AI Design Taste Framework.md — Operationalization, failure modes, synthesis
