Don't argue with the client's taxonomy
Is 'cold drinks' a category or a subcategory? Wrong question. The schema that wins is the one that renders whatever the client believes.
// trace: where this idea came from
- ↳ video diary @ 13:45 (el debate de las categorías)
- ↳ video diary @ 16:13 (la decisión de arquitectura)
Picky, the QR-menu project, got scoped on a whiteboard: no user accounts, no app store, just a QR code that opens an interactive menu, three or four pages total ▸ 10:18. Julia had wanted an app partly to give the new logo somewhere to live, and the counter was clean: if that’s the only reason, we don’t need the app ▸ 10:09.
The disagreement worth archiving came next. Julia insisted “cold drinks” is a subcategory, obviously, drinks contain cold drinks. Taxonomically she’s right. But: what if the restaurant owner sees it as a main category? ▸ 14:16 We are not going to fight clients over whether their ontology is correct ▸ 14:38. If they want twenty top-level categories including three flavors of hot beverage, the menu must render it and look good doing it ▸ 16:53.
el cliente tiene razón sobre su propio menú →
That one concession decides the architecture. The client hands over their data in an agreed structure, categories, items, prices, even their logo in a folder, and the program renders whatever arrives ▸ 16:13. Personalization splits into two tiers: everyone gets the base design that adapts to any structure, and big restaurants that refuse to look like everyone else pay for the “tuned car”, a custom front end ▸ 15:45.
The general form of the teaching: your schema is not the place to be right. Every hour spent arguing that the customer’s categories are logically wrong is an hour not spent making the renderer flexible enough to not care. Design systems impose taxonomies on their own screens; products that ingest other people’s data survive by refusing to have opinions about it. The design goal, stated on camera: make it look good with whatever madness the client puts in the format…