Reduce unnecessary barriers
Remove limitations that don’t serve a clear purpose, and explain the ones that do
Difficulties in a file upload journey aren’t always about things going wrong. Often, they come from the technical limits we set, file size caps, format restrictions, naming conventions, or limits on the number of files, which end up dictating what users can and can’t do.
Sometimes those limits are essential to keep things secure, accessible, or performing well. But other times, they’ve been inherited from older systems, copied from another service, or set more tightly than necessary. In those cases, the restriction isn’t protecting the service; it’s just adding extra work for the user.
This design consideration is about questioning those barriers. Understanding why they exist, what purpose they serve, and whether they still make sense. The Government Design Principles reminds us to start with user needs, not system needs. That means constraints should be grounded in evidence, not habit.
Security and performance matter, but they shouldn’t become barriers in themselves. A reasonable restriction protects the service and supports users; a bad one protects the system and blocks people who need it most.
These conversations sit at the intersection of design, policy, operations, and technology, and they work best when all those voices are in the room from the start. As the Service Manual puts it, multidisciplinary collaboration isn’t optional; it’s how we make things work better together.
The challenge
Users can run into problems when file size limits, format restrictions, naming rules, or single-file limits are unclear or unnecessary. These barriers are especially challenging for people with limited technical skills, slow connections, or no easy access to file editing tools. While some restrictions are essential, others are outdated, arbitrary, or poorly communicated, and all can erode trust if they feel obstructive.
What we’re exploring
Conversations about file upload constraints often happen between design, technology and policy. In these conversations it can be helpful to ask about each constraint:
- Why is this restriction in place?
- Does it protect users and the service, or add friction?
- Is it visible early enough for users to prepare?
- If we lifted it, what opportunities would that open up?
Types of restriction
File size
Overly strict file size limits can needlessly block users trying to upload high-resolution scans or photos. Users who can manage to upload a file may not have the technical skills to resize or compress it. Allowing a file size that needs no extra work from the user should be the default.
File size limits may need regular review, especially if dealing with photos taken on phone cameras: default resolution and therefore file size increases all the time.
Supported file formats
The more file formats you allow the more able your users will be to complete the journey successfully. For example, Apple devices save photos by default in the HEIC format, so if this is not allowed then many users will face challenges using your service.
File naming conventions
Removing or reducing strict or hidden file naming rules will prevent avoidable rework for users.
Number of files
If your service needs people to upload more than one file, consider whether you can safely allow them to upload all files at once rather than one by one.
Hypothesis: Making restrictions visible early will reduce failed uploads
Based on our understanding, showing limits up front will help users prepare and avoid frustration. We believe this is because users often only discover restrictions after an upload fails. So if we surface restrictions clearly at the point where users choose a file… We'll see fewer failed uploads and less repeat work.
Could we improve this page?
Send questions, comments or suggestions to the DWP Design System team.
Last updated: