前言
SaaS 产品体验要求越来越高，用户体验已经成为产品竞争力的重要组成部分，怎样在多业务线的产品环境中做好体验设计，本文从贴合业务线的设计规范、敏捷易用的前端组件库、产品研发协作流程保障、UI体验文化打造、UI设计质量品控5个方面阐述项目快速、规模化提升多产品线整体体验过程中方法论和实践经验。
关键词：
用户体验设计；UI设计规范；多产品线；体验文化；UI设计落地
面对多产品体系，多产品线，需要积极寻找和探索适合我们客观情况的最佳实践，我们面临的问题有：
1.过往以功能堆砌为主、基本“能用”，缺乏平台规范和一致性，体验不足。
2.产品线多、体量大。
3.客户对产品体验要求越来越高。
4.产品历史包袱、修复改动困难。
5.对用户体验认知不一，协同、沟通成本高。
6.重复的开发成本。
7.第三方组件与业务的匹配度不佳。
解决以上几大难题，我们启动了UI 设计规范的搭建、UI组件库的开发等，让规范和组件库成为各产品线坚实底座的一部分，使用户体验文化赋能前端和产品经理，协同 QA 力量一起推动产品体验升级，以下整理分享的实践方法适用于中小型UED团队支撑复杂、多业务线的企业，本文尝试从以下几个方面总结和提炼实践经验，跟业界同行探讨。
贴合业务线的UI设计规范
设计规范体系的搭建对于新的团队，如何从复杂海量的业务场景中制定出一套适用于自己产品的UI设计规范，是第一道待翻越的高墙，完整的设计规范应该是包含视觉规范与交互规范，本文主要针对设计规范实践过程进行阐述。
贴合场景的设计规范：
虽然市面上已经有众多成熟的设计规范体系可供使用，但是当前我们所处的产品阶段、多业务 线以及复杂的业务场景等综合因素，决定了需要重新搭建一套符合我们自己业务场景的设计规 范体系。
UI规范效益最大化：
一旦我们决定制作规范，就要把规范当成一个产品去做。去梳理一套高效合理、可复用的制作流 程，去分析产出什么样的「规范产品」才能产生最大的价值。 依据规范效益模型，在规范的制定中尽可能的提高规范的通用性至90%，先解决统一性，再解决场景细分，打造高质量通用的模式库以提高质量和效率，并力求让更多人从这套设计体系中获益， 从而让规范体系发挥更大的价值。
UI规范制定的策略：
明确用户对设计规范的诉求，构建适合产品的UI设计规范，首先，需要明确规范体系的用户群体经过设计团队多轮调研，确定设计规范面向的目标用户群、基于核心用户的诉求，为后续规范内容框架的制定提供依据。
确定UI设计价值观：
产品历史包袱重，系统结构复杂，在提升用户体验时，内容表达「清晰明确」是第一要务，例如尊重已经形成的用户习惯，优化改造时，注意版本之间的衔接，让用户「清晰明确」，这也是为什么将「清晰明确」作为价值观之首，另外提升效率是企业级产品用户体验的永恒主题，同时兼顾系统的简洁与一致。
梳理UI规范框架：
UI设计规范包括设计价值观、全局规则、组件库、模式库、典型页面、移动端规范和设计资源框架整理主要从以下3个方面进行：
1.梳理现有组件，剔除不使用的部分 。
2.同类竞品的框架借鉴，查漏补缺。
3.场景验证，与业务场景深度结合经过充分论证和梳理，对规范框架做了重新定义，增补了业务缺少的内容。
如上图所示，例如对高频的工具栏组件的补充，典型页面的补充，增加模式库以及全局规则，当前第一个版本的规范框架是基于业务场景优先级最高的内容进行制定，更多的规范内容的增加依托于不断的迭代，逐渐完善规范框架。
规范内容的制定及评审：
组件规范包含：变更记录、组件定义、何时使用、组件的类型、组件的响应。
规范内容制定的原则：
1.有明确场景可依。
2.精简不必要的分支 例如在定义表单规范时，对于表单标签的对齐方式做了统一的约束，标签右对齐，输入框左对齐全局保持统一。
逻辑正确、规则明确易懂：
例如常见的alert （警告提示）名称调整为常驻提示，语义更贴合场景，便于理解。
规则的可拓展性，多场景的兼容性：
产品架构是PC端到移动端的自动适配，因此在组件设计的时候需同时考虑PC端与移动端的对应关系以及两端场景的兼容性。
协作及敏捷迭代：
规范发布后，伴随着实际项目的检验，业务场景的扩充变化，如何高效的对设计规范进行迭代，决定了设计系统能否持续的走得更远，规范内容定期评审，必须通过业务、技术、设计评审，确保规范是可用的、可落地并且易于使用的规范后期不同的规范模块专属人负责，同时有backup，可以帮助走查复盘双重保障规范的质量。
敏捷易用的前端组件库：
复杂的业务场景和多产品线特点，快速打造一套敏捷易用、高质量并符合实际业务场景的前端组件库，是提高产品研发效率、改善UI质量、提升用户体验的关键。
敏捷易用的前端组件库
复杂的业务场景和多产品线特点，快速打造一套敏捷易用、高质量并符合实际业务场景的前端组件库，是提高产品研发效率、改善UI质量、提升用户体验的关键。
前端组件库建立目标：
1.提高开发效率，对高频使用、通用组件进行代码化封装，避免重复开发工作。
2.提高开发质量，通过各类业务场景和业务线的锤炼，沉淀组件代码最佳实践。
3.提高产品体验，组件封装代码化，减少在多角色协同中因为理解偏差、信息传递问题等导致的不确定性和结果不可控性，不同业务线、不行项目、共用一套基础代码，保证体验的一致性，组件的组织形式： 结合实际业务场景和原子设计理论，将组件划分为不同颗粒度：基础组件、业务组件、典型页面 组件，以适用于不同研发场景使用。
1.基础组件，基础组件为组件库最小颗粒度，构成系统界面的基本构件。
2.业务组件，在基础组件的基础上，结合具有共性业务特征的业务场景，梳理出具有业务特征的 业务组件。 3.典型页面组件，梳理具有业务特点的典型页面，相比基础组件和业务组件，典型页面更加具体， 为用户提供具有代表性的内容和框架，并准确描述用户最终看到的内容。如列表和左树右表典型 页面组件，作为最为常见的页面结构，各业务场景可复用页面组件，保证了页面组件内各基础组 件的一致性，最大程度的实现不同产品线产品中页面体验的一致性。
推进前端组件库落地执行：
前期设计规范落地到组件库过程中，面临诸多问题和阻碍，比如开发落地质量不高、内容遗漏、 各方理解不一致、验收及修复问题不到位等问题。处理这些问题对UI团队资源造成很大消耗， 通过总结复盘前期组件库落地时的经验和教训，梳理落地执行流程，在新的协作流程下，新一 批的组件开发不论在协作效率和开发质量上都有质的提升。
分层推进：
组件库开发是一个持续迭代的过程，考虑到组件库开发资源极为有限且无专职负责人员，在跟组 件库开发团队协同过程中，我们通过分步开发来解决组件库更新优化的问题并通过不断优化协作流程来助力组件库高效落地。
前端组件库分步开发原则：
1.优先级原则，优先开发适用于业务线普适场景的组件。
2.紧急性原则，对于急需的业务线所需组件优先开发。
3.快速可实现原则，开发实现成本高的组件暂缓处理。
自查走查验收：
组件UI责任人梳理出下属组件需开发落地的细节点，整理为文档，待开发人员完成组件开发后，自行参照UI提供的自查文档，查漏补缺，保障进入UI验收环节的前端组件不会出现较多的缺陷，降低后期走查和沟通修改的工作量，同时监督开发人员提高组件落地还原度和质量。
组件库的持续迭代：
UI团队通过一套标准的流程来把控组件库迭代的质量，在日常工作中经常会收到产品经理或项目 方提出新的组件需求或对现有组件的优化。UI部门作为推动组件库搭建的核心环节，需要以全局 和更深入的视角加以判断把关，保证前端组件库内容的普适性和高质量，避免组件库内容冗余， 降低研发维护成本。
产品研发协作流程保障：
好的过程是好的结果的有力保障，一个业务需求从产生到开发落地需要经过多角色协同、一系 列环节。必须依靠规范的研发协作流程，确保各角色清楚自己职责以及如何跟上下游衔接，同 时我们也希望协作流程能够确保设计资源可以向重点业务模块倾斜，以及发挥各个角色可以发 挥的作用去共同提升产品体验。
UI角色需融入规范化的研发流程
UED团队建立之初，我们面临的首要问题是：需求随机，完全取决于各产品线和产品经理 个人，为了解决这个问题，我们制定了UI融入研发体系的流程以解决合理、有效利用UI资 源的问题。
企业级产品特点、多业务线、大量面向管理员用户的具有相似页面结构和交互模式的业务 模块、产品经理跟交互团队人员配比等因素都决定了并非所有需求都需要流转到UI团队进 行设计，在判断哪些需求需要流转至UI团队设计时，我们给出了如下指导性方向：
1.用户量角度，大量终端用户使用的场景，例如订票、报销、采购页面 。
2.用户重要程度角度，核心、重要用户使用的场景 eg.公司领导、决策层。
3.通用性角度，通用组件或框架，需要UI通盘考虑各个业务线场景需求进行设计。 其他需求则主要由产品经理进行设计，UX以评审方式轻度参与。
协作流程迭代，UI验收成为必要一环： 随后我们又面临新的问题：设计还原度差，被公司老板生动的形容为：看设计稿是“精装修”， 开发落地后就成了“毛坯房”了。为尽可能确保设计还原质量，我们在研发流程中明确了所有涉 及前端页面的功能需求都需要在研发协同工具中流转到UI负责人验收，在产品团队TAPD中记 录UI缺陷、标明严重程度，对于 “严重” 级别以上UI缺陷，禁止发版。
UI工期评估合理化：
为了既能尽力配合各产品线迭代计划又要争取合理UI设计时间、保证产出质量，合理评估设计周期对UI人力管理尤其重要。对此，我们对设计需求分成了ABC三级进行评估。 对于A和B级需求，通常模块较大，先有UI设计方案再去分期迭代开发，对于这两类需求，在评估 模型中给出了大致工期概念，比如以月为单位，大于1个月或2个月。
对于C级需求，通常为产品经理先排进某个迭代再来提UI设计需求，设计范围相对明确，我们则结合典型页面数量因子和设计难度因子给出了UI工期大概评估公式，以天为单位。
1.设计难度因子：根据业务线的复杂程度而定，范围为（0.8~1.5）。
2.典型页面数量因子：评估需求范围规模（N）。
设计体验文化打造
UI设计团队在协作过程中面临诸多挑战：产品线多、产品逻辑复杂、研发链路长、各级人员对产品认知及重视程度不一、好的体验设计难落地、沟通成本高等问题，想要解决这些问题，若仅靠UI团队自身力量是不够的，需要动员公司各个环节和人员重视用户体验，共同促进产 品体验提升。
搭建体验文化灌溉机制：
UI部门通过多维度的体验知识内容矩阵、多渠道多场景全员覆盖，普及和加深各级对产品体验 价值的认识，提升产品体验思考力和洞察力，帮助企业以新的视角思考业务、产品研发和用户 体验的关系，赋能产品经理及研发人员高质量的输出，“以用户为中心”和“打造产品极致体验” 的价值观根植与企业文化中，指导研发流程中各项工作最终影响到产品的战略层、范围层、结 构层、框架层和表现层这5个产品体验维度，以实现企业产品的“极致产品体验”目标。 通过搭建体验文化灌溉机制，提升全员体验意识，能为产品研发带来长久的价值：
1.提高设计还原度
2.减少培训成本
3.提升跨部门沟通效率
4.提升UI团队影响力
5.提升客户满意度
体验文化落地实践：
针对不同类型的体验知识，我们采取不同的传播渠道进行透，以期达到最好的效果，避免形式化， 将体验文化渗透、学习落到实处，最终影响产品研发的各个环节。
以下为UI团队在企业体验文化 推广的主要渠道和方法：
极致体验公众号主要发布产品体验的基础原理，体验价值、项目复盘、常见体验问题等深度长文。让公司各级人 员认识用户体验及价值，让用户体验理念深入人心。
体验知识小卡片整理产品体验小的知识点，阅读学习成本低。利用员工碎片时间，对细小体验知识点的学习，积 跬步，至千里。
直播宣讲针对重点且复杂的产品体验内容，如交互规范宣讲、重点问题复盘、产品经理及开发人员应知应 会的知识点，采用宣讲直播的方式，更好的对内容进行详细解说和疑难问题沟通。
体验调研分享UI部门成员对核心竞品进行体验调研，整理分析后对产品经理及相关人员进行分享，赋能产品经 理，为产品的体验设计提供新的思路。
UI设计质量品控
UI团队专业水平一定程度上决定了公司产品体验的上限，持续提升UI自身专业输出能力可以从源头提升公司产品体验。
设计自查：
企业级产品的大量体验问题都是设计基础问题。因此需要设计师不论在内审前，还是内审过程中都要牢记设计原则，查漏补缺，守住底线。我们在部门内部制定了一套适合企业产品的UI自查表来检查设计方案，通过这些自查点来避免产品中出现基础体验问题，从UI设计师自己这里 把好第一道关。
在日常工作中，UI自查表始终占据工区的醒目位置。在评审过程中，大家也会通过线上文档的形 式来对设计原则的条目进行逐一检查。
做好UI内部评审：
设计团队内评审（Design critique）是几乎所有国内外设计团队的普遍、经典做法，可以有效提 高设计产出水平、保证团队对外输出质量。方法是普适的，但具体执行时如何做才能有更好的效果却各有各异。 在如何做好内部评审上，我们进行了如下尝试。 从“全员参与” 到 “组成内部评审委员会” 团队内评审时邀请全员参加，但发现只有少数同事发言，另外一些同事因资历浅、不了解评审产品或者积极性不高给不出建议。同时随着团队成员数量从几个增加到十几个，评审会议的时间成 本大大增加。
选取团队内相对资深和积极提出问题、建议的同事组成内部评审委员会，以月为周期轮流进行， 可以有效分散评审委员在团队内部评审上的工作负荷，并明确一次UI内部评审除了内部评审委员 会还有哪些关联同事需要参加。 关于邀请评审内容关联同事，比如“消息中心” UI评审跟另外一位同事负责的“讨论消息”有关联，则需要邀请这位同事一起评审，以便发现关联问题，整体考虑设计方案。
以上参与评审机制明确在团队内部协作工具上，做到人人清楚。另外，对于评审建议，要做到有 记录、有回应、有跟踪，确保有效发挥了内部评审的价值。
UI设计师的能力模型：不言而喻，UI设计师自身能力的培养是UI品控的重要一环。因此对于设计师能力培养通道上，我 们引入了以下模型。
我们将UI设计师能力归纳成了3x3能力矩阵。这可以设计师在工作中也可以有目的提升自身薄弱环节，同时也让企业对UI设计师的要求更加清晰，除此之外，我们要求UI设计师也需要多了解业务和前端知识，往前多走一步，跟上下游角色更好的衔接，一方面，UI设计师需要理解业务，要能够有半个产品经理的业务知识储备， 如果能站在更高的行业视角对自己所服务的业务领域（向 业务产品经理再迈进一点）有一定的理解是更好的了，另外一方面，UI设计师跟自己的下游-前端 开发工程师也需要很好的衔接上，知道相关前端技术概念、基本页面布局和交互实现逻辑、方法，能够无缝地将界面和交互设计翻译成前端可理解的语言。
