TOBY
<ALL WORK
02/Project

02 / 07

Kitchen Operations Site

An internal site holding menu, pricing and operational references in one place, built to be read on a phone during service.

TYPE
Operations
USE
Floor reference during service
ROLE
Design and build
STATUS
In use, ongoing
BUILT WITH
HTML/CSS
CAPABILITIES
Internal tooling, Operational systems
Kitchen Operations Site, illustrative render
ILLUSTRATIVE RENDER. FIGURES SHOWN ARE NOT REAL OPERATIONAL DATA.
/Before and after

BEFORE

Menus, prices and process notes scattered across print-outs, chats and memory.

AFTER

One reference the whole team reads, on the device already in their pocket.

/The machine
  1. 01 / INPUT

    Menus, prices and notes, scattered

  2. 02 / PROCESS

    Consolidate into one internal site

  3. 03 / DECISION

    Which copy is the current one

  4. 04 / OUTPUT

    One reference the whole team reads

/Results

  • Many → one

    Reference sources

  • Whole floor team

    Audience

  • Phone-first

    Device

The problem

The information a kitchen runs on was scattered across whatever surface it landed on first: a printed menu taped inside a cupboard, a pricing list in someone’s chat history, a note about a changed recipe that only three people saw. Every one of those copies drifts. The pricing sheet from two months ago looks exactly as authoritative as the current one.

When a new person joins, that scattering becomes a training cost. When a price changes, it becomes a billing error.

What I built

An internal site that holds the menu, the pricing and the operational references in one place, built to be opened on a phone with wet hands in a loud room, which is the only usage condition that actually matters here.

How it works

Every reference lives in one document, and that document is the one the team is pointed at. There is no second copy to keep in sync, which is the only reliable way to stop two versions disagreeing.

Technical approach

Plain HTML and CSS. No framework, no build step, no login wall to fight during service.

That is a real constraint rather than a shortcut. A site the kitchen depends on has to load on the worst connection in the building, and it has to be editable by whoever is nearest when a price changes. Every layer between the content and the page is a layer that can be down, out of date, or waiting on someone who knows how to run the build.

The design rules followed from the same place:

  • Legible under pressure. Large type, high contrast, no decorative interference. Someone is reading this mid-service, not browsing it.
  • One screen per decision. If a question takes two taps and a scroll to answer, the team goes back to asking a colleague, and the site has failed.
  • Changing it has to be trivial. A reference that’s annoying to update becomes a reference that’s out of date, which is worse than no reference.

Current state

In use as the team’s shared reference. “Check the site” replaced “ask whoever’s been here longest,” which is the difference between knowledge living in a system and knowledge living in a person who might be off that day.