UI 设计师的文件命名规范的终极解决方案
第一部分：
命名，是困扰很多 UI 设计师的常见问题之一。从我们开始在软件中设计内容时，就要对图层、图层文件夹进行行命名，到对接开发的时候，还要对切图进行命名，再到管理我们的版本，项目文件目录，命名技巧都是不容我们忽视的团队协作技能。
这类文章网上写了不少，但很多课程里的同学去查看以后还是觉得无法在实际项目中应用。这是因为，只学一些常用词汇或命名格式，只是聊胜于无，无法真正加快我们的效率。
尤其在今天，越来越多的互联网团队开始使用云服务同步项目文件，如 Dropbox、Google Driver、Synology、坚果云等等，这使得我们的项目文件还要暴露在所有团队成员的公共视线之中，命名已经不是设计师一个人的事，重要性越发凸显。
下面，我们来完整讨论讨论关于 UI 设计中文件命名的规范和要点。
首先从文件的命名开始，前面提到的 “适当” 一词，就是因为对 UI 文件进行命名是没有唯一标准的，如果只靠对命名的死记硬背，依旧会在项目中遭遇诸多阻力。
要知道，之所以需要命名，它的目的是为了方便我们——检索，让我们可以更高效的查找到指定的文件。
比如日常工作我们会发生如下的场景：
需求方突然要你提供一年前某个版本迭代设计中被惨拒的稿子，重新进行审核评估，你得从自己根目录就有几百个文件夹且毫无排序逻辑的移动硬盘中重新把它找出来……
有天你临时请假，同事打开你的电脑，得在你已经被图标铺满的桌面上找到当前项目文件和指定页面……
一个比较大的项目，进入开发阶段，前端同事们接受并解压了切图文件夹，看见里面包含了名称是 “新的图层、新的图层(1)、 新的图层(2) …… ” 的近 300 个 png 文件……
我们找到一个想要的文件，不是每次都在目录中进行遍历，也就是全都看一遍看到想要为止的笨方法。如果没有有效的检索方式，那么任何人都只能在计算机海量的文件里裸泳，溺亡是迟早的。
所以命名要先从检索文件的方式说起，主要包括以下几种：
层级
排序
标签
搜索
层级检索
层级检索源自文件位置的层级结构，可以说是所有接触过计算机的人群里最朴素的文件收纳方式，比如在我们熟悉的 Windows 存放一张照片，那么路径大概是这样的：
选择硬盘 → 多媒体文件夹 → 照片文件夹 → 照片类型/日期文件夹
在 Windows 中，由于某些历史遗留问题，表现形式都在鼓励使用层级逻辑来存放文件。最显著的莫过于硬盘分区，C 盘既然已经被默认分成了系统相关文件分区，那么 D、E、F 盘自然就应该是划分出游戏、学习、电影的分类。
而 Mac 系统弱化了硬盘分区的概念，在 Finder 中更多突出了对文件进行标记，高效主动查找功能 Spotlight ，也就是暗示你文件存在什么地方都无所谓。这是很多 PC 用户刚刚切换到 Mac 不适应的原因之一。
排序检索
排序就是计算机文件排列的方法，无论是 PC 还是 Mac，在文件夹空白区域点击右键，都可以看见排序方式的选项。有文件类型、名字首字母、创建日期、修改日期、大小等等。
在日常中我们使用这个排序功能最频繁的原因，应该是文件没有对齐网格，所以使用排序功能帮我们快速整理。
而在一个文件非常多的目录中，我们就可以通过使用不同排序方式来快速找到我们想要的文件。
比如 Windows 经常会有 某.dll 引发错误的提示，我们要通过名字排序的方式在 win32 文件夹下面找到这个字母开头的文件区域，再向下一个字母缩小搜索范围，然后很快就能清楚这个 .dll 文件是否存在。或者，我们解压了某个游戏，它的根目录文件特别多，于是我们就会使用类型进行排序快速找到 .exe 结尾的几个启动图标。
标签检索
在 Mac 中，标签功能是被重点突出的，可以很方便的创建、分配标签给文件。这样，我们就多了一个维度来查找文件。
比如一个项目名为 “超人的电话亭” 的 Sketch 文件因为版本或者功能的原因，要分别存放到不同的文件夹内，没有刻意使用层级系统进行分类，那么如果有一天我需要找出并另外备份项目中所有的 Sketch 文件，那么就可以在一开始打上 “超人的电话亭” 标签，以后只要选中这个标签就可以立即筛选出这个项目的文件。
再到类似 Things、滴答、印象笔记、Bear、Eagle 等会包含大量目录文件的应用，都会提供标签这个检索维度。
这个功能在 Windows 资源管理器中是可以忽略的……
主动检索
主动检索就是搜索，就是在输入框中键入文字内容，直接根据名称或者标签、类型来查找你想要的文件。
这建立在我们对文件名称已有一定了解的基础上。例如想要快速找到之前切图中的登录按钮，你可能就会直接输入 “登录” 或者 “按钮” 这些关键信息。
而如果文件名本身没有和内容有任何关联，或者这种关联是混乱的，那么搜索自然无从谈起。
文件命名总结
项目的文件命名，说到底叫什么、用什么英文简写、大小写和符号都是次要的，我们是要通过命名这个步骤，加快前面 4 种检索行为的效率，而不是为命名而命名。
并且，在一个团队中，大家使用的电脑系统不一定一致，开发使用 PC，那么你就不能强调文件中的标签。而如果使用公共网盘，那么不同网盘对排序的细节是有一定的区别的，都要经过测试再做决定。
在我给大家提供的思路中，只已两种检索模式作为出发点，即层级和文字排序，因为我认为它们具有最广泛的适用性。
并且，好的命名系统一定是紧密结合项目文件管理方法的，它能帮助我们有强迫性的对文件进行分类和删除冗余的部分。即使任何一个人打开我们的项目，也能轻易找到目标，才是我们追求的方向。
文件层级
项目开始时，要先规划清楚，会出现哪些类型的文件，做出层级的划分。
例如，在我过去的某个项目中，第一个版本文件包含的分类有 PRD文档、Sketch 原型文件、Sketch 设计文件、其它设计文件、动画源文件、参考图片、应用素材、导出展示图、导出交互动画、设计说明、切图等等。
那么我们将他们分门别类，就可以得到下面这个树状图：
那么，我们就可以以此在名称为 V1.0 文件夹下方创建各级子文件夹了，之后将对应的文件置入到指定层级文件夹中，就完成了我们初步的文件整理方式。
当然，不同项目性质和流程可能会有增减，最终确定的层级是需要自己整理的。即使一开始定义的不够完整，那么随着项目的深入，你可以直接在同级中插入新的文件夹即可。
而我们的命名系统，从这里就开始了！
文件夹命名
我习惯使用数字作为同一个目录文件排序的方式，因为数字最容易被我们记忆，并且可以营造秩序感，减轻我们打开文件夹的焦躁。
上面是一般我会使用的文件夹命名方式，即使用—— NO._文件夹名称。
因为默认排序方式“按名称”会自动根据数字递增，那么文件的序列就能保持不变，使用几天以后，这种数字序列就可以被我们有效的记忆。即使几天后增加一个新的文件夹—— “8_活动文件”，也不会影响到前面已经沉淀下来的习惯。
试想在你的手机上的微信启动图标，用的次数足够多时，我们其实记忆的就是它是第几行第几列，而不是根据图标样式和应用名一个个看过去。同时，这样划分的文件夹，任何项目相关的人员都会很清楚应该如何查找自己需要的内容。
画布命名
在文件夹内的文件，是否一样需要有效的序列，也要根据文件的具体属性来确定。如素材图，有没有特意命名都不是太重要，因为它们没有记忆和反复提取的必要，保存下来只是做备份而已。
而界面展示图，意义就不一样了。多的有几百个界面，少的也有二三十个，如果我们没有任何命名和排序模式，那么看起来会非常累，找一个指定的页面也非常累。
所以该如何做出有效命名，就要从设计界面时的目标开始说起了。一般分为两种情景，一种是比较大的工程，涉及到非常多的界面和模块。另一种是以完整业务流程为准的设计项目，那么它们的排序上就会有一定的差异，大致如下方所示：
模块_子模块_类型_状态，演示:
设置模块_个人资料_头像裁切
启动模块_注册_验证码填写_验证失败
流程名_流程步骤页_状态，演示
发布流程_内容填写_照片编辑
购买流程_提交付款_成功
基本的文件命名，都会根据层级从上到下通过下划线分割。之所以需要这样的层级划分，是因为我们可以用来命名页面的词汇是有限的，如果一个应用中出现了很多都要称呼为设置的下级页面，那么最好要清楚它的从属关系，是哪个页面跳转进来的。
导出的界面图片命名，实际上就是画布的命名，以 Sketch 为例，设计还未导出的阶段就要做出整理。Sketch 中有个关键功能是左上角的 Page 列表，我们可以通过创建不同的 Page 将整个 APP 的页面进行分类。例如下面的案例：
我将整个 APP 划分成了 8 个大模块，每个模块前面都增加了一个序号，并且这个序号对应我们的正常浏览和权重的顺序，之后再对每个画布进行命名，这样不会轻易搞混。
而在画布的命名上，除了前面提到的下划线层级以外，数字的排序依旧是要使用的。因为当我们导出了大量的页面以后，查看的习惯就是放大一张一张向后切换，而这个向后切换的过程是需要有明确排序的，不能看了第一页是购买成功，切换下一页就是启动页。
所以我导出的页面命名画风是这样的：
第一个数字是模块序号，不仅快速表明所属模块，同时等于将所有页面做出了分类。而在第二级开始对页面做出命名，根据操作顺序和权重，在页面名字前面再增加一个序号。
比如社交模块下的详情页，就可以这么表达：1_2详情页。
但详情页不会只有一个状态，可能涉及到带有评论的，不带评论的。或者详情页下属所有独立的评论页面。那么我们就要再增加一个层级，正常情况导出去，文件的排序会受到文字首字母的干扰，m>p>y，于是实际排列就会是这样的：
1_2详情页没评论
1_2详情页评论详情
1_2详情页有评论
如果评论只有一个状态，但是包含下级页面，那么可能命名后实际的排序就会变成下面这种情况，下级页面排到前面：
1_2详情页评论详情
1_2详情页
所以，为了解决这些混乱， 我会在详情页后面和下一级标题前面都增加序号。比如：
1_2详情页1_1完整样式
1_2详情页1_2没有评论
1_2详情页2_1评论详情页默认
1_2详情页2_2评论详情页空白
1_2详情页3_1点赞列表
1_2详情页4_1转发列表
命名最多只需要保留4层即可，再长下去已经回很明显的干扰我们查看，并且中文实际应用起来是比英文高效的，因为英文字符占位大多不如中文精简。
虽然这么看起来命名似乎非常复杂，但只要适应一下很快就能习惯并应用自如。因为这种命名的方法除了在导出后可以按顺序查找，还会强迫我们思考页面的关系，并会根据这种关系来排列 Page 中的 Artbord，我的习惯是独立页面横向排列，不同的状态就纵向排列。
而不具备这种规律的复杂设计文件，会出现什么情况，借用上家公司拿到手的主要页面源文件举例（实际页面数大概是这些的10倍）。虽然模块有一定的分类，但是层级太碎片没有逻辑，所以这些模块的位置很难记忆，我们每次都要先花很多去定位到模块位置，再浏览页面内容来找到想要的内容。
再加上其中每个模块，实际上都有一个独立的 Sketch 存放更完整的设计文件，那么当每次我们要查找、修改、覆盖对应的设计文件时，都需要消耗大量的精力。
产品、设计、前后端程序员都需要不定时查看源文件，如果为了这种缺乏体系的命名规则降低效率，长此以往，那造成的经济损失远超大家的想象。
画布命名的规则，之所以要有逻辑和严谨，就是为了在任何情况下，我们都可以快速定位到源文件，对它们进行说明或者修改。无论是给自己、其他设计、其他同事查看我们的内容时，都可以很快摸清楚门路，不会像无头苍蝇一样只能挨个查看。
结尾
好了上半部分就写到这边，命名的系统不是只为了命名而命名，而是结合我们文件管理的逻辑定义的一套检索体系，所以，在死记硬背任何固定的命名模式前，你们先要多思考在一个项目中，文件、界面的层级关系。
下部分我们会再讲关于切图、图层的命名，以及给大家一张完整的文件命名系统思维导图做参考。
第二部分：
这一部分我们要讨论的，是关于切图的命名、图层命名、版本管理的问题。
切图是什么，很多新人可能还是比较懵懂。简单讲解，任何 UI 类的设计图，要通过代码还原成软件界面时，没办法通过代码写出来的图形，就需要设计师导出对应的图形文件，给代码做补充。
比如你现在用手机看这篇文章所在的浏览器或 APP，上方任何图标都要通过导出的切图显示。
而一个完整的应用要导出的切图是有很多种类型的。从图形本身的含义或者是文件的格式。首先说图形的类型，包含有背景图、插画素材、动画素材、序列帧、图标、LOGO 等等。
所以了解怎么命名之前，我们先要知道切图的基本属性和规则。
切图分类
图形种类不少，而且切图的数量可能比较庞大，所以大家一定要先认同一个观点，只依靠命名的方式就能解决所有检索问题的可能性几乎为零。我们还是要依靠文件夹的层级划分进行协助。
比如数量最多的图标、序列帧，势必要单独为它们创建一个文件夹，不能混合到一个目录中。如果有其它某种类型的图形数量也较多，那么都应该先为它们创建一个独立的文件夹。
例如我以前某项目中的切图文件夹划分是这样的：
而最需要我们重点讲解的就是图标部分，因为这里涉及到的下级分类最多也最复杂。比如我们看下面的这个案例：
从右上角到中间的分类底部的导航，出现了好几种不同的图标类型。这是我们在设计一套 APP 时经常会发生的情况，即一套图标规格没有办法满足我们的视觉场景需要。于是，这套项目就出现了多套图标的规格。
再看看下面支付宝服务类型界面，图标数量多，和如“搜索”、“设置”这类功能图标有非常大的差别，把它们放到一个文件夹下面明显是不合适的。
所以文件的划分上，就要清晰。如果是以尺寸划分的，那么就用尺寸的来命名文件夹，如果是类型的，那就按类型划分。比如下面的两种分类：
这些都比较好理解，但是，在所有细节从属上，还有一个优先级更高的问题，就是我们切图面向的手机系统。如果使用了两个平台独立的设计，或是针对平台导出矢量格式文件时，那么在最顶层就应该划分出 iOS 和 Android 两个文件夹，把文件分开导出，便于不同的前端工程师检索。
这里我们集中在只使用一套设计，并且只导出 PNG 的状态，不可能避免的要面对分辨率倍数的问题，即 @1x、@2x、@3x 的文件名后缀。我的结论就是不建议大家再为它们创建独立的文件夹（即使有不少其它文章这么建议）。
iOS 开发中，是直接选取同一个文件的 3 种分辨率，拖进 Xcode 中即可，那么分文件夹就要多次跳转是非常影响效率，如下图所示。而 Android 开发中，虽然程序目录会划分出 hdpi、xhdpi、xxhpi 等文件夹，但这个操作不需要设计师来做，程序员会自己复制出三种分辨率然后改名再置入开发的项目文件夹中（关于改名等等会讲）。
根据以上的说明，完成切图的分类，那么就可以为我们后续的具体命名提供基础环境了。
切图命名
前面之所以铺垫这么多现在才提分类，就是因为设计师导出的切图命名有个最重要的标准——说人话。
网上最常见完整的切图命名模式大致是这样的: 模块_页面_下级页面_类型_状态，而且会给出一堆英语的常用单词供大家使用，那么最后的效果一般是这样的:
Community_PostList_ DiscussPage_ShareIcon_Defult@1x.png
相信大家已经发现问题了，这种命名实在太长了。不止是层级太多，且英文的字数难以控制。虽然很多时候有一些广泛应用的元素如导航、标题、背景之类的都有简写 (Nav、Tit、Bg)，但至少会有一半的词汇你会发现它们是没有简写方式的。
而且，英语不是我们的母语，大多数人英语好点也就 4 6 级水平，如果一个抽象、不常见的词语，如 “拼团”、“发红包”、“种草”、“拔草”，确定你们词典查的英语词组是合理的吗，这些东西简写就更看不懂。
再者，开发命名之所以使用英语，是因为在代码里不能使用中文，如果直接用拼音的也太不敬业了。我们的标注是没有必要给自己框定这样的限制的，或者强行认为只有标注英文看起来才有逼格专业。强行英文的结果就是导致你自己以后看不懂，别人也看不懂。
有的人可能还会讲，命名就是要根据开发的习惯来！这里再解释一件事，就是除非切图命名这个规范是经团队商议，由开发整理给你的，不然不要企图认为自己的英文命名具有普适性。
多数开发人员有自己命名的习惯，你的习惯和他的不可能完全匹配上，所以正常项目中程序员会根据他们自己或开发团队的习惯命名，那就有另一套体系，我们的命名只是为了让他们能快速找到指定的文件而已。
所以，前面的文件夹分类就是帮助我们分割不同类型的图标，让我们的命名可以更简洁精准，逻辑更连贯，降低查找图标所需要的检索成本。这时在每个文件夹中，切图的命名就可以只用 3 级以内搞定。即：
模块_名称_状态
在真实环境下，使用的名称基本就是：
设置_钱包_高亮@1x.png
动态_评论_默认@1x.png
登录按钮_点击@2x.png
紧跟交流中使用的习惯来制定，这样的命名才是简单易懂易用。只是纯形式化又复杂的命名规范，只会倒逼程序员通过放大切图缩略图来查找指定的图形。
图层命名放到切图后面来说，就是因为我们对图层的命名首先要根据切图的需要制定，养成保证导出的时候不需要对切图文件有额外的命名修改，图层命名直接可用。
虽然大家都推崇在设计文件中命名要细致，恨不得每个图层都写上清楚的图层命名，但我要在这边给出不同的意见。
PS的图层命名
先讲使用 PS ，命名是非常非常非常重要的。原因和 PS 的操作逻辑有非常大的关系，难以用鼠标直接在画布中选中指定的内容。比如下图这种比较常见的 PS 合成场景。
这种场景起码有几百个图层组合而成，而这么多图层中，还有大量的光影效果层覆盖在手表上方。如果我要用鼠标直接在画布中选定手表，那基本只会选择到手表上方的高光层，还不清楚是哪层高光。所以，选中和调整 PS 图层内容都要直接从图层列表中查找。
而这种情况不把图层命名清楚，那源文件只会是大型车祸现场。随着图层堆叠的数量增加，到后面你每做一个改动都会非常艰难。删除无效图层、修改前后关系、对某个部分的所有图层进行调色处理……
所以在 PS 中命名多细致都不过分，因为这样自己才能看的懂，别人才明白怎么修改你的源文件。
Sketch / Adobe XD 图层
但是，在现在新的 UI 设计工具中，环境就发生了变化。需要我们进行细致命名的绝对条件已经不存在了。
UI 的设计没有那么多不可见并堆叠的图层，按住 Ctrl 或 Command 键，你几乎可以选中任何看的见的图层，这时候对图层列表的依赖也就远远没有 PS 那么深。
而且，一个 UI 项目的页面和零碎的元素实在是太多了，如果真以细致到每个图层都不会出现默认新建图层字样的地步，需要耗费极其庞大的精力去维护，而这个维护的结果可以增加的团队效率并不显著。
因为无论是你自己还是别人，修改文件的时候直接用鼠标去选中对应图层就可以了，你命不命名都对操作都没有太多直接的影响。当然，我们还要有一个好的习惯，就是不要依赖隐藏的图层，尽量使用一个新的画布来表现不同的状态。
基于这样的性质，在 Sketch 或 XD 的文件中，只建议大家做出适当的命名操作，而不用太纠结于形式的细节，要把每个图层都想命名的无用强迫症，应用在对整个项目文件的管理和思考上。
第一，我们要能在画板根目录上，编组所有层级最高的模块/组件，命名这部分的内容。下级中相对重要的模块文件夹，也可以适当增加命名。
第二，尽可能的将类似图标、LOGO这些必然要导出的图形，制作成 Symbol，并做好清晰的命名。
第三，Sketch 中如果将一个完整的组件做成了 Symbol，那么要对其中文字图层的命名做出清晰的排序和命名，这样才能正常更改其中的内容。
当然，图层和命名和前面关于切图的命名有一样的要求，就是——说人话。图层名可以显示的字符比文件夹列表模式可以显示得少得多，很多喜欢用英文命名的源文件，经常图层名长到只显示了一半就“…”，这样的命名更没有意义。
最后，就是关于版本管理的问题了，网上有层出不穷的关于怎么管理版本的方法，这里奉劝各位，希望借助外力和工具的版本管理方式，都是不切实际的。
无论是 SVN、GIT 的技术类管理方案，还是使用坚果云、Folio之类的第三方工具，会将本来不是太复杂的问题高度复杂化。这是因为造成我们文件版本变更迭代的事件太多了，使用这些方法不仅要大量精力维护，而且其中会有很多不可控的因素产生，造成混乱。
在我过去的项目经验里，只推荐一种关于版本管理的方式，那就还是文件夹和命名，简单的才是管理复杂最有效的方法。
即每次遇到设计文件、文档需要更新替换，或是大改动（不是只加新的内容进去），那么就在同级目录中，创建一个版本回收文件夹，复制一份当前的文件进去，再开始修改。
每个复制进回收站的文件，命名都要做下修改，方便后面可能的查找。通常命名的格式为——日期_版本简单说明_，效果如下：
这样不仅自己操作起来方便，而且其他人也可以很容易的访问查找你的指定历史版本。得益于目前 UI 文件体积的精简，一个 Sketch 文件通常几十 MB 就能搞定，所以记录很多版本也无所谓。当然，如果项目出现比较大型的 PSD 或者视频文件，那么对于版本的管理就尽可能的精简而不是多多益善，否则会在共享和传输上造成极大的压力。
而除了具体到某个文件的版本管理以外，还要考虑一个更高层级的管理，即项目版本。相信很多人有这样的经历，在开始后面的版本时都创建新的文件夹和设计文件，于是在几个版本过后要反复在几个项目之间切换查找页面。
所以，我的方式是设计第一个版本是 v1.0，那么在开始 v2.0 版本时，直接复制一份原版本的文件夹出来。这样，不仅保留完整的 v1.0 所有项目文件，文件夹能层级可以保留下来。
复制完成后，只要再将除了界面设计源文件以外的其它文档、切图等文件全部删除即可。保留设计文件，目的就是要保持最新版本设计文件的集中和唯一性。所有和项目相关的设计文件都集中在一个目录下，才有利于我们的更新和协作。
要说一个题外话，在我过去的项目中，非常在意设计文件唯一性的标准。当一个产品团队有几个设计师，程序员直接查看源文件的标注，如果源文件不具备唯一性，项目调整中每个人电脑上都存了几个版本，且各自添加了新的内容进去，不能直接覆盖合并，最后只能演变成一场开发灾难。
结尾
以上就是我对于项目文件管理和命名完整的经验和思考，经过了好几年的试验和改进，我相信它可以应付绝大多数的情况与协同需要。
还要牢记，这些看似麻烦的过程，不只是做了给我们自己使用，还要方便所有项目的成员，这种能力一样是一个 UI 设计师应该保有的专业素养之一。
最后极度推荐大家使用同步云盘进行工作协同，首要推荐的是使用自建的云盘群辉 Nas（后面有机会会写一篇介绍），然后是国内现在势头正盛的坚果云。如果是比较国际化的团队，那么无论是 Dropbox 或者 GoogleDrive 都可以，传统的 QQ 传输或是移动硬盘拷贝，都已经不适应今天的生产力需求。
如果光靠上面文字描述，对整体的管理和命名还是无法起到清晰记忆作用的话，我另外准备了一张完整的思维导图。
大家只要在公众号后台回复下方文字即可：
"文件命名"
感谢大家的收看！
第8期B端产品设计全能班开启预约了~给彼此一个机会，现在就预约变强！
