# Upload information

Enable users to provide required information by uploading documents or submitting several related items together, rather than answering a series of individual questions. 

Use this step where users must add evidence, records, or structured information in one place to support an application or request. 

Users will not have to answer multiple question pages or manually re-enter data that already exists elsewhere.

#### When to use

Use this pattern when:

* information is provided as files, attachments, or grouped items
* when data is imported from another system or generated by the service rather than manually entered 
* information is submitted in bulk or as a single action

#### When not to use

Do not use this pattern when:

* information can be captured clearly and efficiently through individual question pages
* when the page only provides guidance without requiring user action

***

## How it works

<figure><img src="https://content.gitbook.com/content/u8moxPbFWK9pTxPYNIyh/blobs/aBj3KvtsNeK1D7e2pCx3/Upload%20documents%20(2).png" alt=""><figcaption></figcaption></figure>

#### Content to include&#x20;

**Heading**

This can be a heading or question that states what documents are required.&#x20;

**Additional information**&#x20;

Describe the type of information or document being provided in plain language.&#x20;

Explain accepted formats, size limits, or what makes a document suitable, without overloading the user.

**Upload field**&#x20;

This is the field or dropzone for the user to upload files, attach documents, submit a set of related items, or trigger the import or generation of information in one place.&#x20;

Enable the user to review what has been added, remove or replace items if needed, and explicitly confirm when they are ready to continue.

#### User interaction&#x20;

**Validation rules**

Validation should apply to the submission as a whole as well as to individual items where relevant, such as checking:

* file types,&#x20;
* sizes,&#x20;
* formats, or&#x20;
* completeness of a generated or imported dataset.

**Handling errors**

When errors occur, explain what went wrong in plain language and what the user needs to do to resolve the issue.&#x20;

Errors should not force users to re-submit information that has already been successfully provided. Recovery paths should be clear and achievable.

**Progress indication**

Provide clear feedback on submission status of multiple uploads, and indicate whether the overall requirement has been completed.

**Save and return**&#x20;

Allow users to save progress, leave service and return later, without losing submitted information.&#x20;

On return, clearly show what has already been submitted and what is still required.

### Security or privacy considerations

* Protect users information during upload, import, generation, and storage using appropriate security controls.
* Sensitive information should only be shown when users need to review or confirm it.
* File names, previews, and metadata should not expose personal or confidential details.
* The interface should confirm successful and secure receipt without displaying contents.
* Users should be informed if their information will be shared with other systems or organisations.

***

## Variants

#### **Alternative submission method**

Use this variant when:|

* users cannot upload documents digitally.
* technical, accessibility, or connectivity constraints prevent online submission.
* documents exist only in physical form or are held by a third party.

**What changes**

* The step should explain alternative ways to submit information, such as assisted submission, postal delivery, or in-person support.
* The interface should clearly state what to do instead of uploading and where to get help.
* The service should record that an alternative submission method has been selected.
* Progress and next steps should reflect that information will be received through a different channel.