A filename beside an upload field can look reassuring even when the file has not reached the business. The customer selected it, but perhaps the transfer failed or the final enquiry did not include it. For a ChatGPT ad that leads to a project quote, that gap can leave both sides believing the other has the necessary information.
An attachment step needs to explain what is wanted, what has happened and what remains. Treat those as separate design questions. A technically available upload control does not answer them on its own.
Ask for a useful artefact
For a fictional packaging-design service, a customer may have a product photograph, a dieline or an existing design. Those files serve different purposes. The photograph helps identify the object. A dieline can describe the package structure. Existing artwork may show the current brand treatment.
Tell the visitor which material helps the advertised quote and why. “Upload files” is less useful than “Add the existing package drawing, if available, so we can review the required format”. Keep the instruction consistent with what the team can actually evaluate.
If a file is essential, explain that before the customer starts the form. If it is optional, make the status explicit and allow the enquiry to continue without it. Do not turn an optional reference image into an unexplained submission barrier. The field necessity guide helps decide whether the attachment belongs in the first request.
State the real limits near the control
List supported formats and size restrictions that the system genuinely enforces. Do not copy a generic example limit from a design component into the page without confirming the implementation. If several files are allowed, explain the supported count or total limit where relevant.
The GOV.UK file-upload component illustrates instructions and feedback around a file control. Use it as a reference for understandable interaction, while keeping the actual requirements specific to your service. The documentation’s example settings are not automatically your website’s limits.
For the packaging service, a customer may possess an editable source file that the form cannot accept. If another format is sufficient for an initial review, state that option. If the original must be exchanged later through a different process, explain the next step rather than encouraging unsupported workarounds.
Make three states distinguishable
A file can be selected on the device, transferred to the service and associated with the submitted enquiry. Those are related events but not necessarily the same moment. The visible state should correspond to what is actually known.
After selection, show the chosen filename and an option to replace or remove it. During transfer, explain that the upload is in progress. After completion, indicate success only when the system has confirmed the relevant stage. The final confirmation should not imply the attachment is present unless it is.
Avoid using one green tick for every stage without context. A customer may reasonably interpret it as a completed submission. “File selected on this device”, “Upload complete” and “Enquiry received with attachment” describe different milestones. Show only the milestone confirmed by the system; a completed upload can still belong to an unfinished enquiry.
Replacement needs the same clarity. If the customer replaces a drawing and the new upload fails, decide whether the earlier drawing remains attached. Show that outcome explicitly and let the customer remove the old file. Otherwise the team may quote from an obsolete drawing while the customer believes the replacement was sent. Include this case when checking the final enquiry record. If the file later becomes a production instruction for a personalised product, also define which version the customer approves.
A filename is not the complete transfer
- Selected file
The file exists on the customer's device.
- Transferred file
The service has confirmed the upload.
- Received attachment
The final enquiry contains the correct file.
Handle the likely failure routes
An unsupported format needs a format explanation. A file exceeding the limit needs the actual size requirement. A technical interruption needs a retry or alternative route supported by the system. Do not call all three “Invalid file”.
If the file must be selected again after a failure, say so. Preserve the other form answers when appropriate. A long project description should not disappear because an attachment could not be transferred. The error recovery guide covers keeping the correction local to the problem.
When the file is optional, the customer may prefer to send the enquiry and provide material later. Make that route available only if the team can handle it and explain how the missing file will be requested. Do not promise a later upload feature that has not been implemented.
Keep the request proportionate
Ask only for material relevant to the advertised task. A quote for packaging artwork should not casually request unrelated business documents. Where a document may contain information beyond what the team needs, explain the useful portion or offer a narrower alternative.
This is not a full security or privacy design for file handling. The implementation needs its own appropriate controls. The customer-facing content should accurately explain the supported use and should not make unverified claims about confidentiality, deletion or storage.
If the team has a verified policy that affects what may be uploaded, link to the relevant explanation at the point of use. Keep the instruction readable rather than replacing it with a broad reassurance such as “Your files are completely safe”.
Verify what the team receives
Use safe sample files to test an ordinary upload, a rejected format and an interrupted transfer. Complete the enquiry and inspect the received record through the approved test process. Confirm that the attachment corresponds to the customer’s final selection, including replacement and removal.
Repeat on a phone, where choosing a file may open a different device interface. Check that returning to the page does not erase the project description. The attachment step is ready when the visitor and the receiving team can agree on what was supplied, rather than merely seeing a filename at some point in the journey.
Sources and scope
The customer-facing upload step in an enquiry from a ChatGPT ad, including purpose, status and recovery when a file cannot be supplied.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.