现在大多数情况都需要团队协作，比如仅UI一个环节也有对外的衔接和对内的协作，而非一个人单打独斗。其实，不少从业者还是不大习惯根据自身情况去制定相应的规范体系，或乐享其成，甚至排斥抗拒，今儿简单聊聊这话题，仅供参考吧。
简单的说人少靠沟通，人多还是得辅以标准、规范更佳，比如：
13年前自己开始做个人网站的时候，11年前自己做“蓝柯工作室”接活儿勤工俭学的时候，反正就是自己一个人心里有谱就成，没觉得需要整理什么规范。
03~05年，在一家电力行业软件公司做研发部界面设计负责人，也就连我自己一起算和UI设计有关的就2、3个人，项目相对单一，人员之前常交流学习但也没多大业务交集，没觉得需要整理什么规范。
05~06年，在一家从事电子政务的软件公司做电子政务事业部界面设计主管，团队成员5~8人，项目大致有政府各级门户网站、业务系统、触摸屏、平面宣传等。没有相应的约定和规范随意性很大界面一致性相对较差增加项目风险甚至危及省级电子政务重要事件，发现加班是可以产生工作量，但无法有效提升效率，故在常见业务分类中逐步约定部分共识，在Web UI设计整理相应需求规范、设计实现规范等，明显效率有所提升，特别是避免了低级错误和一些较为大量的重复工作。当时已具有软件界面模式、组件等重用思路的萌芽。
07~08年，在一家从事能源、电子商务方面ERP的软件公司做技术研究院界面设计开发主管，团队成员5~6人，项目大致有能源行业ERP产品及客制开发业务系统、网站、平面宣传等。在去这家公司之前的现状是，大量开发人员在分模块开发时界面实现的随意，导致一套ERP系统上千个页面，却有三种主要展现，各页面细节也不统一，维护成本很大，客户不满项目迟迟不能回款，项目风险很大。当时的情况，不允许招聘几十个UI设计制作人员去设计页面去写网页代码，仍然还是得开发人员去实现表现层，但也不能指望开发人员每人都很懂都心有灵犀。当时是更多的结合了技术层面的东西，做了一些既有主流设计理论也有实践技术支撑的规范：1、制定软件界面规范。确立以用户为中心的界面设计思想，制定公司级界面规范《界面设计指南》，构建界面规范体系，建立界面规则库、测点库、构件库，指导公司界面设计开发过程。2、浏览器端界面框架、组件开发。从各项目搜集界面组件，常见界面组件的选型及抽象开发，将界面设计思想、展现方式、技术手段进行重用，推出浏览器端界面套件BUISuite，并不断完善更新，公司主要产品、项目应用中屡获好评，提高开发效率，降低界面维护成本。3、其他项目/产品工作。是验证我们所制定规范和界面开发框架的一个重要途径，在此类工作中我们在保质保量完成任务的基础上同时侧重界面模式、构件的积累和业务实践水平的提高，取得良好的收效。
08~13年，在一家从事融合通信、移动互联网的软件公司做产品开发部界面设计主管，团队成员5~7人，项目类型相对丰富，从前期的Web网站和Web Phone、多方通话、多媒体会议、IM PC客户端，到近三年的IP Phone + MMS移动设备iPhone、Android、Windows Phone、TV Box等客户端。前期Web为主要支持的时期，吸取这家公司现状问题及前面的经验教训，通过充分的调研和分析，制定Web UI规范体系，结合各种技术要求，优化编写“基础界面元素规范baseUI系列”、”通用界面框架规范UIframework系列”HTML+CSS代码，为RD及相关人员进行框架体系培训，该框架仍沿用至今。近年来，开展移动互联网平台业务支持时，支持的平台之多、技术更新之快，平台官网所提供之指南和相关内容之有限，让我们倍感压力，需变通思维，尽快学习实践，一方面吃透官方指南；一方面了解业界相应研究和实践成果；一方面多试用相应产品，汇总相应的经验和知识为我们公司项目支持之用。安排了很多的知识分享、总结、以及有计划有针对性的安排了一些UI预研，及小课题。甚至，在一些各平台，我们的UI人员也通过了解RD的一些开发知识，在UI实现层面也做了一些尝试，可以更好的了解界面机制更有效的和RD沟通。
可以说，现在这个时间点，做界面团队，如果不重视“标准、规范”相关工作，不重视相应的研究和实践总结，不重视相应的知识分享，基本上不能顺应目前移动互联网时代的现状。
时下多人团队很多情况标准、规范，不能够被一般沟通交流所取代的，大致说几点：
- 标准、规范在相应约定范围内严谨制定，避免在一些基础问题上的随意性、不确定性，影响项目全局。
- 标准、规范有利于团队内及对外的协作，有利于辅助公司形成一套自身的标准及技术规范。
- 标准、规范对新人的培养有重要指导意义，团队成员共同参与相应规范的制定、实施也有利于自身成长。
- 标准、规范不应因主要制定者休假、离职等原因，就无法执行推进，故标准、规范制定时应立足业界实际长远考虑，避免“个人英雄主义”因素。
就扯到这儿吧，凌晨一点多了，明儿还得上班。