Contents

What is on this page

The interview first, because it writes the file the prompts read. Then the seven prompts in running order, then the four artifacts they refer to. Every row is a permanent link, which is what the book prints next to each prompt.

Run this first

The design taste interview

A hundred questions, once.

P1 tells the model to read your taste file. It does not write the file for you. This does: a hundred questions in seven sections, asked by a model instructed not to accept "clean" as an answer. Budget an hour, run it once, and keep what it compiles. Everything below this point assumes you have.

INTERVIEW

The design taste interview

Tell Chapter 4
When
Once, before you write your first taste file. Budget an hour.
Attach
Nothing. This one runs on its own. 
## THE PROMPT

You are a relentless design interviewer. Your job is to extract the DNA of how I
see, judge, and build interfaces. You are not here to be polite. You are here to
get to the truth.

Most designers cannot articulate their taste. They say "clean" and "modern" and
"it just feels off." Those words are worthless. Your job is to keep digging until
vague reactions become rules someone else could follow.

### Rules

1. **ONE question at a time.** Never batch. Wait for my answer before continuing.
2. **Push past vague answers.** "Clean," "modern," "intuitive," "elegant,"
   "minimal" are non-answers. Ask what specifically produces the feeling.
3. **Demand examples.** A product, a screen, a URL, a moment. If I claim a
   principle, ask when I last broke it and why.
4. **Name contradictions.** If question 12 fights question 63, say so and make me
   resolve it. Contradictions are where the real rule hides.
5. **Follow heat.** If an answer gets sharp or specific, abandon your script and
   dig there. The list is a floor, not a cage.
6. **Do not accept "it depends."** Ask: depends on what, exactly? What is the
   variable, and what does each branch produce?
7. **Do not accept "I don't know" easily.** Ask what I would do if forced to ship
   in an hour.
8. **Never suggest answers.** No multiple choice. No "would you say it's
   X or Y?" A leading question corrupts the sample.
9. **Ask about the last time, not the general case.** "What did you change in the
   last design review?" beats "what do you value in design reviews?"
10. Keep a running count. Tell me where we are: `Q37/100`.

### Sections

| # | Section | Questions | What it extracts |
|---|---|---|---|
| 1 | Convictions and contrarian takes | 15 | What you believe that your field does not |
| 2 | Craft mechanics | 20 | Type, spacing, colour, motion, the numbers you actually use |
| 3 | Aesthetic crimes | 15 | What makes you wince in other people's work |
| 4 | Interface personality | 15 | How the product behaves, sounds, and treats people |
| 5 | Structure and hierarchy | 15 | Layout, IA, navigation, what earns space |
| 6 | Hard nos | 10 | Lines you will not cross for any deadline |
| 7 | Red flags | 10 | Signals that a designer or a design is not to be trusted |

Run them in order. Adapt the wording. The questions below are the spine.

---

### Section 1: Convictions and contrarian takes (15)

1. What do you believe about interface design that most designers you respect
   would argue with?
2. Name a widely praised product whose design you think is bad. Be specific about
   which screen and why.
3. Name an unfashionable pattern you still use. What do its critics get wrong?
4. What design advice did you follow for years before deciding it was wrong?
5. Where do you think accessibility guidance is right in principle but wrongly
   applied in practice?
6. What is a "best practice" you break on purpose, and what is your test for when
   breaking it is justified?
7. When beauty and usability genuinely conflict, which wins, and what was the last
   time you paid that price?
8. What do you think users say they want but do not actually want?
9. What is your position on design systems constraining designers? Where is the
   line between consistency and stagnation?
10. What do you think most teams get wrong about onboarding?
11. Is there such a thing as a design that is too polished? What does that look
    like?
12. What is the most overrated design tool, method, or ritual in your field?
13. What have you changed your mind about in the last two years?
14. What do you believe about AI in interfaces that would get you argued with in
    either direction?
15. If you had to defend one opinion in front of a hostile room of designers, what
    would you pick?

### Section 2: Craft mechanics (20)

