Daitoku Ramen Food House

The problem

The admin kept uploads and content on separate pages. To put a photo on a menu item or a journal post, staff had to leave the form, upload the file under Media, wait for a reload, come back, and pick the file out of a dropdown that showed nothing but text descriptions.

The editor is thinking add this photo to this item. The interface was answering create a library file first, then point at it. The screen was describing the storage model instead of the task, and it put unsaved work at risk on every trip.

The dropdown was its own problem. Asking someone to recall a photo from a written description instead of recognizing it by sight goes against a basic usability principle, recognition over recall. For images especially, that is backwards.

What I looked at

I compared how the editors people already know handle this exact moment. Shopify puts upload and choose-existing inside the product form itself, and it separates remove from this product from delete from the store. WordPress does the same at the point where an author inserts an image. Both keep a central library for housekeeping, but neither makes it a required stop. Jakob's law applies here, since staff spend most of their screen time in other tools, so the admin should behave the way those tools taught them to expect.

Government form guidance was useful for the unglamorous parts: keep a plain file input working underneath any enhancement, state the file rules before upload rather than after failure, and make waiting, success, and error states readable to everyone, including screen readers.

I also weighed the opposite direction, dropping the shared library and attaching files straight to each record, and rejected it. Reuse is real here, the same bowl photo appears on the menu and inside a journal post, and Tesler's law says that complexity has to live somewhere. One managed library beats the same file pasted into five records.

What was chosen and why

One picker on every media field, with Upload new or Choose existing right there in the form. Choosing shows searchable thumbnails, newest first, so picking works by recognition. Uploading shows an honest waiting state and puts errors beside the field they belong to, so the system's status stays visible.

The record still saves only when the editor says so. A new upload attaches to the field immediately, but nothing about the menu item or post is committed behind the editor's back. That keeps control where it belongs.

Remove and delete were split deliberately. Remove clears one field on one record. Delete permanently only unlocks once a file is used nowhere, and the library lists every place a file appears first. That is error prevention, so the destructive path shows its consequences up front.

The old dropdown stays underneath as a fallback. If the enhanced picker ever fails to load, the form still works the way it always did.

Outcome

The task now matches the sentence in the editor's head: open the record, add the photo, save. It happens without a page change, a reload, or retracing steps.

I won't dress this up with numbers that were never measured. The gains here are structural. The detour is gone, unsaved work no longer has to survive a round trip, and deleting a file can no longer break a published post without warning. The next measure is watching restaurant staff use it.