Dev Journal

Notebook / Interface notes

A form should explain what happens next

Labels, errors and confirmation messages are part of the same conversation.

Ask for less

Every field is another decision for the person filling in the form. Before making a field required, ask what would happen without it. Information that might be useful someday is a weak reason to interrupt someone today.

Keep the label outside the field

A placeholder can show an example, but it disappears as soon as typing starts. A persistent label gives the field a name throughout the task. Put formatting hints nearby when they are actually needed, rather than leaving people to discover them through an error.

Make errors specific

“Something went wrong” leaves the next move unclear. An error should name the problem and suggest a correction when possible. Keep the information already entered. Repeating the whole form after one mistake makes a small problem feel much bigger.

Finish the interaction

A successful submission deserves a clear result: what was received and what happens next. Avoid promising a reply within a fixed time unless that promise can be kept. This notebook has no submission form; these are design notes, not an invitation to send personal information.

Back to all notes