AI as a design tool

What came back that I had missed: Three of the four restaurant owners described the same workaround — they mark an order "preparing" the moment it lands, before touching it, because the timer starts on accept and they are judged on it. That is a design failure disguised as a metric. I found it in the transcript, but I found it because the clustering put those three lines next to each other.

Why it works: Clustering is mechanical. Deciding that this particular cluster is the whole project is not, and that judgement stays with me.

The catch: It will produce a quote that reads plausibly and was never said. Requiring the verbatim line is not a nicety; it is what makes the invention checkable in thirty seconds.

Why it works: Writing twenty variants is cheap. Knowing that the useful information here is the order still exists and there is a clock on it is the design decision, and I still make it. The model will happily write twenty polite, useless variants of "please try again" if that is all you ask for.

• A 54-character item name with brackets and a Jain modifier
• An item with 14 add-ons and two required choice groups
• A ₹0 item (a free add-on the restaurant uses as a note)
• A customer name in Devanagari next to one in Latin, in the same column
• An address that is four lines and a landmark instead of a pin
• A restaurant with 400 items and no categories at all
• An order that was refunded, re-placed and then partially cancelled

Result: Six layout failures showed up in an afternoon. The worst: the item name column truncated at exactly the point where "no onion no garlic" became invisible, which is the single piece of text a kitchen cannot afford to miss.

Why it works: This is where dense operational interfaces fail, and it is the cheapest class of bug to find before build rather than after.

The honest part: Generated layouts are average by construction; they are assembled from what already exists, which for a delivery app means every competitor's tracking screen. That is genuinely useful, but as the thing to argue against. The direction I kept came from asking why the map is the biggest element when the customer's actual question is "is it coming" — and the answer is that the map reassures precisely when nothing else can. That argument is not in any dataset. It came out of the rider interviews.

What I still had to write myself: The rule that cancelled and rejected must never share a colour, because the restaurant is measured on one and not the other. That is a business rule wearing a visual-design costume.

• Rider cancels after pickup, prepaid. Who has the food, who is refunded, and what does the restaurant see?
• Customer's number is visible to the rider — for how long after delivery, and is it visible to support forever?

Why it matters: Not because the model understood the product, but because it does not get bored on combination 47, and I do.

The limit: A machine pass catches contrast ratios and missing labels. It does not catch a rider app where the focus order jumps from the map to the support button and skips "arrived", or a live region that announces the ETA every eight seconds while the customer is trying to read the address. Those need a person, a screen reader, and one hand on a bike.

Outcome: Developers get an explicit list of edge-case behaviors rather than guessing from static screens.