阿里经验！聊聊实用而容易被人忽视的设计整理术

　　


和很多人一样，我并不喜欢「整理」这件事情，我的桌子总会在一段时间后变得凌乱，电脑桌面也经常布满各种类型的文件图标。在具体的设计工作中，(仗着自己记忆力还行
+ 有搜索功能在)也会表现得比较随性，存放设计稿的文件目录乱糟糟，疏于整理沉淀产品的设计规范，交付物的样式经常变来变去等。

　　诚然，整理上的工作优先级不算高，经常需要给更重要的事情让路，在项目组人员很长时间都不会发生变化时意义相对也不大(因为大家都足够熟悉现在的工作模式)。但一旦出现项目变动人员交接搭档变化的情况，忽视整理带来的缺陷就会更容易暴露，也会给新的项目成员造成困扰，我还记得很久之前一次临时交接工作中讲解一些设计规范注意事项时的不耐烦心情，而对方的估计也一样头疼。(想起程序员最讨厌的事是自己要写注释和别人的代码没注释这个梗，其实设计师也有类似情况的233)

　　文件夹的归类与命名

　　我在前一家公司实习的时候，大家的设计稿一般存放在Server上，并且有些比较约定速成的归类与命名方式(目前记得的有按版本分成V1\V2\Archieve\Latest…，或者按时间分成201X-XX，一组高保真设计稿按交互流程前缀上0123…)，当时的老板会在组会上当场Review大家的设计文件存放方式是否规范(比如.psd和.png要放在不同的文件夹，不能混在一起)，否则挨罚。不过我有一点一直做得不太佳，就是会慢慢把文件目录搞得过细过深而疏于重新整理归类(懒……)，结果反而影响了查找东西的效率。

　　这样的好处是别人(上级、项目组伙伴、其他设计师)看你的设计成果时能一目了然，迅速找到想要的东西，而不是迷失在混乱的版本管理与各种类型的文件海洋中，也相对不容易出现拿旧的设计稿开发完才发现不对的情况;你也可以更方便地浏览别人的设计稿、寻求思路借鉴。作为用户体验设计师，在公司内部和他人合作时，也要注意怎么带给别人更好的体验。


　　常用组件的整理沉淀

　　大公司的大型成熟产品线通常都有一份完整的设计规范，沉淀了各种常用的组件与使用原则，这样的规范可以帮助新人设计师迅速熟悉和接手工作，将更多精力聚焦到对业务和用户的理解与思考中去，而非纠结已经很成熟的组件设计上的细节。

　　但如果是做从0到1、偏偏还比较复杂不是一两个内嵌页面了事的产品设计，有必要时就需要自己动手丰衣足食了。起初做这样的产品时，我对组件与规范的沉淀不以为意，也磕磕绊绊完成了第一期的上线，后来不断增加新页面新模块的设计时，都是凭借自己的记忆从旧设计稿中找到可以复用的组件，但随着时间推移记忆负荷与查找成本也有所上升。后来趁一个比较空闲的工作周里做了一下网站组件的统一梳理沉淀，并参考其他部门一些成熟的设计规范，写了相应的使用场景与原则，进一步加深了自己对组件在交互设计中如何运用的理解，也希望让自己之后设计工作里查询复用、甚至项目变动需要交接给他人时变得更加方便。


　　交付物的规范化与实用性

　　刚来现公司实习不久时，写过一篇设计文档相关的文章：如何写好一份设计文档。随着时间推移，我发现自己的设计交付物虽然整体框架上还好，但细节上是有各种问题的，所以也在不断地迭代优化。后来偶然接手了一个之前由天猫设计师负责的小项目，进而又通过内网发现天猫的设计师们有一套相对成熟的交互交付物规范，包括任务流程、用户路径、信息架构等，都有比较完整的模板，比自己摸索出来的交付物要成熟不少，注释细节之类的信息很完整清晰。

　　但在实际工作中我发现，交付的规范、严谨、说明全面的交互文档可能并不一定能起到很好的效果。比如前端未必有耐心去阅读你那大段的文字，一个简单的交互动效，用Axure直接模拟出一个可以交互的高保真效果演示给他人，比口干舌燥地描述上一大段效果要好得多;又比如常见的「左侧标记数字，右侧空白写说明」的布局模式，在PC端的产品设计稿中(APP端应该还好)右侧经常会被人忽视(意识不到页面还能横向滚动一下)，也提高了反复沟通确认的成本，所以我更倾向直接在设计稿上控件的旁边直接标注，虽然会对美观性产生一定影响。


　　《交互设计沉思录》一书中就批评了UX经理把时间花在华而不实的文档管理工作上的现象，指出文档的时间维度体验表现力偏弱，而可用原型会是一个更好的替代方案。在规范化交付物提升专业度的同时，也要注意观察搜集他人实际的反馈效果，并进行调整改进，不要忽视了实用性。