Journal / Restaurants
Rebuilding a menu page the kitchen could actually update
The menu was a PDF. Updating it required an email, a designer and four days. In a kitchen that changes three dishes a week, that meant the site was wrong roughly always.
This is a small project with a large effect, and it comes up more than any other single request.
A restaurant with a well-designed site and a stale PDF menu is, from the guest's point of view, a restaurant with a well-designed site and a wrong menu. The wrong menu is what they remember.
It is worth counting what the PDF costs, because it is never counted.
It cannot be read on a phone without pinching. It cannot be read by a screen reader. It cannot be searched or indexed. It cannot be translated by the browser. It is invisible to the search engines that would otherwise surface the dish.
And because it is expensive to update, it is always slightly out of date — which produces the worst outcome available: a guest who chose the restaurant for a dish that is no longer served.
The actual cost of the PDF
- Unreadable on a phone without zooming
- Invisible to screen readers and to search
- Expensive enough to update that it never is
The menu became structured content: courses, dishes, description, price, allergens. Not a page builder, not a rich-text field — a set of entries with fixed fields, because fixed fields are what make allergens reliable.
Editing happens in the browser on a phone, in the same place the dish lives. A change is visible on the site within seconds, with no export and no cache to clear.
Allergens sit on the dish record itself, so the person changing the dish is the person updating the allergen information. They cannot drift apart, because they are the same row.
What we built
Put the allergen field on the dish, not on a separate compliance page. Then the two cannot disagree.
No reservation platform. The restaurant takes bookings by phone and had no intention of paying per cover, so the site says so plainly on the first screen and links to the number.
No online ordering. It is a different business with a different operational cost, and adding it would have made the menu harder to maintain rather than easier.
No photography shoot. The dishes change weekly; a shoot would be stale in a month. The menu is text and it is designed to work that way.
What we did not do
The menu is now updated by the kitchen, usually within an hour of a change, without contacting anyone.
The restaurant stopped receiving calls asking whether a dish was still available — a question that had been arriving daily and was always really a question about the menu being out of date.
The allergen information is current, which is the part that matters legally and the part that was previously a PDF nobody updated.
What changed
If the person who knows the content cannot update the content, the site will be wrong. That is not a design failure or a technology failure; it is a handover failure, and it is the most common reason a good-looking restaurant site stops being useful.
The fix is always the same: make the thing editable by the person who owns it, in the smallest possible interface, on the device they actually have.
The general lesson
If the shape of this is familiar, the first call is a conversation rather than a pitch.
Start a project