这两年随着各个大厂开始进军B端市场，关于B端产品设计的讨论在不断变多。恰好近三年接触B端产品设计也比较多，总结了一些小小的经验和心得。
开始之前首先明确一下概念。To B产品，或称企业服务类产品，区别于服务个人的消费类产品，目标是为企业或组织直接节省成本/提高盈利，或通过提高某个商业环节的效率来间接节省成本/提高盈利。
我们日常在工作中难免会遇到请假报销等审批场景，常常就是在公司采购或自研的B端产品中解决的。还有面向不同职能的产品如财务系统/销售管理系统/人力资源系统等，也都是属于B端产品的范畴。
对于B端的客户体验来说，线上的产品体验只是一部分，更重要的是线上线下相结合的全流程服务体验。篇幅有限，本篇将重点关注SaaS产品的线上体验设计中用户角色分类的部分。
在我们谈论B端产品用户的时候，主要谈论的是职场人。当我们把一个一个的自然人放到职场中，他们就不会像做C端产品时一样以性别/年龄/喜好等特质来分群，而是以角色/权利/义务来分群。需求分析也不再基于自然人性，而更多是基于角色需要。
简单举例来说，一个做招聘的HR，无论是男是女，是喜欢二次元喜欢自由搏击，坐在工位上，打开候选人的简历，此刻就只是一个单纯的做招聘的HR，在一个「筛选候选人」的场景里，需求是能快速找到匹配当前岗位的新员工。
那么一个企业中有那么多的职能和职位，如果他们都是一个B端产品的服务对象，涉及到的所有角色可能都会来提出站在自己的角度所关心的问题，这些问题复杂又数量庞大，设计师该如何取舍和分配优先级呢？
一个较为复杂的B端产品可能会涉及到这四类线上用户：Decision Maker 决策者，Primary User 主要使用者， Secondary User 次要使用者，Tertiary User 间接使用者。
决策者，顾名思义，就是那些下决策买它的人，或者说是给钱给资源的人；他们有可能是公司IT部的负责人，也可能就是CEO。
他们常常不是产品的主要使用者，使用频率非常低甚至完全不用，但又非常关心产品的最终效果和核心价值，例如流程线上化之后最终的数据统计分析和内部管控的加强等等。
他们对于某个功能的评价有时，甚至是常常，与主要使用者的感受相悖，原因也正是因为他们并不是那么关注使用过程，而可能更关心产品的核心作用/最终效果，品牌和价格。
满足决策者的需要是做好B端产品的前提；很多大家感觉不好用或者不注重体验的B端产品，仍然可能活得很好，就是因为做好了这一点。
理想的情形下，团队基于对目标客户群的深入研究，对他们的需求作出理性判断和取舍，形成趋于标准化的产品，并通过可配置的功能模块灵活适配不同场景，就能打动目标客户群的大部分决策者。
而现实中很多B端的产品经理和设计师常常会抱怨产品太过于销售驱动，有时为了满足决策者的要求，做一些并不容易被其他客户复用的一次性需求，耗费了很多设计和研发的资源，并且让产品变得越来越累赘和复杂。这个问题在文章最后会聊到。
主要使用者就非常接近于C端“用户”的概念，他们是真正频繁使用产品的人。
没有他们的数据录入和功能使用，决策者想要的数据统计分析或流程管控都是水中楼台，所以他们对于产品的评价也通常会直接影响决策者的选择。如果要在体验上下功夫，提升NPS(净推荐值)，瞄准他们。
主要使用者通常是最容易识别的。
比如一个销售管理系统，如果没有销售日常在系统中录入客户信息，那么管理层就无法直接通过数据统计功能看成单进度和转化统计，协同部门也没法通过销售录入的数据管理财务&合同等相关内容；那么普通销售就是整个系统的主要使用者。
作为设计师如果能确保销售录入数据的流畅体验，将会为这个销售管理系统的后续功能拓展打下坚实的基础。
次要使用者相对于主要使用者而言，使用频次相对更低一些，用到的功能也比较少，往往只在某一个流程中间涉及少量操作。对于他们而言，能简单快速找到自己的任务并顺利完成就可以了。
如果一开始在次要使用者的花费了过多精力，满足了很多衍生需求，投入产出比很可能是比较低的。
间接使用者是指不直接使用产品但会被产品影响或是影响产品的第三方；例如监管机构，审计等等。设计师在设计过程中如果有资源和精力，可以兼顾他们的需求。
一个简单的B端产品不一定都会有这四类用户；而越是复杂的产品越可能有更多的利益相关者，就越难抓到设计重点。
当在需求的海洋里窒息的时候，清晰的用户分类可以让设计师始终保持清醒，将有限的精力和资源用到最重要的两类用户身上：决策者和主要使用者。
在识别这四种用户的基础上，用户B端产品的另一个特点值得设计师们注意：
多元的用户需求在产品中常常并不是独立存在的，而是相互影响的；且同类用户中往往也会有更细微的分层。
举个栗子：
在设计审核后台时，不只一个审核员在用户访谈中提出审核过程中常常会遇到无法立即给出判断的情况，需要停下手中的审核进度，向经验更丰富的审核员请教并讨论处理结果；但这种时候常感到时间紧迫，时效性压力很大。
他们希望审核时能添加一个【跳过】的按钮，这样可以不耽误手里这一批可以直接判断的审核内容。
审核员的需求听上去非常清晰合理。
但此时我们还需要综合考虑，目前因为无法跳过审核内容，审核员在压力下会争取在最短的时间内去寻求帮助并找到合适的审核策略。
而如果以“提升审核员的审核效率和体验”的目的顺应审核员的需求添加这个【跳过】按钮，被跳过的复杂审核内容的时效性如何得到保障呢？
是否需要专门安排一个经验丰富的审核员同时来处理这些被跳过的审核内容？
如果新手审核员可以轻易跳过自己无法判断的内容，这又是否利于他们自己的成长？
「高难度审核内容」是否能有明确的定义来约束审核员，让点击【跳过】按钮这件事情有据可循而不会变得过分随意？
在添加这个按钮之前，需要想清楚这一系列问题，确保它们能够得到妥善解决。
最后再聊聊前面提到的问题：如果产品过于“销售驱动”，以至于作为设计师无法合理分配资源和精力，专注在产品的核心用户和核心流程上，设计师该怎么做呢？
这个问题虽然不是本篇的重点内容，却实实在在困扰着很多做B端设计的小伙伴，就着自己的理解希望能给出一些启发。
一. 多层传达的需求收集过程
对于B端产品，尤其对外售卖的SaaS产品来说，需求常常是由客户的决策代表转述给项目经理&销售，而非业务人员直接提给产品设计团队，这是第一层信息流失；
然后团队内部通过业务经理/销售经理转述给产品设计团队，这可能造成第二层信息流失。
同时因为产品经理和设计师在过程中只能被动接受信息，失去了深入挖掘和与客户探讨的机会，很难充分理解需求场景，也无法基于自己的理解提出比客户所要求的更好的解决方案，从而失去了主动权。
要解决这个问题，产品设计团队需要更加主动地参与需求收集的环节：
一是尽量制造机会参与需求讨论；多与项目经理和销售一起身临现场与客户沟通；
二是积极与销售和项目经理等直接接触客户的同事打交道；长期直接接触客户的人员对于产品的核心卖点以及竞品的优劣往往有敏锐的洞察，对于产品设计人员理解客户的角度有很大的帮助。
最理想的情况是尝试将用户调研流程化：
在需求讨论的前期，组成专人小组，到客户现场实地调查，通过分角色的访谈，详细采集需求场景和用户需求；在产品设计过程中，可以同时参考用研团队的结论和销售同事的输入；在产品交付前，也可进行分角色的可用性测试等来帮助产品及时调整；交付后收集客户反馈以便之后进一步完善产品。
如果资源不足，可以将所有环节的调研都尽量倾斜在主要用户上。
这样做的好处是产品设计团队能扭转因为信息流失和沟通不畅导致的被动局面，建立对客户更加深入全面的了解，做出满意度更高&更容易成功交付的产品；在长远上也有利于产品设计团队对目标客户场景的深入理解和标准化产品的沉淀。
并且流程化的用户调研环节可以给客户传达一种专业的感受，让客户感到受重视，可以成为客户服务体验流程中的加分项。（不要担心会打扰客户，他们其实也挺需要存在感的：）
二. 标准产品 vs. 非标产品
还有一个需要考虑的是标准化产品与非标产品的区别。
打造一个标准化产品需要长远而精准的定位和分析；这些分析往往不是在做加法，而是在做减法。只有通过对需求进行强有力的把控，将标准化产品定位在相对明确的方向上，对衍生需求进行适当割舍，并不断对核心流程进行打磨，才不至于做着做着变成了什么都有但都不好用的庞然大物。
但如果发现产品面对的场景本身是一个非标准化的场景，每个客户都有截然不同的要求和处理方式，甚至无法找到一个足够大的有共同需求的客户群体，并且短时间内也无法通过教育市场把场景转变为标准化的场景，此时根据每个客户定制化的项目制产品往往比标准化产品更加贴合实际用户需要。
项目制产品往往讲求短平快，在尽量短的时间内抓住客户的核心需求进行设计和开发，并成功交付；此时设计师需要更设身处地站在客户的角度，以快速交付项目为主要目标。
在实际工作场景中，有时也会以标准化产品与定制化需求打包售卖的方式，此时设计师需要及时调整定位，以开放的心态看待定制化需求，而不用以标准化产品的要求来批判客户的选择。
结语
由于B端与C端产品在商业本质上的不同，产品设计的目标和套路也会有相应的变化。对于C端产品而言，视觉层的重要程度相对更高，而界面是否优美流畅非常直观，设计师的价值更容易得到体现；对于视觉层优先级不那么高的B端产品而言，设计师的价值体现就更隐性一些。从C端转B端的设计师小伙伴们常常会感到很大的反差，甚至很多小伙伴吐槽B端产品不注重设计，很少有机会可以做一些新颖时尚的界面和交互，工作没有成就感。
B端产品相对于C端产品来说，业务场景，功能逻辑，用户构成等各方面大多都会更复杂一些，在业务理解/产品认知/交互能力/逻辑思维层面上都很具有挑战性，可以很好地锻炼设计师的综合能力。
第一步，就让我们先从正确划分用户类型出发，摆正设计重心，调整心态，来迎接更多的挑战吧 ～
原文地址：雪球设计中心XDC（公众号）
作者：雪球设计中心
评论0