笔者作为用户体验设计中心的成员，在接到了“带动业务持续运转和商业价值的稳步提升”的任务后，与团队一起承接了绝大部分以往大家所认为的产品或运营职能，对核心产品的平台侧和业务侧做一次运营和体验优化升级。
入正题，设计有两种价值输出方式：一种是售卖设计本身（外包公司、设计全案公司、咨询公司）、另一种是用设计思维售卖万物（稿定设计、爱彼迎、苹果），这是两种截然不同的思维方式和价值形态，一个极度垂直，一个高度整合，同时也会将设计从业者带向不同的职业发展之路，这篇实例文章将会围绕它们之间的差异来展开。
一、案例
还是延续之前的叙事穿插方式：
最近公司核心业务事业线的产品和开发团队变动非常大，资源变得异常短缺，我的老板（leader）突然找我，说：
用户体验中心在特殊时期必须进能带动业务持续运转和商业价值的稳步提升，退能找准自己的专业定位，持续输出专业价值和协助业务目标达成……
如此云云，口吻没毛病吧，很官方很老板对不对？？
但我隐约觉察到用户体验中心充当“填坑办”的任务要来了，那种感受就像捉奸一样又兴奋又忐忑。
庆幸的是我的团队大部分设计师并不太排斥这种协作方式，毕竟互联网行业属于价值驱动型而非职能驱动型。忐忑的是切实能感受到前面的暗坑和不确定性很多。
这个世界有一部分人总能光鲜上场，长枪短炮、马肥粮足的条件出征，另外有一部分人注定就是在缺兵少粮、困阻重重中负重前行（哈哈，我希望我的老板永远看不到这片文章）。
果不其然，接下来在很长一段时间内，设计需要承接绝大部分以往大家所认为的产品或运营职能，对核心产品的平台侧和业务侧做一次运营和体验优化升级，该事业线没有业务产品经理（目前国内大部分to b公司产品经理都是以技术产品经理为主，业务产品经理更多是销售担当了）、也没有用户运营岗，用户体验中心这个冠以建立与用户沟通通道为天职的团队，似乎理应承担点什么。
事实也是如此，接下来团队必须从需求承接方转变为需求方，从专业支撑岗位转变为项目驱动岗位。
也就是说，用户体验中心需要深入业务，在产品和技术的支持和协助下，结合市场和竞品研究分析，自己梳理业务流程并确定预期目标，进而发现问题和优化提升点，形成系统产品需求执行方案，然后拉项目组立项并驱动交互、UI、开发、测试上线，最后验证目标和效果达成。
当然，以往类似这种项目流程在头部平台的to c项目中比较常见，但在业务的行业壁垒森严和业务逻辑异常复杂的to b项目中的确非常罕见，因为一个设计类的专业岗位确实很难对to b业务认知和理解上做到全穿透，不是能力不行，而是信息的不对称和权限的不对称。
即便可以做到，但因为职业偏见，业务部门也不敢委以重任，毕竟平庸胜于风险。
以往我们团队确实有过独立发起并驱动项目的经历，但都只限于现有产品业务逻辑基本不变，也不会有新的功能逻辑产生的情形下单纯对交互、视觉和品牌体验的提升，其结果的衡量标准也是以定性评判为主，行为数据变化衡量为辅，毕竟互联网产品体验设计很难摆脱业务，形成自己独立的商业价值评价体系。
因为这篇文章不是定位为设计方法论，加上项目太细很容易被猜到东家是谁，会有打广告之嫌，所以整个项目背景这里就不做细节赘述和配图，简单描述就是：
一个以往以销售驱动产品研发来满足客户需求，且销售为主动，产品研发为被动的传统SASS业务模式将要面临一次重大的商业模式升级，变成销售和产品相互协同的双驱动模式，但在现有业务体系下要达到以上目标，具体需要完成以下事项：
01 在官网平台侧
重新升级产品品牌调性，由原来的“数据改变世界”升级为以“满足客户价值为发展重心”，并开始官网和产品业务侧的用户的精细化运营，做好用户分层和引导分流，最后促进意向客户的主动咨询和留资，这一点会偏to c产品用户策略。
将以往售卖的散点产品功能包装成行业客户的解决方案，提升客户的场景代入感，促进官网平台的客户转化，提升销售ARPU值。
进一步精细化真实客户案例营销，用大客户真实案例，以更真实和数据化的案例分享形式来讲述使用产品和服务前后效果差异，借客户的口吻更可信。
02 在业务平台侧
还原客户的行业背景＋业务需求场景，通过客户体验地图和使用行为路径结构树的行为数据，洞察客户可能的潜在增值服务需求点，通过一定规则内嵌增值服务运营引导，将公司的亮点付费功能适时营销出去。达到真正意义上的SASS产品的场景化运营，这里也比较类似to c产品的用户场景化运营。
当然最后才是用具体的设计手法，将免费用户和付费vip用户的身份和服务的差异化营造出来，并用更加简洁轻松的设计风格和和友好的运营话术来完成业务平台侧展示层的体验设计升级。
看到这里，你肯定觉察到了两个点：
这并不高级呀，这不就是教科书式产品运营进化迭代方向吗？
这不是产品或运营应该做的吗？跟用户体验中心有啥关系？
但这才是今天我要说的重点，用户体验设计从命名那天起就应该摆脱先天设计职能边界限制了，纯UI、UX设计是一种专业能力的表现方式，他们是一种专业价值方式的介入，而用户体验是一种客户价值预期管理，是承载了客户价值和商业价值闭环的，我们的职责是把设计思维和方法带到产品体验全流程甚至商业全链路的决策中去，如果只做设计表达，就是开篇时说的第一种单一价值输出模式。
我们把剧情拉回到实际案例中，这里再补充一个现实困境的小插曲：
因为该业务发展历史非常久远了，且目前产品承载的业务逻辑和技术逻辑异常复杂，也存在一定的架构逻辑问题。再加上来来去去的产品和研发人员的流动，最终导致的结果就是，目前分管的各产品支线没有一个人能彻底弄明白内在逻辑全貌，那就更谈不上对于上面升级改造点的具体方案设计了。
对这样一口飞来之锅，用户体验中心该如何承接？没有做过成熟to b业务规划的设计师可能永远无法想象面对一个系统黑盒的无助，说实话，设计师开始确实是拒绝和慌乱的。
接下来我会围绕以下七个要点来分享我们具体是怎么做的，里面肯定有很多模糊的职责边界，欢迎网友批评指正：
二、我们是如何做的？01:
体验设计这个职业的能力要求是没有边界限制的，所以作为设计师，不用惧怕打破原有协作方式和职责范畴，这样你的能力以后才有迁移价值。
什么叫迁移价值这里就不赘述了，可以百度。
举个栗子，装饰设计师或空间设计师这个职业，他们的工作方式并不是按照客户的需求被动接单，然后用牛逼的专业设计能力做好人居环境规划方案直接交付。
而是在前期充分沟通的前提下，整合客户预算、风格喜好、材料成本、公司利润等综合条件限制，他的日常工作会深深的嵌入到前期销售、中期工程施工，后期交付甚至售后服务全流程，而且在整流程中会恰如其分的嵌入增值服务的场景营销，达到客户价值最大化和公司利润最大化的平衡，这不是设计，这是在经营。
回到这个项目一开始，负责该项目的设计leader很无奈的和我说：
我觉得以往的协作方式很好也很顺畅和清晰，产品告诉我们需要做什么，我们就用心把他实现，职责很清晰，现在让我们跨界协调所有环节，主导这个项目，真的会有很多不确定性的坑，这些坑不是我们能解决的……
但在我看来，这也许并没有那么难，因为该项目核心价值部分并不是我们专业上的盲区，它不像纯技术和数据解决方案，需要有专业背景，我们不需要对技术实现方式全盘了解，只需要了解大概原理就行，我们可能需要把大量的时间放在和产品、技术的频繁讨论并确认现有逻辑上，还有用户访谈还原使用场景上。
但这个过程中我们获得了完整业务形态上的规划能力，我们获得与用户以及协作团队的沟通能力，我们获得如何连接并驱动其它团队小伙伴一起合作的能力，我们获得了挫败后的坚持、获得沟通中的相互尊重、获得了用户体验边际价值的自信，这些能力是可以平行迁移复用的。
02:
要做好to b产品的精细化体验设计，对产品了解的颗粒度必须达到业务逻辑乃至技术逻辑的全覆盖。
因为这是设计中心第一次完整的规划一个带有预期业务目标的系统性项目，所以如何向产品和研发下需求（寻求帮助），这显然是一个逆天的操作，过程确实是抓狂的。
第一，我的老板把锅给了我们，注定主要压力在我们，其他人没有义务主动上心，不是说大家没有责任心，这是职场本能反应，因为大家都很忙。
第二，面对复杂的产品黑盒，设计师以前是实现需求，不需要技术和资源支持，现在凭一己之力起初确实无从下手。
我们只有一个办法，开通所有不同付费权限，以客户的业务视角花大量的时间系统性走查全业务流程，统计并标记所有的潜在的可能的付费转化触点，把问题及时记录，集中沟通和请教，就是通过自己花时间系统性梳理了业务逻辑之后，带着具体的问题去请教，而不是给大家提开放式的需求，这样才不会让人反感，也会让支持解答的人没有那么大的负担，这是一个沟通协作技巧，也是一个向别人学习请教的技巧。
03:
要做好to b产品的用户体验设计，难度不在于设计细节处理和大家经常所说的to b产品to c化的方法论平移。
国内to b产品用户体验设计因为传统销售模式差异，之前确实没被重视起来，前两年也有过to b产品to c化的说法，但这个项目下来给到我的感受是，其实主要难度不在于to c的方法论平移，而是在于沟通和驱动整个业务链条的体验价值认同和资源支持配合，从客户侧到市场商务，从前端销售侧到产品运营，从设计落地到开发交付。
还是拉回项目案例吧，我们有一块内容的规划设计其实是想结合客户使用产品服务前后数据效果对比的真实案例描述，来提升产品品牌口碑和线上营销的可信度，从原来的“我们能给你提供什么？”转换成“他们用了以后，给他们带来了什么样明显提升？”。
毫无疑问，这项工作用户体验中心是怎么都盘不动的，客户详情案例是需要客户配合提供和授权的，没有过硬的客户关系和信任度很难获取内容并授权，大家应该已经意识到，看似是一个案例升级，但事实上已经上升到了业务的品牌战略高度了，可以理解为把客户价值放在了企业战略的重要位置。
怎么办呢？不然就开展不下去了，没办法了，说服leader并写份ppt吧，让leader去说服CEO，从上层引起重视并安排下来，这件事情才能顺利完成，我们的确是这么做的。
04:
设计不是在资源充足的完美条件下做完美的设计，而是在限制条件下寻求尽量完美的设计解决方案
其实我们大多数设计师每天都在各种限制条件下做设计，同意的请举手。因为条件真的完美了，设计就没有那么大价值了。
回到案例，项目前期阶段，设计师一边走查一发现有诸多先天的历史遗留逻辑问题，于是问道：“这么多坑，感觉根本执行不下去，能做吗？？”，我说“先不要过分担忧，先动起来，动起来就能发现问题和寻求到解决方案”。
其实解决办法就是先接受和包容这些坑吧，尽量用优秀的设计解决方案降低历史问题对客户体验的影响，但同时也不是放着坑不管，过程中和产品以及业务相关人员商量后续如何彻底解决，就是项目继续推进，设计过程还有个职能就是暴露问题，问题暴露出来，所有的解决方案才能在项目推进中产生。
还有个例子，对于包装客户业务场景的产品解决方案，目前产品团队要马上给出来确实很难，这是一个需要业务线和战略层共同参与并讨论才能决定的内容，怎么办呢？？等着他们提供内容了再继续项目？不用
等，先按预设客户体验要求规划好内容结构示例，并形成设计解决方案，带着解决方案让老板们做选择题或填空永远比让老板自主命题完成整篇论文要靠谱。
05:
少即是多，学会接受用最简单的设计处理来解决业务需求中的复杂问题，不是设计改变越大价值就越大。
少即是多这个理论在交互设计原则上有经常用，但在这个项目中体现的尤其突出。
设计师在项目初期问我，这个需求会不会吃力不讨好，费老劲做了那么多基础工作，可能最后老板发现并没有太大的改变，也没做啥新的显性设计。
我本来不想把这个点引进到文中，但这确实是一个经常会犯的原始的认知错误，和看程序员写了多少行代码来评判他的绩效如出一辙，其实to b产品的设计价值评价标准真的不一定是以数量来取胜，比如你要是能用最少的一套设计标准解决所有具有共性的中台业务线的前端展示层，那就真的是无上功德了，就像ant－design，但这里更想表达的是设计背后支撑和依据是需要大量的前期基础研究和分析，设计输出只是最后的呈现状态，和无印良品的极简工业设计底层逻辑是一样的。
06:
虎头龙尾，第一个小迭代设计方案尽量完美，先让老板看到一个好的开始，你给老板希望，老板可能会帮你提高结果预期。
这不算什么大的设计策略，就是切身体会到的一个细小妙招，你给了领导/老板一个好的开始，即便不是完美的结果，也会坚定他们的项目信心和结果预期、会给予更多的时间和资源的支持，给你扫平阻力，你会推进的更轻松，那么期结果必然会大于预期。
因为领导开始委任给你这个项目的时候可能是一个相对选择项，只有你给他足够的信心之后，才会坚定他的绝对选择项，真正好的团队，不是一个独立造车，而是能把领导裹挟进你的项目中，为项目成功在上层力量上加持，因为颠覆性的项目过程中不可能一帆风顺。
07:
别忘了，每一个大项目的迭代都要做好结果预管理和价值评价标准，以方便最后做成果检验和复盘迭代。
结果预期和评价标准是未来项目迭代调整的唯一依据，不然做项目就是拍脑袋，这在一个正经的to c项目中是最基本的标配了，但在to b产品中，因为数据样本可参考性和历史发展的差异大家都避而不谈，但数据有相对价值和绝对价值之分，to b产品的用户行为数据虽然对营销没有那么大的决策性价值，但对用户潜在行为倾向性也有相对参照价值的。
很幸运，该项目的设计负责人对项目数据埋点和上线后的数据结果统计意识非常强，也愿意直面自己的工作成果的真实用户数据反馈，此次升级是希望能将一个潜在的付费用户从进入官网平台，到注册免费用户，再到咨询商务，再到销售跟进到CRM系统，最后到正式使用服务并适时引导升级额外增值服务付费转化的完整用户漏斗。
所以，你想让to b产品体验设计在价值之路上一路打怪升级，那么，你就要敢于承担真实的业务数据结果，敢于面对待质疑批判，学会对结果负责，是你做好用户体验价值设计所迈出的第一步。
最后还是草草总结截稿，世上本无柏林墙，都是自我设的防！！设计师不是只会撸图，在特定的情况下，你的潜能可能会远远超过你自己的预期。
请不要低估自己，跟我一起，用实际的项目案例持续触碰传统体验设计的价值边界…….
