Decide what the archive needs to answer
An archive is useful when it helps you answer a question without reopening every file. You might need to find the logo version a client approved, check which fonts were used, reuse an export setting or remember why a layout changed. Start with those likely questions rather than trying to preserve every trace of the project.
Before moving anything, make a quick inventory of where the work lives: local folders, cloud storage, design tools, shared documents and message threads. Identify the final deliverables, editable source files, important inputs and notes that explain decisions. You do not have to copy an entire conversation into the archive. A short summary of the decision, with enough context to understand it later, is usually easier to use.
Check what you are permitted to retain. Client agreements, privacy expectations and tool access may affect what belongs in your own archive. If you do not need a file to maintain the work or document the handoff, leaving it out can make the archive both simpler and easier to manage.
Give every project a predictable home
Choose one main location for completed projects, then use the same small set of folders inside each project. For example: 01_Final, 02_Source, 03_Inputs and 04_Notes. Final holds the delivered exports; Source holds editable files and necessary linked assets; Inputs holds approved copy or supplied materials; Notes holds the project summary and handoff details. The numbers keep the folders in a useful order without relying on a particular app’s sorting behavior.
Name the project folder so it remains recognizable outside its original client workspace. A pattern such as Client_Project_Year works if those details are useful to you. For a personal project, replace the client name with the publication, product or project name. Pick a pattern you can apply consistently; a modest structure you actually use is better than an elaborate one that becomes a sorting task of its own.
If a project spans several phases, keep the archive together but label the phases clearly. This makes it easier to tell a later revision from the original delivery. Avoid leaving duplicate folders called “final” in several locations: choose one archival copy and treat other copies as working or backup copies.
Use names that make files findable
File names should describe what a file is without requiring you to open it. Include the project, asset type and intended use when relevant: for example, Harbor_SocialBanner_Square_Approved.png. For editable files, a clear label such as Source can distinguish them from exports. Use the same terms across related files so a search for the project name or asset type returns a sensible group.
Avoid relying on names such as final2, latest or new, which only make sense for a short time. If several approved versions exist, distinguish them by purpose or phase: WebsiteLaunch and EventUpdate say more than v3 and v4. Keep filenames reasonably short, and avoid special characters if files will move between systems.
Searchability also depends on content outside filenames. If a design file uses linked images or fonts, store the assets you are allowed to keep alongside it, or note where they can be obtained. If the project includes many similar exports, a brief file list in the notes can explain which one was delivered and which ones were alternatives.
Save the reasoning, not just the output
The most valuable archive file may be a plain-text project note. Give it a consistent name, such as Project_Notes, and place it in every project. Record a one-paragraph description, the deliverables, where the editable files live and any practical instructions needed to reopen them. Add the names of collaborators or tools only when they help you understand the work later.
Then capture a few decisions that would otherwise be easy to forget: which concept was approved, why an option was dropped, what constraints shaped the final result and what the client received. Write for someone who has no access to your memory—or for yourself after a long break. Separate confirmed decisions from open questions so a tentative idea does not look like an approved requirement.
This note can also make portfolio work easier. You may not be able to publish every asset, but a record of the brief, your role and the design problem gives you a starting point for describing the project accurately. Keep private feedback, credentials and sensitive material out of any version you plan to share.
Make archiving the last step of delivery
Set aside a short closeout step before you consider a project finished. Gather the delivered files, move or copy the source files, write the notes and remove obvious temporary exports. Then test the archive: search for the project by name, locate the approved deliverable and open the editable file. If you cannot tell which asset was delivered, add that detail while it is still fresh.
Keep the archive in a location with a backup process you understand. A synchronized folder can be convenient, but synchronization alone may also carry accidental deletions across devices. Consider how you would recover a file if a folder changed or a device failed, and check that the files you expect are actually included in your backup.
Finally, revisit the system only when it stops answering your questions. You can add a folder or change a naming rule for future projects without reorganizing every older archive. The goal is not perfect preservation; it is a dependable path from a remembered project to the assets and context you need.
