关于设计规范,你了解多少？.pdfVIP

关于设计规范 ，你了解多少 ？ 有幸在刚入部门就参与设计规范制定 ，前前后后大概花费 个月时间。本次博文结合亲身参 与的制定规范项目 ，围绕 ：设计规范的重要性 ，制定规范的时机 ，制定的过程和后续工作这 几个方面来总结和分享。 设计规范的重要性 设计总监刚开始召集设计师讨论立项制作设计规范时 ，就有设计师提出“规范只是公司给外部看的 种噱头” ，更像是体现 种公司视觉形象 （V I ）。其实互联网公司的产品设计规范并非是仅仅用来宣 传形象的 ，更多用来使用、简化开发过程、使多个产品拥有 致的体验 ，是落到实处的东西。 在 个部门含有多个产品线的情况下 ，此时产品设计规范最能体现其作用 统 产品用户体验 由于负责各个产品线的产品经理并非同 人 ，如果此时设计师们又是渗透到各个产品组中 ，那么产 品之间的体验就根本让用户感觉不出是 个部门设计开发出来的。 不同产品线的产品经理交予设计师的线框图就千差万别。比如实现 个筛选功能 ，有的采用下拉 菜单 ，有的采用弹窗。相同的情景不同的交互方式 ，先抛开各自的优劣不谈 ，产品之间本身就出现 体验上的矛盾。产品经理间缺少沟通 ，而产品团队基本会按照产品经理的规划设计产品 ，这就造成 产品间存在体验差别。 不同产品线上的设计师设计风格也存在差别。比如外观尺寸设计 ，配色选择。当没有独立的设计 组时 ，产品线上的设计师均各自为政 ，并直接对产品经理负责 ，更加深化了产品间的不协调。 产品设计者没有错 ，只是缺少了让各个产品线之间协调统 的桥梁。通过设计师间的讨论并协商各 产品线上的产品经理 ，制定 套规范 ，架起这座桥梁 ，让产品设计者们有参考、有准则。 方便设计开发产品 在制定设计规范的过程中 ，会形成统 标准控件库、页面元素尺寸规定、配色方案规定和视觉风格 统 指导。设计者可以按照功能需求直接调用规范中的标准控件 ，按照信息结构需求调用不同的元 素尺寸进行设计。很轻易便能输出高保真原型图 ，减轻了设计过程中对交互控件选择和信息排版的 思考负担。 形成备案和文库 如同技术文档 样 ，产品在设计方面也需要文档与规范。由于业务需求的变化 ，设计规范不会 成 不变。通过文档备案记录每次设计调整 ，调整的初衷和理论依据 ，便于日后的回顾与总结。自己在 刚入部门时既没有产品设计规范文档 ，又没有规范的技术框架文档 ，在产品成长与传承中出现了 中断。形成简单易读的文档规范是 种对产品负责任的体现。 制定规范的时机 规范出现时机应恰到好处 ，过早或过晚 ，均会为产品迭代带来麻烦和阻碍。 在产品刚刚起步或仅迭代几代版本后便想总结出 套规范为时尚早。此时产品仅仅拥有大体发展方 向和基本功能 ，很多细分工功能不够完善 ，产品整体不够丰满。此时制定出的规范并不能起到概括 和统 作用 ，随着产品不断完善 ，大量功能需求会添加进来 ，而规范也要随之大更改 ，增加各个部 门修改调整负担。如此大规模修改规范本身就失去了规范作为 个准则的意义。 在产品已经成熟之后再制定规范则为时较晚。此时每个产品线上的产品功能、结构信息组织框架已 经定型 ，只有偶尔优化提升体验细节修改和辅助类功能的添加。产品技术框架逻辑 ，尤其是前端技 术框架已成型 ，且技术人员在开发过程中对于产品界面设计 ，交互方式也谙熟于心。如果迭代过程 中产品间差别不大还好 ，产品差别很大时 ，再出台规范会增加很多技术人员调整的成本 ，拖延新版 本上线时间。 如果部门同时存在成熟与刚起步的产品 ，按照成熟产品设计方向制定规范会更方便后续调整。即使 规范出台时间较晚 ，也要比部门内部没有统 规范使产品间不统 、不 致好得多。 制定设计规范过程 设计规范虽然只是简单几页 ，但那是浓缩概括的结果 ，并非 蹴而就。 早期注意积累和归纳 设计师在设计初期产品效果图时要注意实时归纳和总结 ，原文件和导出文件进行分类整理 ，对设计 过程中使用的控件和模式及时归纳 ，同时简单记录 些界面设计的初衷 ，有争议的设计点等等。及 时地总结对后期设计规范的制定打下良好基础 ，否则很容易忘记设计初衷 ，找不到文件或者设计负 责人等等问题。 总结归纳会议 准备制作设计规范时 ，需要召集各产品线上的设计师将设计结果进行汇总和提炼。这样的会议既是 讨论性会议又是决策性会议 ，所以耗时较长 ，但这又是要制定设计规范的必要会议。 可以预先将规范划分成各个模块 ，分步进行会议讨论和决议 ，并将不同模块对应到不同设计师来负 责总结。当遇到难以解决、产品间互相冲突的问题要即时沟通相关产品负责人 ，当涉及到 些产品 需要重大样式修改时更要即时沟通 ，设计组内部意见