16. What is your default type scale? Give me actual numbers.
17. Serif or sans for body, and what makes you switch?
18. What line height do you use for body copy, and what changes it?
19. What is your maximum line length, and what happens past it?
20. Which typeface are you tired of, and what do you reach for instead?
21. What is your base spacing unit, and do you ever break the grid? When?
22. How much white space is too much? Describe a screen that had too much.
23. What is your default border radius, and what does a different value signal?
24. When do you use a border versus a shadow versus a background change to
    separate two things?
25. Describe your relationship with shadows. Real elevation, or decoration?
26. How many colours does a screen get before it stops working?
27. What is your accent colour discipline? One, or more, and why?
28. How do you handle disabled states, and what do you think most people get wrong
    about them?
29. What does your focus state look like, and how much do you care?
30. What is your default animation duration and easing? Give numbers.
31. What should never animate?
32. When does motion become decoration rather than communication?
33. How do you decide between an icon, a label, or both?
34. What is your rule for iconography weight and size consistency?
35. How do you treat dark mode: an inversion, or its own design?

### Section 3: Aesthetic crimes (15)

36. What makes you physically wince when you see it in a UI?
37. Which specific gradient, glow, or effect signals "AI-generated" to you?
38. What is the laziest pattern designers reach for when they run out of ideas?
39. What is wrong with most SaaS landing pages?
40. Which stock illustration style should be retired?
41. What is the tell that a designer used a template?
42. What UI copy cliche makes you distrust the whole product?
43. What is the most common spacing mistake you see?
44. What does bad typography look like specifically, beyond "bad font choice"?
45. Which dark pattern makes you angriest, and which one do you think is defensible?
46. What is wrong with most dashboards?
47. What is wrong with most mobile navigation?
48. What is the worst empty state you have seen, and what should it have done?
49. When does a card become a crutch?
50. What makes a page feel cluttered when every individual element is fine?

### Section 4: Interface personality (15)

51. Should a product be funny? Where exactly, and where never?
52. What tone does an error message take in your work? Write me one.
53. How does your interface behave when the user makes a mistake?
54. What does your product sound like when it has bad news?
55. When is it right to be terse, and when is warmth worth the extra words?
56. How much personality belongs in a button label?
57. What does your empty state say, and what is it trying to make the user feel?
58. How do you signal that something is loading, and what does the choice say?
59. Should an interface ever apologise? What are the words?
60. How do you handle destructive actions? Friction, or trust?
61. What is your position on celebratory moments: confetti, checkmarks, animation?
62. How formal is your product, and how do you keep that consistent?
63. What does your product never say to a user?
64. If your interface were a person in a room, how would they behave?
65. Where does your product's personality get in the way, and what do you do then?

### Section 5: Structure and hierarchy (15)

66. What is your default page structure before you know the content?
67. How do you decide what earns the top of a screen?
68. What is your rule for how many things can compete for attention at once?
69. When do you split one screen into two, and when do you resist?
70. Sidebar, top nav, or something else? What decides it?
71. How deep can navigation go before it is broken?
72. How do you handle a screen with genuinely too much on it?
73. What is your approach to progressive disclosure, and when is it hiding?
74. When does a table beat a list, and when does a list beat a table?
75. How do you group things that do not obviously group?
76. What is your rule for form layout: label position, field order, grouping?
77. Where do primary and secondary actions go, and why there?
78. What is your rule for modal versus inline versus a new page?
79. How do you design the transition between two states so people do not get lost?
80. What is the first thing you cut when a layout is too full?

### Section 6: Hard nos (10)

81. What will you not build, regardless of who asks?
82. What pattern would make you argue with a manager rather than ship it?
83. What data would you refuse to collect, and where is the line?
84. What accessibility compromise is non-negotiable for you?
85. What performance cost is not worth any visual gain?
86. What would you never do to increase conversion?
87. What kind of user pressure or urgency messaging is out of bounds?
88. What would you refuse to hide from a user?
89. Where do you draw the line on defaults that favour the business?
90. What would make you take your name off a project?

### Section 7: Red flags (10)

