Before a customer chooses a photo, a submission page should explain what to send, which file constraints actually apply, what information is necessary and what happens after submission. Put those instructions where they are needed. Do not wait until an error message to reveal a requirement the customer could have checked earlier.
Keep participation, receipt, review and publication distinct. This is a content review of the upload page, not a privacy-policy template, permission agreement or certification that the form works.
Name the subject without prescribing a verdict
Describe the practical scene the team needs to inspect: the product in ordinary use, a particular part or an available view. Avoid asking for a flattering caption as though it were a file requirement. A customer should not have to invent enthusiasm to make their photo acceptable.
If an example image helps, explain which detail it illustrates. Do not make a professional studio scene look like the minimum standard for an ordinary submission. Use only examples you are authorized to show, and distinguish the product from props that are not part of it.
Consider a fictional storage-box page asking for a photo of the closed box on a shelf. Its useful instruction names that scene. A broad request for a transformation story, a rating and several videos would turn the same upload into a different task. Decide what is necessary before writing a longer brief.
State the constraints of the actual route
Confirm accepted file types, size limits and the number of files with the implementation owner. If orientation or a visible product detail is essential to the intended use, explain it plainly. Do not copy a resolution threshold from another campaign or assume that the form accepts whatever a phone can select.
The GOV.UK file-upload guidance distinguishes missing files, unsuitable types, excessive size and other error states. Its examples show why different problems need specific explanations; their example limits are not specifications for your form.
Make the stated requirements agree with the actual error messages. If the page requests a file that the receiving system rejects, revise the requirement or have the responsible owner resolve the mismatch. Better wording cannot override an unsupported format.
Explain required and optional information
For each field, ask what decision its answer supports. A product identifier may help connect the photo to the right item. An optional contextual note may explain what is visible. Do not collect contact details or personal history simply because another submission form includes them.
W3C WAI's form-instruction guidance calls for clear required and optional inputs, formats and relevant instructions. It also explains why placement and association with controls matter. A useful copy document therefore identifies which instruction belongs to which field; the implementation still needs its own accessibility review.
In the fictional box example, a product question could allow the customer to say they are unsure rather than guess, if the form supports that response. The team would then retain a product-identification question for review. Do not write an instruction that refers to an option the real form does not offer.
Explain review without promising a feature
State the proposed purpose of collection and where the customer can read the relevant use and privacy information before sending. Have the responsible qualified reviewer approve that information. This article supplies no consent clause, checkbox text or promise that one acceptance covers every future use.
Explain whether the received material will be reviewed and how the customer can recognize a receipt. Submission should not be described as guaranteed publication. Likewise, do not promise a response time unless the actual team and process support it.
If a reply or replacement is possible, name an established help route and the reference that connects it to the submission. Do not invite private files in a public comment thread. A help sentence needs a responsible destination, not merely a friendly tone.
Read the page in the order a customer encounters it
Follow the proposed page from its opening explanation to file choice, supporting fields and final action. Check that instructions appear before the decision they inform, remain visible and do not contradict one another. The reader should not have to remember an important condition from a disappearing placeholder.
Keep copy review separate from route testing. This review can establish that the instructions are complete and internally consistent. It cannot establish that the intended file arrived, that a confirmation was sent or that a reviewer can open it. Record those as separate checks rather than implying they passed.
Finish with a short, accurate set of instructions rather than a larger set of demands. A good submission page helps someone send the requested material and understand the next step without promising a result the team has not verified.
For broader portal planning, 7-Day UGC Collection System Setup includes a submission-page checklist. Use it as a planning aid, not ready-made permission approval or verified technical limits. Its physical page 19 blanket rule about publishing third-party logos is unverified and needs context-specific qualified review; its example performance and timing targets are not standards.
Explore Content Creation in Creator & Marketing.
