nkz-taste

Taste

Taste is the art of the invisible. You look at it and you know it is good, and you cannot point at the one thing that made it so.

Four layers, in this order. Each one is a different question, and a good answer to a later question cannot rescue a bad answer to an earlier one.

Layer	Question	Where
Product	Should this exist, and what is its one job?	product.md
Craft	Does it work for everyone, in every state?	craft.md
Direction	What should it look like, and why this and not the default?	direction.md
Feel	Does it look, behave, and move well?	design / interaction / animation files

Most UI work fails at Product and gets polished at Feel. A beautiful screen that does the wrong job is a more expensive mistake than an ugly screen that does the right one. Do not start at Feel.

Within Feel:

Design      → how it looks
Interaction → how it behaves
Animation   → how it feels

Two rules hold across all of it:

• Nobody should notice an animation. If a user notices motion, it was too much. Motion is for continuity and feedback, never for attention.
• Interaction without feedback is not interaction. Every action confirms itself inside 100ms, before the work is done.

The loop

Run this in order. Do not skip step 1 because the request sounds small: a request for one button still sits inside a screen that has a job.

1. Frame the product. Name the surface, the user's job, the one primary action, and what happens before and after. Identify unnecessary additions, if any. Read product.md. Ten minutes here changes what you build; ten minutes at step 6 changes a shadow.
2. Survey what is in place. Find the token source, the component library, the animation library, the existing conventions. See In place vs out of place below.
3. Resolve the style. If a style was selected, load its contract and recipes using the router below; those decisions are already made. Otherwise set the direction, when the work is new or brand-facing. State the read, set the intensity dials, write the four-part plan, then critique it against the answer you would give any similar brief. Read direction.md. Skip this only when you are working inside an established system that already made these decisions.
4. Pick the platform and load the files. Native mobile and web share philosophy and share almost no mechanics. See the router below.
5. Propose before you build, when the change is more than a component. State the frame, the direction, the layout, and the trade-off you are making. One paragraph, not a document.
6. Build, installing the selected style centrally when applicable, then taking every visual value from the project's token source. Never invent a hex, a font, or an arbitrary px inline. See Tokens below.
7. Pass the pre-flight. Blocking. See below.
8. Report the trade-offs. Name what you knowingly skipped and why, and name every new token the project needs.