这次讨论主要是针对设计团队在figma、即时设计等在线协作平台的文件管理，其实这些内容互联网上面已经有很多大佬讨论过了，但是要么不够完善，要么就是在实操方面还是不够便捷，有优化的空间，今天就结合我自己工作中的经验来分享一下，不一定是最好的，但是目前来说是比较适合我们团队的。
1.要找到之前某个时段、需求的设计文件简直大海捞针，新旧文件散落各地；
2.某个项目更新迭代比较块，UI画布也越来越多，导致满屏都是画布，严重影响加载速度；
3.每当有新的需求，就直接新加页面，没有做版本管控，导致同事互相协作成本增加；
4.组件也没有有效管控，没有形成规范的组件库，查找起来极其费时......
在我刚接手现在的项目时，所有页面、交互、归档文件、组件库文件全部都放在一个文件内，只对主要的功能进行了简单的划分，如下图：
列出问题之后，我们就要对其拆解并分析，可以得出我们的需求：
1.版本管控：更新要做到能被记录，可以随时追溯某个版本某个时期的需求；
2.要优化项目的层级，做到清晰有序，尽量减少单个文件内的画布数量以提升网页运行效率；
3.交互和UI尽量能够在一起协作，之前都是交互稿一个文件，设计稿一个文件，解决协作难的问题；
列出需求以后我们便可以开始着手管理规范的搭建了。在我接手的项目中，所有内容大杂烩式全放一起，有新增的就在原来的画布/页面中新增，只有版本完全更新换代才会归档。这种方法只是把Figma当作一个“大型的在线文件夹”，没有发挥出“团队功能”的特性，越屯越多就会导致开头我说的问题，因此我对项目整体层级进行重构。
在层级重构中，我把整体层级向上移动了一级，最重要的一点就是将需求、UI、规范这一层移动到了文件内，这样可以专注于某一个文件夹内的每个阶段需求，也可以减少每个设计文件内的画布数量，加快网页运行速度，接下来我们逐层拆分讲解。
我们原来会把所有的不同版本的APP放在这一层，迭代也放这一层，这就导致，虽然是服务于某一个APP，但是这个里面既有不同版本类型的分支APP，也有迭代过的APP，测试和开发人员经常提到找某个版本APP的具体页面很难。我们需要让团队单独服务于某一业务，就不要把其他业务放在单个团队内，应该新建一个业务线，重新规划项目文件层级。
在团队层我们确定这个会专门服务于某一业务线APP，那么我们可以开始划分项目层的类型了。项目层是服务于某一业务线的全流程，那么项目层的分类依据我们可以按照以下类别：
1.业务线的功能模块：例如首页、我的、小首页、消息等
2.通用的项目资产：比如整个业务线的运营规范、通用的素材库（icon、字段、素材等）、整个业务线的视觉规范（垂类视觉规范可在其分类下新建）、用户调研等
3.归档文件：不会再进行更新的版本可以放到这里，避免和现有进行版本冲突
4.其他：例如外包需求、项目说明、PRD等等...
只要是服务于某一业务线的全流程，那么就可以在项目层这里进行分类。
在这一层我们主要服务于应用的功能模块，基本都是在处理功能模块的需求，所以我们可以围绕需求来展开。建议按照需求量更迭的时间线去分类，比如更迭比较快可以按照季度新建设计文件，更迭慢可以按照半年或1年的频次去新建文件。
同时在设计文件内建一个画板，规范好封面的类型和命名规则，用不同的颜色区分开，可以帮助项目同事快速找到需要的设计文件。可以参考以下我的分类，还可以在封面上加入设计师、PM等职位记录。
在项目层中我们还可以善用置顶文件功能，将当期进行中的文件置顶，方便团队快速访问。
页面层是设计文件打开后左侧的页面排序，这里先整理一下我们团队的工作流程。
根据流程我们可以按照这个思路来进行页面的分组，我是这样做的：按照需求开始和上线时间进行命名，这样就可以知道这个需求是什么时候开始，什么时候要上线了。然后在下面就是具体的需求类别，用🔨表示正在进行中的需求，用🎉表示已经完成的需求。如果有延期则在画布中标记（顺便吐槽一下Figma赶紧出一个分类折叠的功能吧，有的时候需求和页面实在是太多，得下滑好久)。
到了页面层我们可以规划得更加详细，附上我们团队大概的流程和布局。
在处理需求时，可以在讨论区开始需求讨论，这里啥都能放，建议 、素材等。在确定之后会整理好更新到需求详情中去，交互和视觉稿尽量放在一起，方便对比。在下方可以放带遮罩的草稿和废稿，方便记录。
处理完需求需要把更新的页面
立即同步
到UI视觉设计文件中去，方便管理功能模块的整个页面。同时也方便团队成员的信息拉齐。
这里有一个注意的点，比如淘宝、京东那种首页的运营位，它们的样式变体极其多，每个运营位的算法推荐极其复杂，一般会有详细的说明文档，而且可能样式算法会新旧交替使用。我们可以这样管理：将首页和分页面详情按照权重分开，这样就方便团队成员查看首页有哪些组件样式或者分页面了。参照前文我讲的，也可以把交互放在这个画板旁边方便对照。
我们还可以通过Figma复制链接功能，将文档之间相互连接。这个功能不仅能在单个文件内画板之间相互运用，也能跳转至其他文件。比如在首页我想访问推荐页面的使用规范，我就可以通过点击说明文档的文字跳转至规范说明页面。（非常好用！推荐！）
这里再讲一下我对具体页面的命名规则，比如首页的设计文件命名为1，属于首页下的搜索画板就命名为1_1搜索，第一个数字是序号，这就相当于给模块分类了，以后大家看到1这个序号就知道这个画板是属于首页的。然后功能模块下的分页面，可以根据权重来进行排序，比如某宝首页搜索比扫一扫用的多，那么我们可以命名为：
再比如淘宝首页的商品详情有很多种不一样的，每个详情又有不同的状态（有评价、没评价），我们就可以这样命名：
同时，不同的页面我们可以横放，相同页面不同状态可以按照权重竖着放，这样其实也相当于在分类了，分类的原则是有新的页面就在名字后面加一层。命名最多保留4层，太多也会影响检索效率。比如：
1_1小首页_1小首页推荐_1默认推荐状态....
团队成员都会不定期去查看设计源文件，缺乏有效的命名体系会导致查看效率极其低下，一旦项目庞大页面过多，只能诶个查找，导致效率极其低下。正确且适合团队的命名规则可以极大程度提升我们的协作效率。
以上命名推荐也只是分享我们团队目前在使用的。不一定适合每个团队，只是分享一个思路，要用什么样的命名还是要和团队内成员商量并统一意见。
本篇文章仅仅是分享我自己的文件管理心得。并没有什么管理方法是最好的，最适合团队的方案才是最好的，文件管理是一个需要全员参与和遵守的文化建设过程，规划时务必要考虑到和原来的工作流程，一个好的文件管理方案应该是符合团队实际需求、易于理解和执行，能随团队成长而调整促进而不是阻碍工作效率。
