Give restaurant inquiry fields persistent visible labels

The decision this workflow supports

A visitor returning to a partly completed form should not have to remember what each box means. Visible field labels are especially useful when catering forms ask for several dates, contacts or different kinds of numbers.

Put the review process in place

Label each field with its actual purpose and keep the label visible after typing. Ask the website maintainer to associate the label with its control. Separate an event date from a requested callback date rather than using two unexplained fields labeled date.

Worked example for your team

A fictional catering form has one field for the event date and another for when the organizer wants a response. Enter both values and return to the form after looking elsewhere. A reviewer should still understand which date belongs to which purpose. If the only explanation was placeholder text that disappeared while typing, the field needs a persistent label. Ask the maintainer to check the label association as well as the visible wording. The operational test is whether the organizer can review and correct their own details before submission.

Sample wording to approve

“Event date means the date you are considering for the gathering. If it is undecided, use the available unsure option. Callback preference is separate and does not reserve an event date.” This wording is a draft for the restaurant owner to approve before use.

Fields for the staff handoff

Staff need field name, visible label, associated control, unclear terminology, and website owner. Mark uncertain details explicitly and keep the requested action separate from anything restaurant staff have already confirmed.

Acceptance tests before use

Labels remain visible after entry. Selecting a label identifies its control. A tester can distinguish event date from callback date without extra explanation. Record the observed result, assign any mismatch, and repeat the affected scenario after correction.

Related guides