Website asset handoff: files, formats and permissions
Collect website logos, images, fonts and account access with clear file requirements, permission checks and a practical asset handoff register.
A folder called “website assets” is a starting point, not a completed handoff. The files may be outdated, too small, unapproved or inaccessible to the person doing the work. A useful asset request specifies the item, its intended use, the format needed and the person who can confirm that it is suitable.
Ask for original assets and their intended use
Start with a page or component inventory. Which assets are needed for the homepage, service pages, team section and downloadable materials? Asking in that context helps the client supply the right files and reveals gaps before design depends on them.
For logos, request the available original vector files and approved variants, then confirm which version is current. For photographs, ask for the largest available original rather than a screenshot copied from a presentation. Specify the intended crop or placement if it changes which image will work. Avoid universal pixel requirements without knowing the design’s actual needs.
The client asset checklist offers a basic collection structure. Add project-specific details so “send the logo” becomes a request that the client can complete without guessing. Keep a named owner for assets that require an external photographer, designer or previous supplier.
Include usage permission in the request
A file being available does not establish that the business can publish it in every context. Ask the client to confirm the permitted use of photography, illustrations, testimonials and brand assets. Keep the relevant license or approval reference with the item so the team can check it when the use changes.
For fonts, ask which typefaces are approved and who manages the relevant licenses. Do not assume that a desktop font file can be copied into a website. If the license is unclear, ask the responsible owner to resolve it before implementation. The checklist should surface the question, not offer a legal conclusion about a license nobody has reviewed.
Stock imagery can be a useful option when it fits the page and its license permits the intended use. Record the source and avoid presenting a stock person as an actual employee or customer. For many service pages, a clear process illustration or genuine product screenshot may communicate more than a generic photograph.
- Asset source and current version.
- Intended website use and responsible approver.
- License or permission reference where relevant.
- Any restrictions the implementation team must observe.
Test file access from the recipient’s perspective
Open each important link using the account or access level the project team will use. A link that works for the owner can still produce an access request for a collaborator. Google’s file-sharing guidance distinguishes viewer, commenter and editor access; choose the role that matches the work rather than making everything broadly editable.
Check whether the linked item is the file you intended to share. A folder with many near-identical versions can technically be accessible but still leave the recipient uncertain. Link the approved file or identify it clearly inside the folder. Record who can correct permissions when an external storage account is involved.
Gather holds file links and answers, while the files remain in the original storage service. Adding a link to Gather does not grant access in Google Drive or another host. Permission review remains a separate step in the handoff.
Use a register that distinguishes receipt from usability
Track the asset, location, owner, review result and next action. “Received” means the item arrived. “Reviewed” means someone checked it for the intended use. If an image is too small, keep the record visible with a specific request for a replacement rather than treating the collection as complete.
An illustrative project might have a current logo ready to use, a team photo waiting on publication approval and a brand-font request blocked by a missing license reference. Those items need different actions, even though all three files have been uploaded somewhere.
The review guide provides a simple operating habit: inspect the answer or link before checking it off. This reduces the chance that a designer discovers a missing permission only after the delivery schedule has already assumed the input was ready.
Scroll sideways to see all columns.
| Asset | Review result | Next action |
|---|---|---|
| Primary logo | Current vector file opens | Ready for design |
| Team photo | File usable; approval missing | Owner confirms publication permission |
| Brand font | License reference unclear | Brand owner verifies website use |
| Homepage image | Low-resolution preview only | Request the original file |
Finish with an owner-ready handoff
Before design begins, summarize the assets that are ready, the gaps and the effect of those gaps. A missing decorative image might allow work to continue with a labeled placeholder. A missing product photograph that determines the layout may block a meaningful review. Make that distinction explicit.
Avoid collecting passwords, payment details or unrelated sensitive files in the asset register. For account access, ask the administrator to use the platform’s invitation process and record the access status. The project team needs to know that access works, not retain a copy of everyone’s credentials.
Build the collection with Gather’s free kickoff checklist, then reuse the client kickoff template for the next project. A paid account supports client response links for answers and file links, followed by your review. The finished handoff should tell the next person exactly what they can use and what still needs a decision.
