Cafe landing page: open now, menu, order

A customer on the move has very little patience. They arrive from a map listing or a search, see a large photo, and look for two things. The first is today's hours, which a footer often hides and a holiday can make wrong. The second is the menu. A PDF opens at laptop width, so they pinch and scroll sideways to find a drink. A link to an order site takes them to a site they do not know. Each one asks more effort than the cafe down the street.

• Does the first screen show whether the cafe is open right now, not only the weekly hours?
• Are holiday and weather closures shown on the hours, not only in a social post?
• Is the menu written as text a phone can read without zooming?
• Does the order button go to a page on your own domain, or to a site the visitor has not heard of?
• Does the map link go to the right address, with a tap to call number beside it?

A person who finds a cafe on a map is usually nearby, and their first question is whether to walk there now. Put today's open or closed state beside the address, and link it to a note for changes this week. A weekly schedule does not say the cafe closed early today or opens late on a holiday. A social post that says closed Monday does not fix a page that still says open.

Check this on a phone from a map link, not from your own desk. Open the page as a person walking past would, and note the first screen where the hours appear. Send a simulated visitor with the task, and check whether the answer sits below a photo that fills the whole screen. If it does, the photo is the problem, not the words.

The menu is the second check. A cafe may publish the menu as a PDF, a photo of a chalkboard, or an image with drinks in curly script. None of those read well on a phone, and a photo cannot be searched for a drink name. A visitor looking for an oat milk latte may give up before finding it, and go to the cafe that lists its drinks as text.

Separate a menu problem from an hours problem by looking at what the visitor needed. If the visitor found the hours but could not read a drink name, the menu is the problem. If the drink is there with no size, milk option or price line, the menu is incomplete. Ask the simulated visitor to find one drink by name, and note how many taps it needs. A drink that takes more taps than a visitor will spend is effectively missing.

Ordering turns a visit into money. If the order button leads to a third-party site, that is the step to check first. The button may open an ordering site with a different name, a new sign-in, or a page that asks for an account before it shows the drinks. A visitor who expected to order a latte now has to trust a stranger's login screen. Some leave, and some go back to the map. The button should lead somewhere the customer recognizes, with a line that says what happens after the order.

Check the destination on a phone by reading the address bar after the tap. If the domain changes, note the name on the new page and whether it asks for an account. Then run the order with a simulated visitor. The run can reach the payment step, and a card that needs a real payment ends there. A sign-in that needs Google or single sign on stops it too, since a visitor cannot use either.

The first run finds the hours, menu or order step that sends the visitor away. The fix puts today's status on the first screen, turns the menu into text, and keeps the order button on your own domain. Run the same visitor again to see whether it reaches a drink and the order step. Run it again after each menu change, each seasonal closure and each change to the ordering tool.