避坑指南

成功的路径各不相同，踩过坑大抵一样。这里记录的不是系统化的学习方法和工作流程，更多的是自己在一线项目中真实遇到的各类问题总结而来的经验教训。希望能在大家通向未来的道路上彼此帮扶，让我们可以走的更远更长久。

✍️ with tears & love.

不同于C端产品，我们经常可以比较自然的把自己当做用户切换为用户视角，B端产品的用户会有一些特定的认知和专业门槛，我们很难在短时间内深入了解用户完成身份切换。切忌用自己的相对局限的角色认知去凭空捏造B端客户的需求。并且也不要想当然的认为客户会清楚自己当下的需求，我们需要深入客户的真实场景才能层层剥离出真正的需求和背后的业务价值。

● 效率为优而不是唯一

B端产品的用户一般会更在意功能是否完整、链路是否通畅、效率是否够高。这一定是我们需要第一优先级考虑的事情，但我们要清楚这不代表B端用户不在意体验的提升，这只是优先级问题而不是可有可无的问题。对产品设计而言，我们必须同样秉持体验最优的信念，只是在过程中要学会判断设计对业务的ROI（投资回报率）。

● 尽早考虑定制化

B端产品因为其面对的每一个客户都有所不同，基本不存在工作场景和工作流程都一样的企业。千万不要自信到以为可以一招鲜吃遍天。牢记磨刀不误砍柴工，我们要尽早在设计上定义出灵活的交互框架，从设计到技术都要做到低耦合高复用。在做定制化交付的同时将自己的成本和效率做到最优。

业务冲刺阶段通常是艰辛和痛苦的，也是检验一个团队综合能力的最佳场景。自己曾经历过近半年多的业务冲刺期，其间遇到了各种大大小小的问题，踩过了无数深坑。希望能给正在冲刺或是可能遇到相似问题的你照亮一点前路，避开深坑走远一点，走的舒适一点。

● 警惕补位意识

补位是在组织、业务遇到人员短缺或资源配置不合理（业务冲击阶段经常会遇到的两大问题）的时候一种有效的处理手段。其根本目的是化解危机、快速解决问题。团队需要鼓励大家培养补位意识，但切忌过渡宣扬。补位的本质是处理不合理，补位如果成为常态意味着组织中一定存在更严重的人员和流程问题。长期的补位状态会让团队处于工作内容不确定和工作边界不清晰带来的焦虑感中。我们要透过补位去揪出本质问题，避免补位成为常态。

● 直面不可抗力

在业务冲刺中，我们一定不可避免的会遇到各类不可抗力（例如甲方决策层突然更换）的影响。对于信息的优先知情者，一定要做好信息的透传，过渡沟通远好于隔离沟通。面对不可抗力我们需要更直接更理性的告知每一个人，藏着掖着只会带来更严重的信息偏差导致团队气势受损。请真诚的面对团队的每个人，共同解决不可抗力带来的影响。一次成功的面对和担当会转化为更强的团队凝聚力，是形成良性循环的绝佳起点。

● 原因比目的更重要

一定不要小看做事原因对团队的影响力，特别是在业务冲刺阶段，原因往往比目的更能影响团队的工作效率和工作质量。要做到师出有名才能真正激发一个人一个团队的战斗力。只有赋予事情强有力的意义和价值，让信念感推动大家才能真正把事情做好。业务冲刺首先要有冲击的方向，但能确保团队持续冲刺的动力一定来自师出有名。

● 领导者的局限性

领导者通常依据大量的项目经验和信息获取优势来进行业务评估和决策。但在业务冲刺阶段，我们一定要认识到个人时间的局限性，当你在纵览全局和获取信息上花费大量时间的同时，一定是无法兼顾对一个具体事务的深度思考的，此时我们应该给予专注负责该事务的伙伴以足够的信任，对专业和专注授权远好过用不一定适配的过往经验做判断，领导者需要守住底限，而不是成为上限。

从曾经的定制安卓系统到Web端的UIKit盛行，再到如今的各类 Design System 遍地开花，有幸经历了设计系统这一路从文档到框架到未来工具化的演变过程。踩坑无数，虽没有什么拿得出手的优秀系统案例，但希望下述的几条避坑建议能给大家在后续接触和参与设计系统的过程中起到些许正向的引导作用。

● 学会站在巨人的肩膀

要学会根据业务规模和业务节奏来决定设计系统的引入和使用方法，一套设计系统的建立和维护是需要花费大量时间和人力成本的。在设计系统如此繁荣的今天，我们要学会合理的使用这些开源且成熟的设计系统（Ant Design、Arco Design等）。根据业务场景和载体的不同，选择合适的设计系统站在巨人的肩膀上进行二次应用和业务定制，可能是产品引入设计系统更为优先选择的一种处理方式。

● 时刻牢记业务目标

保证体验一致性是实现业务目标的手段，设计系统是保证体验一致性的工具。业务在多数时刻一定存在其定制性，不要为了统一而统一，要时刻清楚工具和手段都是服务于业务目标的。

● 别自嗨用起来

随着行业的发展，设计系统的呈现形式逐渐从过去的文档变为现在的框架，未来正向着工具化的方向发展。作为和设计系统关联最为密切的设计师，我们要做的是让设计系统真正的用起来，真正的深入到工作场景中，落地到前端甚至产品团队的使用场景中。设计系统不是设计师用来自嗨和展示其设计一致性的文档，是要切实的在各个团队中流转使用起来，真正帮助产品提高迭代效率、保证体验一致性的跨团队型工具。

● 系统是有阶段属性的

设计系统的建立不是一蹴而就的，更不是一层不变的。不要妄想在产品设计之初就建立起一个完善的设计系统，你无法穷举产品的功能更无法预测业务的发展。设计系统是一个一直在进化和迭代的事物，没有完美的系统，更没有存在终点的系统，设计系统是有时间和阶段属性的。我们应该踏实的面对每个阶段的业务需求，完善和进化符合每个阶段的设计系统。