Taste Feedback

Live Taste Feedback

The standard Designpowers pipeline catches taste mismatches at critique — after the full build is done. That's expensive. A wrong colour palette discovered after 8 components are built means rebuilding all 8. This skill interrupts the build at strategic moments to show intermediate output and ask: "Is this heading in the right direction?"

When to Use

• During design-builder execution, at natural visual checkpoints
• When the build involves subjective aesthetic decisions (colour, typography, spacing, tone)
• When this project's taste direction (design-taste) is ambiguous on the decision at hand
• When the project is new and there's little explicit direction yet for this decision
• When the design-lead's direction was based on interpretation, not explicit user instruction

Do Not Use When

• The user is in auto mode and hasn't opted into taste checks
• The build is purely structural (data models, API integration, routing)
• This project's design-taste direction already settles this decision clearly
• The user has explicitly said "just build it, I'll review at the end"

Process

Step 1: Identify Checkpoints

Before the build begins, identify 2-4 moments where taste feedback is most valuable. More than 4 interruptions becomes annoying. Choose wisely.

High-value checkpoints:

Low-value checkpoints (avoid):

Step 2: Prepare the Checkpoint

At each checkpoint, capture the current state:

1. Take a screenshot of the running output (or describe the visual state precisely if screenshots aren't available) 2. Identify the taste-sensitive decisions visible in the current output 3. Prepare specific questions — do not ask "does this look good?" (too vague)

Good taste questions are specific and answerable:

Step 3: Present the Checkpoint

Show the user the intermediate state with targeted questions:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  TASTE CHECK  [1 of 3]
  Phase: [e.g., "Colour & Typography"]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [Screenshot or detailed visual description]

  DECISIONS VISIBLE:
  • [Decision 1 — e.g., "Sage green (#8FAE8B) as primary"]
  • [Decision 2 — e.g., "Space Grotesk for headings, Inter for body"]
  • [Decision 3 — e.g., "Generous padding, low density"]

  TASTE QUESTIONS:
  1. [Specific question about a visible decision]
  2. [Specific question about a visible decision]

  Quick responses welcome:
  • "Looks right" → continue building
  • "Warmer/cooler/bolder/quieter" → adjust and continue
  • "Stop — wrong direction" → pause build, discuss
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 4: Process the Response

The user's response determines what happens next:

Step 5: Adjust and Confirm

When the user requests a change:

1. Make the adjustment 2. Show the updated state briefly — do not re-present the full checkpoint 3. Confirm: "Updated [what changed]. Continuing the build." 4. Do not ask for re-approval unless the change was ambiguous

If the change cascades (e.g., new colour palette affects multiple components already built):

1. Flag the cascade: "This colour change will affect the 3 components already built. I'll update them all." 2. Update everything before continuing 3. Optionally show the cascaded result at the next checkpoint

Step 6: Record Taste Data

After each checkpoint interaction, update taste signals:

1. Record confirmed decisions as positive signals in design-memory 2. Record adjustments with before/after — these are the richest taste data 3. Record rejections as anti-pattern candidates 4. Note the direction of adjustments — "wanted warmer", "wanted more contrast", "wanted tighter spacing" — these directional signals generalize across projects

Checkpoint Frequency

Adapt based on user behaviour:

The system should learn this preference over time via design-memory.

Integration With Pipeline Modes

Integration

• Called by: design-builder (at visual checkpoints during build), using-designpowers (can be enabled/disabled)
• Calls: design-memory (to record taste signals from feedback)
• Reads from: Taste profile (to determine checkpoint frequency and known preferences), design-state.md (for current decisions)
• Pairs with: design-memory, ui-composition, designpowers-critique

Anti-Patterns