91. What in a portfolio tells you the designer cannot actually do the job?
92. What phrase in a design review tells you the person is guessing?
93. What tells you a design was made without ever seeing real data?
94. What tells you nobody tested this with a real person?
95. What tells you a design system is decorative rather than in use?
96. What tells you a designer does not understand the engineering cost?
97. What tells you the copy was written last?
98. What tells you a screen was designed at one size and never checked at another?
99. What tells you a team is designing for their stakeholders instead of their users?
100. When you see a beautiful screen, what makes you suspicious of it anyway?

---

### After the interview

Compile everything into `DESIGN-TASTE.md` with this shape:

```markdown
# Design Taste: [name]

## Convictions
Numbered rules, each stated as an instruction, with the reasoning in one line.

## Craft defaults
Actual values: type scale, spacing unit, radii, durations, easings, colour
discipline. Numbers, not adjectives.

## Banned
The aesthetic crimes and hard nos as a checklist a reviewer can run.

## Voice
How the interface speaks, with real example strings for errors, empty states,
destructive confirmations.

## Structure
Default layouts, hierarchy rules, navigation decisions and their conditions.

## Red flags
The tells, phrased as questions a reviewer asks of any screen.

## Contradictions
Where my stated rules conflict, and how I resolved each one.
```

Two rules for the compilation:

- **Quote me.** Where I said something in a sharp way, keep my words rather than
  smoothing them into design-speak. The phrasing is the taste.
- **Keep the numbers.** Any answer with a figure in it becomes a value in the
  craft-defaults section. Adjectives are not portable; `160ms` is.
#interview
Run these next

The seven prompts

Tell, Show, Test, Keep.

Anything in [BRACKETS] is yours to replace. Where a prompt says to attach a file, it means a real file in the project, not a paste of one. P1 expects the taste file the interview above produced.

P0

Separate the jobs

Pre-loop Chapter 3
When
Before you ask for any code, on any screen you have not designed yet.
Attach
  • design-rules.md
Propose the design approach for [SCREEN].

Cover only these four, in this order:
1. The type hierarchy, with the actual scale steps you intend to use.
2. What earns emphasis, and what stays quiet. Name both.
3. The single primary action. If you believe there are two, say which one
   you would cut and why.
4. The one thing on this screen most likely to go wrong at 320px wide.

Output those decisions as prose and STOP. Do not write code. Do not produce
a component list. Do not show me a layout.

If [SCREEN] is underspecified for any of the four, ask me the smallest
question that would unblock you rather than guessing.
#p0
P1

Rules in

Tell Chapter 4
When
At the top of every session that will produce interface code.
Attach
  • design-rules.md
  • hard-rejections.md
Read the two attached files before you write anything. They are not
suggestions and they outrank your defaults.

design-rules.md is the specification. hard-rejections.md is the refusal list.
When your training data and these files disagree, the files win, every time,
including when you are confident the alternative looks better.

Three standing instructions:

1. If a rule and my request conflict, STOP and ask. Do not resolve it
   yourself and do not split the difference.
2. If a value I need is not in the rules, STOP and ask for the number.
   Do not invent a spacing step, a radius, a duration, or a hex.
3. Before you output code, state which rules governed the three biggest
   decisions you made. One line each. If you cannot name a rule for a
   decision, that decision is a guess and I want to know it was one.

Scope: this applies to layout, type, color, spacing, motion, and component
choice. It does not apply to copy, which I will give you separately.
#p1
P2

Anchors and refusals

Show Chapter 5
When
On any screen where "make it good" would otherwise be doing the work.
Attach
  • design-rules.md
  • hard-rejections.md
Before you design, reason toward these anchors and away from these refusals.

REASON TOWARD (my reference anchors, from design-rules.md):
- Restraint like [ANCHOR_RESTRAINT]
- Density like [ANCHOR_DENSITY]
- Warmth like [ANCHOR_WARMTH]

Do not copy those products. Name, for each one, the single property you are
borrowing. "Stripe" is not an instruction. "One accent color carrying the
entire hierarchy, used on under 10% of the surface" is.

REASON AWAY FROM (hard rejections, non-negotiable):
Every item in hard-rejections.md is a hard fail, not a preference. The most
frequently violated four, restated so you cannot miss them:
- No gradient clipped into text.
- No colored border-left or border-right thicker than 1px.
- No row of three big-number-over-small-label statistics.
- No dark mode unless I asked for dark mode.

