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

The previous articles explored the impact of folder naming conventions. This article discusses the naming convention inside the CX and UI files before integrating them with our engineering colleagues. 

Why does no one care?

If you talk to any outside of the design practitioner circles, no one would consider naming layers or how the work is done as far as it is shipped. Often though, it is the fundamental difference between the practical (speedy, dirty, copy and paste) and integrated (well-organised, connected, regularly updated and automated) way that impacts the real world. 

You wouldn’t care how your herniated appendix is removed so long as the stitches are minimal. So the cavity operation is done by the first-grade surgery student where the private well-known plastic surgeon will carry your stitches on your tummy and final speech that you should be all ok. 

Fun aside, we often hear from our POs and PMs that no one cares. The agile manifesto says, “Working software over comprehensive documentation," making everything else disposable. If no one cares, why should you?

Should you?

In 1996, I was fortunate enough to work amongst some titans of retouching imagery in Photoshop 3.1.0 – I know, but I hear the story. 

We were preparing the imagery from the 96 Tour de France. Almost 10k images have been carefully scanned from original negatives (no DNGs or NEFs, no Lightroom) and are neatly organised in a magazine-led structure. Every picture was converted to PSD and properly layered out, so we can link them to Quark Express. 

There, I was told to: 

“Name the layers properly so that everyone knows what you have done and can read it as a message from the designer.” – Machacek, Design Director, Margaret Studio 1996.

Many times ever since, this simple practice saved me an excessive amount of time in production. It made me more creative when it came to further requests and changes. I could read and change layers and move objects and other parts of the layout without even looking at the stage. 

The argument I often have to prove is “if we do name the layers, it’s a waste of time to name it” especially if we delete them, right?  Sure, we waste more time copying and pasting instead of automating our workflow, which surprisingly is far quicker (about 63% on average) than naming layers properly.

Regardless, if you already name it, you know what you are deleting or removing, not even mention if it's a component from DS; it’s simple as switching off – you do not have to name it or rename it. 

Smart Objects 

Fast forward more than a decade, Adobe introduced Smart Objects which allows embedded files and advanced versioning. While someone worked on the logo (in Adobe Illustrator), the smart object was linked (and rendered) into all Photoshop files and different breakpoints for desktop, tablet and mobile. We can then easily display different logos and different breakpoints. 

Equally, once the layer coms arrived, we organised our workflow with such precision that 40+ designers could simultaneously work on several PSDs without deleting anyone's work. Good old days when the collaboration had to be under control. 

It also showed when the design ops are done correctly; we can have a dedicated “folder” for all the assets that can be mirrored into a production line. Our engineering colleagues didn't have any questions about where the file or the graphic was or, more importantly, what the file's name was?

Next-Gen 

We all very much embrace Sketch and Figma, but with the arrival of all the shiny tools, the legacy of structured design has slowly vanished. 

Having a chance to review some work across the large financial institutions in comparison to apprentice portfolios, the layering and the name Elipse 3975, Square 4598 and most likely Frame 19083 – which makes it hard to export group or groups or groups that logically or inherently belong to each other.

That said, several sources debate the challenge from the perspective of (a dirty) prototype which proves the concept of behaviour and function between work files with linked design systems and codependency between them.
(new article about naming layers in Figma)

Systems

This brings us to the final point of naming convention and it's a convention of Design systems. Generally, I’d have one UI designer (or UX-er) running the work file and the other “design system designer” will run the design system file. 

With this approach, you simultaneously build a repository of your future implementation. With “variants” and “tokens”, you can really make something magnificent that is not only pretty but very functional and adaptable to your growing exponential needs.

Automation and Algorithms.

I have to mention something that has been with me for quite a while, and only now are we seeing the first successful implementation of it –  it’s the automation and use of algorithms. 

Given the fact that Google releases new code every couple of seconds, it’s not surprising that design as a function needs to adapt to it. Navigate through the complexity of all your assets in each release, iteration and adaptation add to the complexity of your design ecosystem. Algorithms help you to correctly rename 30.000 elements in your APAC version of your software far easier than 30 designers would over a monotonous 10-day shift. 

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/ What am I working on? 

– a very first iteration of the design?
– or a well-integrated piece?
– or something in between?

2/ Does it matter to me or to others?

– if it’s a singular file without possibility of sharing it, knock yourself out 
– if you share it make it count – it should be a story.

3/ When someone comes with feedback, listen.

– two things will happen 
– you’ll learn something new, which is always a good thing
– if it’s a critique of something, try to find a way to better it.

4/ Does it take too much time?

– if yes, you are doing something wrong.
– learn about automation and integrated (linked) design files.
– learn what to reuse and standardise. 

5/ Have one document messy and the very same one organised

– spend a day working on the messy one 
– and then spend the day working on the tidy one

Share your thoughts with us now 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.

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.