The Problem and Examples

As many people as many approaches to the organization of files, folders, layers, artboards. Is this a problem? Yes, it is! Especially when you work in a team or with a large volume of objects.

Good is the key to fast navigation in materials, tracking changes and improve product team communication.

Just imagine how would you ask your client to open particular screen in inVision saying 
Could you please open Projects -Assigned to Me_Unassign Manager Unassign [email protected] ?

And now imagine how you ask the same but 
Could you please open the screen 34?

Did you feel the difference?

And yes I remember that there is a Search, but still…

Let’s look at some examples of the names of mock-ups and try to understand why they are not perfect.

Example 1

Projects-Assigned to Me_Unassign Manager Unassign [email protected]
Admin-Assigned to others Unassign [email protected]

What’s wrong?

  1. The names are very long by themselves and in inVision they are going to be cut and it will be difficult to understand what is hidden after the ellipsis. Not really informative, isn’t it? In the Sketch panel, it’s pretty hard too.
  2. The name is very long and it’ll be quite hard to understand the meaning. Understanding the dependence of the child and parent pages is extremely difficult too.
  3. Adding @2x in the mockup name manually, when everything is already done through Sync in Sketch and automatically created it’s a little bit frustrating.
  4. It is boring to write down a long name.
  5. Complete lack of versioning.

Sixth, it is impossible to understand what was created first, what later. The relevance of the appearance of new mockups is not obvious.

Cut long names

Example 2

Pharmacies Service Administrators Modal Error
Pharmacies Service Administrators Modal Error Upload

The problems are almost the same:

  1. The long name by itself
  2. Not visible in inVision and the Sketch bar
  3. No versioning
  4. History of the creation of screens is missing
Non-informative cut names

Any good things about? Well, somehow you can understand the dependence and that there is an additional status of the parent page.

Example 3

1.0_Sign in_Confirm Info_No code_Desktop 1280x800px
1.1_Home_Unlock Featues_V2_step 2_Desktop 1280

Cut names but we can see hierarchy


  1. Long name
  2. Not visible in InVision and the Sketch bar
  3. No versioning
  4. A lot of unnecessary and noise information, such as the size of the screen, etc.
  5. The dot symbol in the name — not every OS or cloud storage will be happy with the special characters in the name. I strongly recommend to avoid them.
  6. To long to write down
  7. Versions marker in a strange place

But here is something interesting — numbers. But they are still not perfect! Why? Because with a high probability, almost every OS will sort them like this:

And even more strange, when first will go 10, then 1, then 20, then 2 …

Example 4



  1. A strange wish to use the name of the parent in every screen. That is unnecessary
  2. The separation of numbers. Really strange
  3. No versioning
  4. The history of creating screens is not clear, but there are whispers

What well? Finally, hyphens appeared 💪

Example 5

2.0.5 Add New Contact — empty
2.0.6 Add New Contact — in progress

Let’s start with a good:

  1. There are numbers
  2. It seems that you begin to understand the history of screens
  3. It is clear that screens 5 and 6 are children of 2.0 screen and they are different states of it


  1. Dots
  2. Parent name repeat
  3. No versioning

In general, almost everybody forgets about the versions. We often change a screen and it happens that we need to keep the previous one, in the archive, or on a separate page, or even file.

How would you copy and name it? Final? And then final-final? Final-final-final?

The naming hell

There are few ways to solve this problem:

  1. Rewrite the screen
  2. Add the version number to the name
  3. Add the version number only to the archived screens

The first way will destroy all your steps.

The second is excellent for readability, but there is a disadvantage — when you upload it to inVision, it does not change the previous version but uploaded as an independent screen. This is not bad and not good, but sometimes it can become a trouble.

The third option can solve both problems — you can save versions as part of an archive, and an actual file/screen/artboard without a version — it will be always the last and actual. You choose the option.

I personally still prefer to add the version in the end of name so I always know that v08 is more relevant than v07, v06 … v01. They are also sorted, and it is easy to understand which is the latter.


So the second finding is versioning!

Folders naming

Often during a project you get more and more new files, new folders are created, one for the sources, others for the input, the third for the presentation, for testing, etc. For all stages of the project. Of course, sorting by alphabet will not be the best decision to understand what was behind, what happened in time, but it’s important to quickly navigate and remember what you did a year ago, and what was the last stage.

Create a historical hierarchy of all stages of work at the folder level.

My own example:

Historical and sorted project steps as folders

Now it’s obvious that I received a client’s input and put it in 00 folder. It is the main source of information, it is constantly renewed and it is important for me. So it will be always at the top of the structure.

Then I was engaged in the creation of information architecture, then made sketches, then I created a Screenmap, then created a Concept, then did an Animation. Then I created an archive with everything I gave to the Client as a result.

Everything is simple, everything is clear, everything goes one after another.
And the most important thing is that inside each of these folders we can use exactly the same principle if necessary. But in my practice — all the files can be without folders because of there no need to create a deep structure.

Artboards Naming

How to name artboards in Sketch?

If you effectively start to do this at the Screenmap stage, then everyone will be happy. Developers, and managers, and stakeholders! It is quite obvious and clear what to relate to, what is the state of something else, what is a parent, and what is a child. You can start the naming already there!

Screenmap and Naming

And if you also add color coding to different sections, then you have ready flows and obvious candidates for the next sprint 👍

Screenmap with Naming and Color Coding for Flows

As you can see, the first part of the name of any artboard is already done!
Now we apply everything that is described above and just add the short name of the screen + its version and get:


Relative and children

It is quite clear that 04-1, 04-2, 04-3 — are the children of 04. There is no need to repeat the root of the department-info name everywhere and we quickly understand that the file 04-1-finances is the part of the department-info.

The version though doesn’t fit in inVision or Sketch panel — nevertheless, it will help us to understand what artboard is actual, and which is “archived”. The last one is always ‘’the current’’.

And exported as .png artboards will come in a natural and sorted structure in your Finder.

Role based naming

It often happens that you make a bunch of designs for different roles: admin, buyer, manager, etc. In this case, I do a separate Screenmap for each role. In Sketch — I make separate pages or separated visual sections and in the naming, I add the encoding of the role. Thus, in inVision, I immediately see for whom this screen, and then already, which specifically for the screen.

Here is an example of the artboards names for the role of Delivery Lead (DL)

So, what do we have now?

A reasonable naming approach, not only helps to navigate fast among a large number of entities but also allows you to understand the relationship between them, it helps to sort them, read names in various services such as inVision and most importantly — simplifies communication!

– Hey John, take a look at screen 04-1!

Scheme 1:


Naming Scheme 1

Alternative Versions

When creating a large nesting of child elements, you can get confused and lose some readability, getting something like 04-1-2-3-error-v11. In this case, you can try to adapt the system a little and add a character to all child states and avoid large nesting levels. For example: 04A-error-v11, 04B-success-v01, and so on. In this approach, 2 levels are enough.

Scheme 2:


Naming Scheme 2

And the last scheme, I came just recently, is assigning a letter to a specific flow and number for a particular screen. Depending on your goals you can use two or three levels.

Scheme 3:


Naming Scheme 3

There are many advantages to this scheme, and there is only one minus — now it does not fit with the names of the folders beginning with the numbers. So my choice is still numbers. Though…

Which one did you like better?
Do you know a better scheme? Share in the comments!

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here