;

Impact of File Naming Convention on delivery.

Featured Image

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.

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

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.

Figure03: Detailed explanation.

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. 

Figure04: The convention accessibility via multiple touch points.

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

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

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)

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

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. 

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

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. 

Tagged: agile · coaching · collaboration · cx · dastm · design · designatscale · designer2designer · framework · madebyhuman · management · mentoring · Method · organisations · process · scale · sme · startup · ux · ways_of_working
EMT

Related.

Featured Image
Over the centuries, we humans have improved our tools to be sharp, resilient, and robust enough to conquer different materials in specific conditions. With digital ventures, we invented software to carry out digital work …
 · 
2023-01-04
 · 
8 min read
Featured Image
Welcome to the fourth article of this series that focuses on designers in the team of one. After touching on Ambitions, Beliefs and Design Philosophy, we are entering the more practical part of the …
 · 
2021-01-25
 · 
5 min read
Featured Image
Hi, I’m Jiri (in short J+). I’m a product designer who has coded since 1992. Before creating a design system, I built a wealth of brand guidelines and marketing packages for small, medium, and …
 · 
2023-01-02
 · 
13 min read
Featured Image
Welcome to the second article of the Design at Scale — Academy, which focuses on a designer in a team of 100. This article will explore how to evaluate a team, department, or business …
 · 
2021-05-21
 · 
5 min read
Featured Image
Welcome back to our Design at Scale – Academy series, focusing on the design practice in a team of one hundred. This article explores how design functions integrate within a business structure from three …
 · 
2021-05-14
 · 
5 min read
Featured Image
Welcome back to our Design at Scale™—Academy series, focusing on design practice in a team of one hundred. This article delves into the intricacies of integrated design teams within agile organisations.  While "HR organisation" …
 · 
2021-06-04
 · 
6 min read
Featured Image
Many designers worldwide ask the same questions repeatedly “how do we deliver our design at scale?”. In other words, how can we adapt to the change where our remits start and finish?   The answer …
 · 
2020-02-01
 · 
4 min read
Featured Image
Welcome to Design at Scale – this article will focus on the mindset and how implementing such a mindset can make a difference in Product Design Delivery. To understand the mindset definition, let’s borrow …
 · 
2020-01-30
 · 
3 min read
Featured Image
Welcome to the Design at Scale Method series. Today’s article has no more minor ambition than to connect, empower and unify all product designers under a simple Manifesto, which easily translates the value of …
 · 
2020-01-26
 · 
3 min read

Newsletter

Subscribe.

Subscription.

A tailored list of meaningful tips and assets that help designers of all levels manage their daily challenges at scale.

100+

Design Articles 

Join more than 5,000 readers who redefine product design delivery through Design at Scale™

INSTAGRAM—We know you love visual stories and bite-size quick suggestions. That is why we created an Instagram channel specifically for your taste. 

X – Daily updates, shared links, and conversations about scaling design propositions in small, medium, and large teams. Join the conversation.

DAS-Social

Your Story
Matters.

Contribute.

We're sorry you haven't found what you were looking for. Let us know your story, and we'll ensure it's broadcasted to the world.

All brands and trademarks presented on the DesignatScale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners.
Do not copy or publish any of the projects shown here without approval from 9V™ + GIVE™ + Design at Scale™ and/or relevant companies and agencies.

View