Your client has sent a file. It opens correctly and the upload is complete. Your consultant looks at it and realises it is a blank template. The request was for the procedure currently used at one particular site.
This is an invented example. It illustrates a small but important part of a digital consulting service: helping a client understand what to provide, then keeping the conversation about that document together. An application under your brand could guide this exchange. The professional meaning of the document would still belong to your consultancy.
Explain what you need before asking for a file
In the example, a consultancy is preparing a process review. “Upload your procedure” leaves several questions open. Does the consultant want the general template, a draft being revised, or the approved version used at the site?
A more useful request could say: “Please provide the approved procedure currently used at this site for handling service interruptions. We will use it to prepare our discussion of responsibilities. If you only have a template or draft, please let us know.” The application could show the site already selected for this review beside the request.
That wording is a proposal for this fictional service, not a universal requirement. Its purpose is to give the client enough context to choose the document. The consultancy decides what it needs to assess; Browserbite turns that explanation into a usable journey.
Government Digital Service guidance recommends explaining what people need to provide before they upload it. Although published in 2017, that guidance is still linked from the current GOV.UK file-upload component. It offers a design principle, not evidence about results in consulting engagements. [1]
Confirm what has actually happened
After a successful submission, the client should be able to recognise the file they sent and the request it belongs to. In our example, the confirmation might read: “Your file has been received for this site’s process review. The consultancy has not reviewed its content yet.”
The choice of words matters. A receipt confirms receipt. It does not establish that the document is current, covers the right scope or supports a professional conclusion. If a request stays open until review, the application should explain that next step rather than presenting an unexplained completed status.
If the transfer fails, the client needs a useful explanation and a way to continue. W3C’s form guidance recommends understandable success and error feedback, including help correcting errors. We would apply that principle to the upload journey and test the implementation, including its use with assistive technologies. [2]
Make a correction part of the same request
Suppose the client has nevertheless sent the template. The consultant identifies the problem during review. Instead of a bare “Rejected”, the application could show a specific request: “This is the blank template. Please send the approved version used at this site, or let us know if there is no approved version.”
The client would return to that request, see the explanation and provide the replacement. The consultant should be able to distinguish the new submission from the earlier one. The correction, the site and the reason for the request belong together; an attachment with a similar filename should not silently stand in for that context.
What if there is no approved version? The client should be able to say so. For this example, that becomes a point for the consultancy to discuss. It should not force an unrelated file into an upload field or treat the missing document as an automatic professional verdict.
These are proposed service behaviours. They are not a claim that software can decide whether the procedure is adequate or whether the client fulfils an obligation.
Collect only what the service needs
Before building this journey, we would also examine whether the consultancy needs the file at all. Could the preparation use a short answer, an agreed existing document reference or a discussion instead? The GOV.UK Design System advises requesting an upload only when it is critical to delivering the service. [3]
Where a file is necessary, the journey should explain the supported formats and any limits before submission. Making the experience straightforward still requires appropriate protection behind it. OWASP recommends restricting file types to those the service needs and using several validation measures. That is implementation work for the software provider; it is separate from your consultancy’s review of the document’s meaning. [4]
Start with one real document request
A tailored application is not necessary for every exchange of files. If your existing secure process already makes the request, response and review clear, it may be sufficient. A bespoke journey becomes worth exploring when document requests repeatedly connect to the same client service and its follow-up work.
Bring one example of that exchange to a conversation with Browserbite: what your consultancy needs, what the client is being asked to send, and how you respond when it does not fit. We take responsibility for designing, developing and testing the software journey. Together, we check that it represents your service correctly. You retain the professional judgement about the information received.
Sources and scope
[1] Government Digital Service: Some design tips for uploading things, 14 February 2017 — explaining what to provide.
[2] W3C WAI: User Notification — understandable feedback and error correction.
[3] GOV.UK Design System: File upload — when a file is needed for the service.
[4] OWASP: File Upload Cheat Sheet — restrictions and layered validation.
Sources checked on 4 October 2026. The example and proposed journey are editorial recommendations, not a description of an existing standard product. The sources provide design and implementation guidance; they do not establish time savings, commercial results or professional compliance for this example.