Welcome back; this article is part of the series called Naming convention.

The previous article explored the history and mental models behind sorting information in digital space.[001↗] This article aims to discuss the naming convention of our files spread across drives or remote places. 

Environments 

The remote world eventually moved our internal naming convention from local hard drives to a public space. You name it – Miro, Slack, Google, Microsoft or Figma (or Sketch). Every boss, product owner, human resources or developer knows what we are and how we orchestrate our designs in the company we work for. 

“The messy team equals messy structure, resolving in a messy product or service, period – there is no science about it.”

–Jiri Mcc, Greenwich

The good thing is if you are really organised, the impact is imminent. Upon gaining the respect, you also broaden your influence that could easily expand from design to business and development. 

There is a silver lining between imposed file naming convention and a carefully crafted one. Do make sure you work with your development team first to align on the basics of how the names work in their specific world and how we can make them more prominent in our designs.

Acronyms 

The red flag goes with making everything an acronym or abbreviation – 

even though it can be very efficient once embedded. It also has to be digestible to a broader audience. So if your team serves cat food in your company, you don’t have to call it “CFC – Cat Food Company”. 

The challenge with some acronyms comes with an ambiguity of the meaning. Once, on a project, we had the acronym CWA. It meant four different things – you most certainly want to avoid that.

Method

I have settled on the following. Call me old school, but I have crafted the structure and naming convention since 2000, and now this effort massively pays off. Throughout and after finishing the projects for a specific client, I’ll rename and adjust all the files for easier and smoother access later.

Year 

The first part of the file is the year - in the format YYMMDD. This allows me to have an understanding of when the file was created or when it was shipped. 

Some of my folders start with the year, for example, “Y22 TCN SOW,” which tells me everything I need to know about the Statement of Work (SOW in short) of specific clients in that year. 

Question: Why don’t you use YYYY? Because we’re at the beginning of the 21st century and no one will ever look for the files from 1982 that need to be integrated into the following release. So, I shortened it for YYDDMM (220217, for example) and used folders that start with /Y22 (inherited from old-time coding).

 

Project Name

Project names are abbreviated or shortened to three letters. Having a project name defines a specific piece of work for one client. Now in the corporation, it can go as complex as: 

client “TCN”, 

transformation name “TSN”, 

Project Name “PRN” 

This allows me to distinguish between different projects in the same transformation initiative.

 

Release (aka. versioning)

Although not previously common amongst designers, one thing we’re seeing more often are the release names Alpha “AL”, Beta “BT”, Candidate Release “CR1.0” 2.0 and so on. That allows me to ship specific versions to specific developments and releases. It allows designers to work on two releases simultaneously without missing the death line or mixing the assets. 

Design System

We are all on the verge of design system expansion. Everyone talks about the colours, pallets, and tokens. Very few articles debate the point of versioning and different releases, rebranding and international design system supporting multiple markets with LTR & RTL UI, etc. 

Since the early days of design, I’d always include the name (or an acronym) of the Design System (later referred to as DS) – at Sky it was SKYOS1.3, and in LloydsBank, it was Constellation Co1.0 showing the DS and the version. 

Accessibility

All the above leads to broader accessibility amongst files that use the same naming convention across the business and development. 

Anyone in the same unit or transformation is aligned with the product team by locating files on the server, in Jira, Trello, dropbox or Confluence. This saves 32% of productive time (Assuming all participants agree on the naming convention, respect it, embrace it, and maintain it).

Scalability 

Establishing straightforward guides about the names allows teams to franchise this thinking and move beyond one team or team. It inevitably empowers department units that deal with a vast amount of data – like research, insights and copywriting. 

As of now, three documented case studies represent an infinite scalable model allowing designers to simply start the file from the master and link all design systems – DS into a project file. Once executed, the file can be translated to a prototype or production file from SD to CX to UI assets. 

Adoption

I can not speak for Sketch and Abstract as I haven’t tested them thoroughly; the convention's adoption was swift regarding Adobe (/Y00-18) and Figma (/Y16-22). It also plays in various technical environments – such as broadcasting, finance, trading, and aviation.
(Feel free to add your question or DM me for more details). 

Integration 

One of the main advantages of our naming convention influenced (or defined) by design is the broader integration beyond the design function. In six months, we have started seeing product owners start using the same formats for their PPTX and our Confluence and Jira structure evolved to the point of a unified “Knowledgebase” – the result, everybody can find whatever they were looking for. 

Where next 

We’ve got the primary, not rocket science, here: As a genuine note, try to look at your current folder structure and ask yourself the following questions: 

1/ Do you know what you are looking for?

– Specific design
– Version
– release or iteration. 

2/ Do you know what are you opening?

– if you are certain it saves you 23% of your time. If not it burns you 49% of your time
– Visual Search is 30% faster than word /read search. We have specific tiles that allow us to know what is inside.

3/ How do you link/update your files? 

– Having smart objects (Adobe) or design system (Figma), where is your library?
– is that a unified and centralised place or is it well redistributed?

4/ How many people are working on one file?

– One 
– many (if many who is the owner of the file)

5/ Do you know the status of the file?

– Draft
– Work in progress 
– DOR – Under review 
– DOD – Delivered (aka final sign-off version)

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to find your feed in teams of 01, 10, and 100, supported by Grid Magazine and Supply section, where we weekly bring more insights on how to become a design leader in your organisation.