Uploading is a challenging interaction for many users, particularly on desktop devices. It's somewhat easier on mobile devices, but still presents challenges. Users lower on the digital literacy scale will struggle and may not be able to use a service if they need to upload as part of it.
The most basic upload mechanism is the file picker. This can be difficult to use on desktop devices, but works well on mobile devices. You should support using a file picker as a minimum before adding alternatives.
Drag and drop
Proficient computer users may prefer to drag and drop from their file system onto the browser.
Always use another upload method alongside drag and drop.
Drag and drop only works in modern browsers
Users with dexterity problems such as tremor may have difficulty dragging a file.
You may want to support drag and drop to support users who attempt to drag a file, and would otherwise lose their progress in the service.
If GOV.UK Verify is not a good fit for your service, consider a passwordless account system. The best way to do this is to ask for the user's email address. When they need to sign in again, send a time-limited access code to that account. This approach means the user does not need to remember usernames and passwords.
this makes email address a requirement. What do we do with people who don't have them? Or share an account. I would recommend they open one and provide links to Gmail, Outlook. I think the complexity of supporting alternative models is too great and could impact too much on the large majority.
Some users want to be able to share their sign in with trusted parties to review their application. A time limited email doesn't work in this scenario. Ideally you'd set up user accounts with separate access for each of the individuals but for some services this might be overkill. Having username and password allows users to easily share access.
Over here at HMRC we've been having a problem with the example NINO that's given in the Service Manual (QQ 12 34 56 C). In particular, we've been trying to use it as an example NINO for use in our APIs, on the grounds that it is guaranteed to be fictitious. The trouble is, it fails validation within the API because "QQ" is not a valid prefix for a NINO. I was wondering whether there are any "reserved" NINOs that are guaranteed to be fictitious but will also pass validation. Any thoughts?
On the positive side, we do have valid test IDs for UTRs - for example, I am told that 1111111111, 2222222222, 3333333333 etc. are valid UTRs (as per check digit validation) but are guaranteed not to belong to anyone. I believe this applies both to CT UTRs and SA UTRs