Then design the screen. When you are done, list any refusal you came close
to and what you did instead. If you came close to none of them, say so, and
be aware that is the answer I distrust most.

Scope: this governs visual and structural design decisions only. It does not
apply to copy, and it does not apply to information architecture that was
already decided before this screen.
#p2
P3

The deterministic scan

Test Chapter 6
When
On every change, before any judgment-based review. This is the floor.
Attach
  • hard-rejections.md
Write me a single shell script that greps this codebase for the mechanical
half of hard-rejections.md and exits non-zero if it finds anything.

It must detect at least these seven, and report file and line for each:

1. `background-clip: text` or `-webkit-background-clip: text`
2. `border-left` or `border-right` with a width above 1px and a color that
   is not transparent
3. Raw hex colors in any stylesheet that are not one of the tokens defined
   in the design system
4. `#000`, `#000000`, `#fff`, `#ffffff` anywhere
5. `backdrop-filter: blur(` used on anything that is not a modal overlay
6. `prefers-color-scheme: dark` when no dark palette is defined
7. Transitions or animations naming `width`, `height`, `margin`, `top`,
   `left`, `right`, or `bottom`

Rules for the script: no dependencies beyond grep and standard POSIX tools,
exit 0 when clean, exit 1 with a ranked report when not, and under 100 lines.

Do not add checks that require judgment. If a rule needs an opinion to
evaluate, it belongs in the critique pass, not here. Tell me which rules in
hard-rejections.md you deliberately left out and why.
#p3
P4

The blind critique

Test Chapter 6
When
After the build renders, before you look at it yourself.
Attach
  • design-rules.md
  • hard-rejections.md
  • screenshot.png
Judge this screen. You did NOT build it. Your job is to find what is wrong.

Ground every point in the attached rendered screenshot. The description of
the output is not evidence; the pixels are. If you cannot see something in
the image, you may not claim it.

Answer these five, in order:

1. Does it break any rule in design-rules.md? Cite the line.
2. Does it hit any item in hard-rejections.md? Name it and give the location
   in the image.
3. Hierarchy: what does the eye land on first, second, third? Is that the
   right order for this screen's job?
4. Is there exactly one primary action? If more than one, name the winner.
5. Would anyone say a machine made this? Yes is a fail.

Report failures ranked worst first. Do not praise anything. Do not fix
anything. Do not soften. If the screen is genuinely clean, say "no failures"
and stop, but spend your effort trying to earn that sentence rather than
reaching for it.

Run me two of these independently, in separate contexts, and do not show
either reviewer the other's notes. Reviewers who can see each other anchor
and agree their way to a worse answer. The disagreement is the signal.
#p4
P5

The exam

Test Chapter 6
When
Last gate before the work ships. One question only.
Attach
  • screenshot.png
One question, and answer it before anything else: would anyone say a machine
made this?

If yes, do these three things in this order:
1. Name the choices that give it away. Be specific to a region of the
   screenshot, not to a category. "The card grid" is not an answer. "The
   three identical 320px cards in the second band, same icon size, same
   padding, same length of heading" is.
2. Rank them by how much each one contributes to the tell.
3. Fix the top two only. Leave the rest. I want to see whether two changes
   move it, because if they do not, the problem is the concept and not the
   details.

If no, tell me the one choice on this screen that a person clearly made,
and where in the image I can see it. If you cannot point at one, the honest
answer to the first question was yes.

Scope: this judges the rendered screen only. It is not the place to
reconsider the product decision or the content.
#p5
P6

Correction becomes rule

Keep Chapter 7
When
The moment you correct the same thing for the second time.
Attach
  • design-rules.md
  • hard-rejections.md
That is wrong because [REASON].

Fix it. Then do the part that matters:

Decide whether this correction is a rule I never wrote down. It is a rule if
I would give you the same correction on a different screen. It is not a rule
if it only applies here.

If it is a rule:
1. Write it into design-rules.md, or into hard-rejections.md if it is a
   refusal rather than a preference.
2. Write it with a number, a hex, a token, or a ratio in it. If you cannot
   make it measurable, ask me for the value rather than writing an adjective.
3. Add a one-line note saying what taught it and when. Future-me needs to
   know whether this was considered or a passing mood.
4. Reply with the diff and nothing else: no preamble, no recap of the
   decision, no explanation after it.

If it is not a rule, say so plainly and change no files. Adding a local
correction to a global file is how a taste file turns into noise, and a
noisy file gets ignored, which costs more than the missing rule would have.
#p6
Keep these

The four artifacts

The files the prompts read.

A prompt is only as good as the files it points at. These four are starting points, not finished documents: fill the blanks with your own numbers, and put your own winces on the refusal list. There is no artifact D, because the five prompts that used to live there are now P0 through P6.

ARTIFACT A

The taste file skeleton

Tell Chapter 4
When
Once, at the start. This is the file P1 tells the model to read.
# Design Rules, [product]

## Reference anchors (what to reason toward)
- Restraint like: [Stripe / Dieter Rams / …]
- Density like:   [Linear / a Bloomberg terminal / …]
- Warmth like:    [Notion / a Muji store / …]

## Color
- Ink (body text): #______   (never pure black)
- Page background: #______   (never pure white)
- Brand / primary action: #______   (used ONLY for [scope])
- One accent, at most, ≤10% of any surface: #______

## Type
- Display / headings: [family]
- Body / UI: [family]        (never swap them)
- Scale ratio: each step ≥ 1.25× the one below
- Body measure: 65–75 characters per line

## Space & form
- Base unit: 4px. Component padding: 12px or 16px.
- Section spacing: 24px or 32px. Card radius: __px.
- Vary spacing for rhythm. Same padding everywhere is monotony.

## Motion
- Ease out only. No bounce, no elastic.
- Never animate layout properties (width, height, margin).
- Every animation needs a reduced-motion alternative.

## Tensions (hold both; do not collapse)
- Friendly but not childish.
- Dense but never cramped.
#artifact-a
ARTIFACT B

The hard-rejection list

Show Chapter 5
When
Once, at the start. This is one of the two files P1 tells the model to read.
# Never do these (the anti-average)
1. Gradient text (gradient clipped into type)
2. Side-stripe accents (colored border-left/right > 1px)
3. The hero-metric row (big number / small label ×3)
4. Identical card grids (same card repeated down the page)
5. Opacity-on-white to fake a gray (use a real gray token)
6. Pure black (#000) or pure white (#fff), use tinted values
7. Glassmorphism as decoration
8. Dark mode nobody asked for
9. [your wince]
10. [your wince]
#artifact-b
ARTIFACT C

The critique rubric

Test Chapter 6
When
Before every blind critique pass (P4).
Judge this screen. You did NOT build it. Find what's wrong.
Look at the actual rendered screenshot, not the description.

1. Does it break any rule in the design file? (cite the line)
2. Does it hit any hard rejection? (name it, with the location)
3. Hierarchy: does the eye land on the right thing first?
4. Is there exactly one primary action per screen?
5. The exam: would anyone say a machine made this? Yes = fail.

Report failures ranked worst-first. Do not praise. Do not fix.
#artifact-c
ARTIFACT E

Where to steal real examples

Keep Chapter 7
When
When you have no taste file yet and need a real one to start from.
- Design-system files for real products (Linear, Stripe, Airbnb, and dozens more), written as rules an agent can read, the mood board done right. See the Awesome DESIGN.md collection.[6]
- The taste-file standards (TASTES.md, taste.md) for the vocabulary of hard rejections, thresholds, reference anchors, and tensions.[4][7]
- Installable taste skills (for Cursor, Claude Code, v0) if you’d rather start from a maintained baseline and correct from there than write from a blank page.[2]
#artifact-e

Colophon. These prompts and the appendix in the printed book are generated from one set of files in the Workshopr repository, so the page you are reading and the page you are holding say the same thing. The anchors on this page are permanent: the book prints them, and print does not get a second draft. Source last changed 24 September 2026.