用户体验杂谈（1）

最近三年一直服务于一个商业产品——腾讯云的用户体验工作。前2年是专门负责UI开发团队，最近1年半负责平台、建站、计费、运营、渠道的用户体验设计团队。这几年中有一些想法和观点，抛出来，欢迎一起探讨。

先通俗的说什么是商业产品，定义我很难下，但是有几个特点： 1.用户是客户。感谢#juicywang的补充：“补充一点，用户是客户及客户服务的用户或客户管理的用户。设计产品要尽可能考虑复用，功能全。” 2.提供的基础产品和服务是收费的 3.帮助某个行业的用户解决实际生产环节中的问题 4.这些问题一般是提升效率和节省成本为主 5.绝大多数存在大客户

团队的角色包括：交互设计师、视觉设计师、UI开发工程师。除了UI开发的较为独立的团队计划之外，设计团队的计划尤为需要花更多的时间和精力去制定。摸索了小半年之后，确定了三个发展阶段：

1. 设计实践
2. 设计学习
3. 设计创新

三个阶段基本上都有半年到一年的平行时期，每个阶段基本上都是1～1.5年，每个同学在各个阶段停留的时间也有所不同。

设计实践阶段的主要目标是快速全面的提升基础能力，比如：

1. 当前能力所及最佳设计实践的应用；
2. 规范制定当中的相互探讨；
3. 面对各种情况（运营、多角色、紧急、长时间加班、人员变动等等）的应对措施；
4. 执行力的提升；
5. 优先补齐短板；
6. 建立基础的数据佐证体系；
7. 尽量脱离竞争对手的影响；
8. 提升在产品侧的影响力；
9. 产出自有的经验和方法；
10. 找到属于自己的设计风格；

设计学习阶段的主要目标是基于之前的实践产出的经验，学习和包容更多的方案、方式和方法，留下适合自己的，舍去暂时不适用的，比如：

1. 有计划的尝试融入新的知识
2. 对第一阶段的产出物进行合理的体验提升

而最后一个设计创新的阶段则的目标就是：

1. 创造力
2. 自成一派的风格
3. 产出行业的最佳实践

发展计划之外，要建立一个团队的长期财富——KM，也就是知识管理。对于toB的设计师（指代交互和视觉设计师，下同）挑战最大的其实并非专业本省，而是对于产品所服务的行业以及产品本身的理解。就腾讯云来讲，宏观一些的问题要知道什么是云？云解决什么问题？公有云、私有云、混合云是什么？各种云产品都是做什么的？三种交付模型Iaas，Paas，Saas都是什么？数据中心是什么？虚拟化技术是什么？安全的挑战是什么？ISO七层模型是什么？什么是pay as you go？……具体到业务中，问题会更加细致，比如，各种规格和实例；如何划分子网？V**的原理。A记录、CNAME、MX、SRV解析类型的不同。……总之是太多太多了。对我自己也是很大挑战。

一方面是自我的学习，另一方面就是邀请产品经理专门过来培训，虽然可以补起很多行业和产品知识，但是这个速度和消化、掌握的速度其实还远远不够。2周一次培训一个产品知识，我测算了一下，如果没有新增，大概要2年。当然，每一位设计师都会负责自己对应的一个业务线，对于这个业务线的知识就会了解的很深入，往往是交互设计师掌握的要比视觉设计师多。因为他们要把负责的业务流程变成用户可以便捷使用的，所以每一个细节自然要了解清楚，这样产生了一个toB团队的一个大问题——视觉设计师的发挥空间和发展以及成就感，这个问题以后会谈，这里就先不说了。

toB的产品在发展阶段一定是增加各种功能，保证快速跟上对手、占领市场份额，加之产品线分散于各个FT，所以体验一致性和效率就是一个必须的保障。曾经在2年的时间里，我们一致在做整个腾讯云的一致性，因为用户根本不关注你们内部到底多少个team在做这个事情，我们必须要让用户感知到一致的体验，所以KM中就必须有各个环节的设计规范。

用户访谈也是难度较大，到达客户的生产环节中去观察比较奢侈，云也并非是一个频繁操作的产品，而且客观说还真没什么时间能去观察，毕竟最快的时间补起能力才是关键。每一次的用户访谈和竞品分析在KM中也占比很多。

对于体验的优化和提升以及设计的决策更多的是来源于数据体系，清晰的标记各个按钮和链接以及其他操作控件，统计点击量。通过内部和外部的系统查看数据，了解访问量，来源，点击率，跳出率，注册率，购买转化等一些列数据。所以数据的报告和分析也一定包含在KM之中。

为了同样的问题不产生第二次，所以一些建议一定要记录，特别是老板的建议，基本上都是我们曾经忽略和没有看到的。

综上，团队的KM文章分类会大致包含：

• 新人指引
• 行业与对手
• 通用工具
• 官网
• 管理中心
• 运营
• 移动端
• 基础代码规范
• SEO
• 用户与数据
• 老板的建议
• 通用设计规范
• 未分类

阶段目标，知识管理是基础，一致性保障则是最后的环节。

总结一下最开始爆发期的一致性保障措施，这个阶段最大的特点是交互和视觉都在疲于应对各种产品的需求，而UI开发作为用户体验环节的最后一环，在时间上有抽身的机会，加之一直灌输不要重复彼此的思想，所以这个环节利用代码向前约束的成效是最快的。当确认一个规范之后，不同设计师产出的有差异的方案，在UI开发环节即刻便被屏蔽掉。

绝大多数的一致性失败的主要原因有5点：

1. 大局观弱：每个产品（模块）只结合自己的特性进行方案的设计、问题的解决；而不去主动的了解其他产品（模块），设计通用的方案，解决一类相思问题，有“必须自己产出”的情节
2. 执行力差：不详细阅读规范、不仔细理解规范、不研究规范的本质、不认真按照规范进行实施
3. 无强制力：没有强势的检验者和约束者
4. 表面规范：规范仅仅作为展示，不介绍使用场景、不介绍注意事项、不介绍设计原理、不介绍如何变化、不提供清晰的使用方法、不进行顶起的访谈、不及时同步更新
5. 与产品本身或版本的耦合度高：过分追求精简、组件与布局混合、控件与内容混合，以产品功能命名。

UI开发在技术环节如何去保障就不细说了，主要要关注的点是：项目间解耦、组件库、新旧版平稳切换、恰当的工具。

详细说说流程上的措施：

1. 强制收口，前面讲了，只认规范，不认偏差，代码要统一，升级一起升
2. 主动承担，不要寄予前面的环节和后面的环节发现或者解决问题。无论是不是自己的项目，必须推动相关人员进行修改，建立审核机制（至少双人审核），明确权责。
3. 每周收集有差异的设计稿，分析潜在的公共组件，然后邮件所有成员。发布交互稿与UI Demo的对应关系。
4. 多重校验，特别是第三方，前期先告知哪些已经有标准化组件，中期审核结果，后期组织参与。校验代码生产工具的使用规范。不定期review工程文件。
5. 代码说明必须到位
6. 交换项目，不定期交换优先级较低的项目，将心比心，如果丹心自己接手的项目代码“很恶心”，那么就先做到不要去“恶心”别人。

UI开发作为一致性的主导和主要校验适用于产品极速上升期以及团队尚未成熟阶段。所以所有人对于一致性的重要度有深刻的认识以及经验丰富之后，就自然而然的将压力分散掉了。