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. 


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.

Figure02: A made-up naming convention for this article reflecting the topic 


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.

Figure03: Detailed explanation.


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.


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. 

Figure04: The convention accessibility via multiple touch points.


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).

Figure05: Scaling the naming convention across different touch parts of the business.


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. 


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)

Figure06: An impact of the naming convention of the team, department and business.


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. 

Figure07: Where Next – How to ask the right questions.

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 working on one file?

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

5/ Do you the status of the file?

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

Let us know at @designatscaletm
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm