A bridge engineer requesting a technical drawing should not have to supply a procurement budget, choose a construction start date, and describe the whole project before the form accepts the request. Those details may help a sales team, but they are not needed to send a drawing. Remove them from that request path.
Transport-infrastructure websites use forms for different tasks: arranging access to monitoring data, requesting material documentation, reporting an asset defect, or submitting a technical inquiry. Each needs its own minimum information. Trouble starts when one form treats every visitor as though they have the same purpose, or asks them to make distinctions the receiving team could sort out later.
Start with the task, not the database fields
Write down what the team must do after submission. To send a pavement-material datasheet, an email address and an unambiguous document selection may be enough. To investigate a reported defect, the team may need an asset identifier, location, observation date, description, and a way to follow up. Internal record-keeping preferences are a separate question.
For each field, ask whether the answer is needed before the team can take the next step. If it is not, remove the field, make it optional, or collect the information later. That also avoids storing project and personal details unnecessarily. “Organisation” and “Your role” may help route a request, but they should not prevent an independent researcher or student from submitting one unless that distinction genuinely matters.
A short form for each task is often clearer than one catch-all form with dozens of conditional branches. If separate forms would confuse visitors, offer a few plainly named request types and show only the fields relevant to the choice. Name those choices for what visitors want to do, not for the departments that receive the submissions.
Make every field understandable on its own
A label should tell someone what belongs in the field. “Structure ID, if known” says more than “Reference”; “Work email for the reply” says more than “Email.” Keep labels visible after typing begins: disappearing placeholder text is a poor substitute for an instruction. Mark optional fields clearly, and explain why any unusual information is required.
Put help text beside the field it explains. A location field, for example, could say, “Enter the asset number or describe the nearest marked access point.” Someone without the formal identifier can still proceed. State accepted file formats and size limits before a visitor selects an attachment, rather than revealing them after an upload fails.
Match the input format to the information requested:
- Allow flexible names and identifiers. Asset references, organisation names, and international phone numbers do not all fit one simple pattern.
- Give examples for unfamiliar entries. Show a date format or sample chainage reference where ambiguity could lead to a wrong answer.
- Offer “not known” when uncertainty is reasonable. Someone reporting a tunnel leak may know its location but not the lining type.
- Leave room for a description. A preset defect category should not stop someone from describing what they observed.
Do not require visitors to make technical judgments they cannot reasonably make. “Water visible at the joint” is an observation suitable for a defect report; choosing a failure mechanism is an engineering interpretation. Qualified reviewers can assess the report against inspection records and site conditions.
Reduce effort without hiding important choices
Arrange fields in an order that follows what people are likely to know: request purpose, asset or document, details, then contact information. Group related fields under short headings. Sections or a progress indicator can help with a long form, but putting a five-field request on several screens adds navigation, not clarity.
Prefill a value only when its source is apparent and the visitor can correct it. A link from an asset page might carry an asset reference into a report form, displayed for verification. Silent prefilling is risky if the page covers several structures or a shared device retains another person’s details. A value that was right when the form opened may not be right at submission.
Conditional fields can spare visitors irrelevant questions, but changing a selection should not silently erase their answers. Test both directions: choose “request documentation,” enter details, switch to “report an issue,” then switch back. Losing the original text may force someone to reconstruct a technical description.
Use validation to help people recover
An error message should identify the problem and explain how to fix it. “Enter an email address in the format [email protected]” is more useful than “Invalid input.” Place the message beside the affected field, identify that field in text as well as colour, and retain the rest of the submission. Do not reject a written account just because it contains punctuation used in engineering notation.
Check constraints that matter to the task. A required email address needs a plausible format; an observation date may need a check for an accidental future year. A narrow national phone-number format, on the other hand, can exclude international project teams. Show character limits before someone reaches them, and leave enough space for the information requested.
Make completion possible on mobile and with assistive technology
A field inspector may open the form on a phone with an intermittent connection and little time to spare. Use controls that are large enough to select and clearly separated. Avoid tiny dropdown targets and wide tables that require horizontal scrolling. Provide the appropriate keyboard for email, telephone, and numeric entries without preventing pasted values. Keep upload instructions and selected filenames visible on small screens.
Accessible design helps everyone recover from mistakes. Every control needs a programmatic label, a logical keyboard order, and a visible focus state. Required status and error messages must not rely on colour alone. The Web Content Accessibility Guidelines offer a recognised framework for checking accessible names, instructions, and error identification. Automated checks help, but completing the form with a keyboard and screen reader can reveal problems they miss.
For a long report or an upload that may take time, consider preserving entered information if the connection drops. Say whether a draft is saved, how long it lasts, and whether it is tied to a device or an account. Do not present an unsaved browser form as a reliable incident record.
Protect sensitive information and set clear expectations
Infrastructure forms may receive information that does not belong in a general inbox, including security-sensitive site details, personal data, or large inspection files. Explain what the form is for and what should not be submitted through it. If sensitive documents or urgent safety reports have a separate approved channel, identify it. Do not imply that a routine web form is monitored continuously.
Ask for attachments only when the team will use them. Explain what a photograph should show—such as the affected area and a wider view for location context—without encouraging anyone to enter an unsafe work zone. Check and store files, and make them available to authorised staff, under the organisation’s security and retention procedures. Do not promise confidentiality or a response time the operating team cannot support.
After submission, show a confirmation that names the request type and explains the next step. Provide a reference number if follow-up is expected. A confirmation email need not repeat sensitive descriptions or include attachments. If the technical inquiry form sits beside a broader contact page, make the difference between those routes clear, as discussed in designing a contact page for transport-infrastructure inquiries.
Test the whole task, including what happens afterward
A tidy form can still fail at the handoff. Test realistic requests with people outside the team that built it: a document request, an incomplete asset reference, a report with an attachment, and a submission from a phone. Notice where they pause, which terms they misunderstand, and whether they can correct an error without losing work. Use representative, non-sensitive test information.
Check the receiving side too. Do submissions reach the right queue? Can staff distinguish an observation from an engineering diagnosis? Is an uploaded filename attached to the correct report? Where privacy practices permit, review abandoned starts and validation errors. Not every abandoned form is too long; a visitor may have realised it was the wrong route.
Finally, submit a report containing only the required fields and ask the receiving team what they would do next. If they cannot identify the asset or contact the reporter, change the relevant instruction or required field rather than adding questions across the form.
