Organise website design assets for a clean handover

Organise website design assets so the next editor can find the approved source, understand its rights and safely make a new version. A folder of files called "final", "final2" and "new final" is not a handover. Use a clear structure, named owners and a short asset register.

Separate sources from exports

Keep editable source files apart from web-ready exports. A logo may have a vector master, light and dark variations, and several optimised exports. Name each according to its purpose and format rather than the person who last edited it.

Create a small directory structure that matches the work: brand, photography, illustrations, icons, page-specific assets and archived versions. Keep only approved exports in the folder that feeds the live website. If old options must be retained, move them to an archive with a date and reason.

Use descriptive filenames such as service-team-workshop-wide rather than IMG_4821. This helps a future editor choose the right file and reduces the risk of accidental replacement.

Record rights and constraints

For each purchased, commissioned or supplied asset, record the creator, licence or agreement, permitted uses, credit requirement and any expiry or withdrawal condition. Store the actual licence document where the team can find it. A note saying "copyright sorted" is not enough for future reuse decisions.

Record accessibility and content context separately. An image's filename does not determine its alt text; that depends on how the image is used on a page. Note whether a photo includes people who consented for a particular purpose or duration.

Avoid copying licensed assets into personal accounts or untracked shared folders. Make the organisation's approved storage location the place future maintainers will use.

Make versions and ownership explicit

Choose a naming convention for revisions, perhaps an approval date and version number. Keep the current master obvious. If several people can edit a design file, agree who can publish a new export and who checks it before use.

Document fonts, colours, spacing tokens and reusable components in a concise design reference. Include the source location and any paid account or subscription needed to open or export the work. Do not depend on one person's private login to maintain a public website.

For technical handover requirements such as source access and deployment instructions, see how to check a developer handover. The asset register should complement that technical record.

Test the handover with a small change

Ask someone who did not create the files to update one image and one icon. Can they find the master, export the right size, identify the licence and replace the live asset without guesswork? Record any missing step while the original team is still available.

Provide a short readme with folder purpose, naming rules, owners and where to request access. A maintainable handover is demonstrated by a successful change, not just a tidy folder screenshot.

Frequently asked questions

Should the client receive editable source files?

Follow the contract, but make the agreed access and ownership clear before handover. If an asset cannot be edited without a specific tool or account, document that dependency and the available alternatives.

Where should old design versions go?

Keep versions that explain important decisions or may be needed for recovery in a dated archive. Remove duplicate exports that add no value, and keep the current approved version easy to identify.

Is a shared folder enough for an asset handover?

Only if it also explains what each asset is, which version is approved, who owns it and how it may be used. A folder without that context often transfers confusion.