Nobody loses a day to a design file on the day they make it. They lose it months later: a client asks for the logo in one more format, a developer needs the source, a print shop rejects the artwork, and the file that was perfectly clear on a Tuesday afternoon is now an unlabelled maze that only opens properly on a laptop you no longer own.
Here is the whole pattern in one line: every one of these mistakes is a small saving in the moment of making, repaid with interest in the moment of reopening. The fix is not a system, a plugin, or a naming manifesto. It is a habit — build the file for the person who opens it next, who is almost always you, in a hurry, with no memory of what you were thinking.
Below are the six that cost the most, why each one is genuinely tempting, and the check that catches it in under a minute.
Mistake 1: naming versions with adjectives instead of order
Logo-final. Logo-final-v2. Logo-FINAL-use-this. Logo-final-new. Everyone laughs about it and everyone does it, because at the moment of saving you know exactly which one is current, so the name only has to distinguish it from the last one.
The problem is not that the names are silly. It is that they carry no order. A folder sorted by name puts "final-new" next to "final-v2" and tells you nothing about which came after which, and file dates lie the moment anything is copied, synced, or restored from a backup.
Why it's tempting: naming a version properly means deciding what changed, and you are usually saving precisely because you want to stop thinking.
The cheap check: sort the folder by filename and read the list top to bottom. If it does not read in the order the work actually happened, the names are decorative. Fix it by leading with something that sorts — a date in year-month-day form, or a zero-padded number — and putting the adjective afterwards, where it can be as sloppy as you like: brand-refresh-03-client-approved.
Mistake 2: one live file with no marked points to return to
Cloud-native design tools quietly removed the moment where you consciously saved a version. The file is simply always current, everyone is in it, and rolling back means scrolling a timeline of automatic snapshots that all look the same.
That is a real improvement over emailing files around, and it introduces one new failure: there is no cheap way to answer "what did the client actually approve?" — which is the question that settles an argument three weeks later.
Why it's tempting: the tool never asks you to name anything, so you never do.
The cheap check: open your file's version history and try to find the state the client last signed off, in under a minute. If you cannot, the habit to add is one keystroke wide — whenever something is approved, sent, or shipped, mark and name that point. "Sent to client" and "approved for print" are the only two labels most projects need. Everything between them can stay anonymous.
Mistake 3: layers and artboards nobody else can read
Group 12 copy 4. Rectangle 88. An artboard called Untitled — 3. This is the mistake that turns a file which technically opens into a file nobody can edit, including its author.
Naming matters more than it used to, because layer names are no longer only yours. Components, shared styles and libraries mean the words you type get reused in other files, by other people, and end up in the vocabulary a developer works from. A badly named component propagates.
Why it's tempting: you are moving fast, the shapes are obvious on screen, and naming feels like admin rather than design.
The cheap check: collapse every group and read the layer panel as if it were a table of contents. If it does not describe the page in plain words — header, hero, price table, footer — it is not documentation, it is sediment. Name things as you create them rather than in a cleanup pass, because the cleanup pass never happens. Structure the file the way the finished thing is structured and handover gets easier too; the rest of that is in how to hand off a design so developers build it correctly.
Mistake 4: assets that live somewhere only your machine can reach
The file looks perfect. You send it. It opens on someone else's computer with grey boxes where the photographs were, because every image is a link to a folder on your desktop.
Linking rather than embedding is usually the right decision — it keeps files light and lets you update an image everywhere at once. The mistake is not linking. It is linking to somewhere personal and then treating the file as portable.
Why it's tempting: dragging an image straight in from wherever it landed is one step; putting it in the project folder first is three.
The cheap check: open the file's links or assets panel and look at the paths. If any of them start inside your user folder rather than inside the project, the file only works here. Keep every linked asset in the project folder next to the document, and run your tool's package or collect-for-output command before sending anything. If the file does not open cleanly on another machine, it is not finished — it is finished for you.
Mistake 5: shipping the working file as if it were a deliverable
The working file has three rejected directions on hidden artboards, a scratch area off-canvas, and a note to yourself about what the client said on the phone. Sending it as the handover is fast, and it is also how half-formed ideas escape and how the recipient ends up asking which of the four versions is the real one.
Why it's tempting: it is genuinely the same artwork, and exporting a clean copy feels like duplicating work you already did.
The cheap check: open the folder you are about to send and ask whether a stranger could pick the right file out of it without asking you a question. A handover folder should contain the final source, the exports someone will actually use, and nothing that needs explaining. Keep the messy file — just keep it on your side of the line. The same discipline applied to a whole project is the website handover checklist.
Mistake 6: fonts that are activated rather than supplied
Type is the most common reason a file opens wrong for someone else. Fonts are activated locally by a font manager or a subscription, so they are invisibly present on your machine and simply absent on theirs — and the file substitutes something else without asking, which reflows every line you carefully set.
There is a second layer to this one, and people tend to discover it late: a font licence usually covers you, not everyone you send the file to, so passing font files around is often not permitted even when it is technically easy. Outlining type solves the display problem and destroys editability, which is why it belongs in final print artwork and almost nowhere else.
The cheap check: deactivate your font library and reopen the file. Anything that changes shape is a font you have not really supplied. Then decide deliberately, per deliverable — outlined for final print artwork, live text plus a named font list for anything that will be edited again, and a look at the licence before you send a font file to anybody.
The ten-minute pass that prevents most of it
You do not need a system. You need a short pass at two moments: when a piece of work is approved, and when it is delivered.
- Name the version with something that sorts, and mark the approved state.
- Read the layer panel as a table of contents; rename anything that is not a word.
- Check the links panel for paths outside the project folder, then move and relink.
- Package or collect before sending, every time, including internally.
- Test the fonts with your font manager switched off.
- Separate the working file from the handover folder, and put only finished things in the second one.
- Write one short note in the project folder: what the deliverable is, which file is the source, what is still outstanding. Three lines. It answers the email you will get in six months.
None of this is tidiness for its own sake, and none of it depends on a particular application — the habits survive every tool change, which is more than most workflows manage. If you are still settling the tools themselves, our guide to choosing the right graphic design tool covers that decision separately.
FAQ
What is the best naming convention for design files? The one your whole folder can follow without thinking. A workable default is project, then a sortable date or number, then a short description of the state — anything where sorting by name also sorts by time. Consistency beats cleverness: a mediocre convention applied everywhere beats a perfect one applied to half the files.
Should I embed images or link them? Link them for anything that might change or is reused in several places, and keep the linked files inside the project folder. Embed small one-off assets, and embed or package anything leaving your machine. Either way, package the document before it travels.
Do I need version control for design work? Rarely in the software sense. What you need is the ability to answer "what was approved, and when" — which named versions in your tool's own history, or clearly ordered filenames, both provide. Reach for anything heavier only when several people edit the same source in parallel.
Should I outline fonts before sending a file? Only for final print artwork, where nothing more will be edited. Outlining makes text uneditable and unsearchable, so for anything a colleague or client may change, keep live text and supply the font list instead — after checking whether the licence lets you share the font at all.
How long should I keep old project files? Longer than feels reasonable, because the request always comes. Keep the source file, the final exports and the linked assets; delete the intermediate exports and the rejected directions once a project has been signed off for a while. Storage is cheaper than rebuilding a logo from a screenshot.
The test for all six is the same: could someone else — or you, next year — open this project and be productive within five minutes, without asking a question? Run the ten-minute pass on the file you have open right now, then keep the habit. For more practical guides on design tools, exports and workflows, visit MyDesign Tool.
