Why do we need a naming convention at all?
The biggest reason is shown in the above figure. Yes, no third person can identify which artboard belongs to which flow or module.
Very often, designers get so involved in making screens and designing the flow that they forget about scenarios where they have to handover the files, or expand the team and make the files accessible for other team members, or even share the files internally while working. The pile keeps on increasing and there is no other way to look for them later on, which creates dependency.
Art-board Naming Convention
Developers get cranky when they don’t get to see the screens in a particular flow. Not only them, sometimes designers themselves forget which flow they were on, while presenting. One cannot depend only on memory, and almonds are pretty expensive these days.
You might feel it’s redundant when you’re working alone, but when it comes to bigger teams, it’s kinda important. It might still feel laborious or a waste of time but trust me, once it’s done, life becomes easier for a lot of people, including yourself. It saves you the extra adhoc time that you’ll unavoidably spend in the end, naming them all together.
There can be n number of ways one can define the naming convention, here is what I did for Cogoport.
Cogoport’s Art-board Naming Convention(ANC):
1_0_PARENT SCREEN_FEATURE_PLATFORM
1_1_CHILD SCREEN_FEATURE_PLATFORM
Platform can be Mobile(MOB), Desktop(DSK) or Tablet(TAB).
Examples:
3_0_SHIPPER VERIFICATION_KYC_MOB
3_1_ERROR_KYC_MOB
3_2_GST UPLOADED_KYC_MOB
3_3_IEC FILLED_KYC_MOB
Using numbers plays a very important role. It creates a nest that belongs to one parent screen and avoids repetition. You don’t need to write the name of the parent screen every time.
This way, all the art-boards are set in a working flow, and you don’t need to dig deep to find them. Plus other stakeholders can easily access them by a simple search.
Edge Case:
If we break down a feature into separate files. For example, if we make different files for Consignee Management and Vendor Management (but they’re a part of Profile), we treat the sketch file or page as “feature”.
Example:
1_0_LIST_CONSIGNEE MANAGEMENT_MOB
1_1_ADD MORE_CONSIGNEE MANAGEMENT_MOB
File Naming Convention
When it comes to naming your sketch files, the foremost important aspect is the “Feature”(for example, KYC). Using numbers becomes redundant in this case. If anyone needs to find the file, they’ll just search by the feature name and they’ll get what they’re looking for.
Other important aspects are:
- Whether the files are a part of UI or UX.
- Which module they belong to.
- What version you are working on.
This way, you don’t need to change the name of the file every time you make an iteration.
Cogoport’s FNC:
FEATURE_UI(or UX)_MODULE_VERSION
Examples:
KYC_UI_ONBOARDING_V3.0
CREATE_UI_QMS_V3.0
File Organising Convention
Remember the time when you needed a sketch file from your team mate to take some UI component or to refer a flow? How they used to send the files on Slack every time and you kept on downloading them again and again coz obviously you didn’t remember the name and it was a hideous task to look for them in your finder?
Life would have been simpler if there was a File Organising Convention in place. There is now!
We decided to make things simpler and use Google Backup and Sync to integrate drive on our finder.
We decided to organise the files module wise, then version and then the stage of the design process that we’re on.
This way, you don’t need to ask for the files every time or get stuck if your teammate is absent. The process gets streamlined, reducing dependency, and allowing other stake-holders to access the files whenever they want.
Train people to use it
All this is fine, but the actual problem occurs when people don’t use the system. It’s a perpetual process and all team members need to follow it religiously. If at any point, any team member feels that the system needs to be changed or updated, they must discuss it with the team and bring everyone on the same page.
Thanks for reading!
