近两年，随着各大厂商纷纷开始进军B端市场，关于B端产品设计的讨论不断增多。恰好这三年接触了更多的B端产品设计，总结了一些小经验和感悟。在开始之前，我们先理清概念。ToB产品，也就是企业服务产品，不同于服务于个人的消费产品。其目标是直接为企业或组织节约成本/提高利润，或者通过提高某个业务环节的效率来间接节约成本/提高利润。在日常工作中，我们难免会遇到请假、报销等审批场景，往往在公司采购或自研的B端产品中解决。还有针对不同功能的产品，比如财务系统/销售管理系统/人力资源系统等，也属于B端产品的范畴。对于B端的客户体验，线上的产品体验只是一部分，更重要的是线上线下相结合的全流程服务体验。限于篇幅，本文将重点介绍SaaS产品在线体验设计中用户角色的分类。当谈论B端用户时，我们在谈论什么？当我们谈论B端产品用户时，我们主要谈论专业人士。当我们将自然人一一放在职场中时，他们不会像做C端产品时那样按照性别/年龄/偏好进行分组，而是按照角色/权利/义务进行分组。需求分析不再基于自然的人性，更多的是基于角色需求。举个简单的例子，一个招聘HR，不管是男是女，喜欢二次元和自由搏击，坐在办公桌前，打开应聘者的简历。此刻的他，只是一个简单的招聘HR。在“筛选候选人”场景中，需求是快速找到与当前职位匹配的新员工。那么一个企业有那么多的职能和职位。如果他们都是一个B端产品的服务对象，那么所有涉及到的角色都可能会从自己的角度来提出关注的问题。这些问题错综复杂，数量众多。设计师应该如何选择和分配优先级？用户角色分类将资源集中在最重要的人身上。一个更复杂的B端产品可能涉及这四类在线用户：DecisionMaker决策者、PrimaryUsers主要使用Or、SecondaryUser次级用户、TertiaryUser间接用户。决策者，顾名思义，就是那些做出购买决定的人，或者说是付出金钱和资源的人；他们可能是公司IT部门的负责人，或者是CEO。他们往往不是产品的主要用户，很少或根本不用，但他们非常关心产品的最终效果和核心价值，比如最终数据的最终统计分析和加强流程上线后的内部控制。他们对某个功能的评价有时甚至经常与主要用户的感受背道而驰。究其原因，正是因为他们并不那么在意使用过程，而可能更在意产品、品牌和价格的核心功能/最终效果。满足决策者的需求是做好B端产品的前提；很多让人觉得不好用或者不注重体验的B端产品，可能也因此活得很好。理想情况下，团队会在对目标客户群体深入研究的基础上，针对他们的需求进行理性判断和权衡，形成趋于标准化的产品，通过可配置的功能模块灵活适应不同场景，打动目标客户最集团的决策者。现实中，很多B端产品经理和设计师经常抱怨产品太卖力了。有时，为了满足决策者的要求，需要进行大量的设计和开发，才能做出一些一次性的、不易被其他客户复用的需求。资源，并使产品越来越繁琐和复杂。这个问题将在文章末尾讨论。主要用户与C端“用户”的概念非常接近，是真正频繁使用产品的人群。没有他们的数据录入和功能使用，决策者想要的数据统计分析或过程控制就成了泡影，所以他们对产品的评价通常会直接影响到决策者的选择。如果您想在体验上努力工作并增加您的NPS（净推荐值），请瞄准他们。主要用户通常最容易识别。比如在销售管理系统中，如果没有销售每天在系统中录入客户信息，那么管理层就不能直接使用数据统计功能作为单项进度和转化统计，协调部门也不能使用销售输入的数据，用于管理财务和合同等相关内容；那么GeneralSales就是整个系统的主要用户。作为设计人员，如果能够保证销售数据录入的流畅体验，将会为本销售管理系统后续的功能扩展打下坚实的基础。与初级用户相比，次级用户使用频率较低，使用的功能较少，往往只涉及某个流程中的少量操作。对于他们来说，快速轻松地找到自己的任务并顺利完成就足够了。如果一开始把太多的精力花在了二级用户身上，满足了很多衍生需求，很可能投入产出比就比较低。间接用户是指不直接使用产品但受产品影响或影响产品的第三方；例如监管、审计等。如果设计师在设计过程中有资源和精力，可以考虑他们的需求。一个简单的B端产品，不一定有这四类用户；产品越复杂，就越有可能拥有更多的利益相关者，也就越难把握设计重点。当在需求的海洋中窒息时，清晰的用户分类可以让设计师保持清醒，将有限的精力和资源用在最重要的两类用户上：决策者和主要用户。交互性在识别这四类用户的基础上，用户B端产品的另一个特点值得设计师关注：多种用户需求在产品中往往不是独立存在的，而是相互影响的；在相似的用户中，也往往存在更微妙的分层。例如：在设计审核背景时，不止一位审核员在用户访谈中指出，他们在审核过程中经常遇到不能立即做出判断的情况，需要停下手头的审核进度，请教更有经验的审核员咨询。并讨论治疗结果；但此时往往时间紧迫，时效压力大。他们希望在审核的时候可以增加一个“跳过”的按钮，以免耽误了可以直接判断的那批审核内容。审计师的需求听上去非常明确合理。但这个时候，还是需要综合考虑。目前，由于审计内容无法跳过，审计人员会在压力下尽量寻求帮助，在最短的时间内找到合适的审计策略。而如果为了满足审计人员的需求，以“提升审计人员的审计效率和体验”为目的，增加“跳过”按钮，如何保证被跳过的复杂审计内容的时效性？是否需要安排专门的审核员同时处理这些跳过的审核内容？如果新手审计人员可以轻易跳过自己无法判断的内容，这对自己的成长是否有利？“难点审核内容”能否明确界定？约束审计人员，让点击“跳过”按钮有据可依，不会变得太随意？在添加这个按钮之前，你需要想清楚这一系列的问题，确保它们能够得到妥善解决。理解“销售驱动力”需要改变或适应。最后说一下上面提到的问题：如果产品过于“销售驱动”，以至于作为设计师，不可能合理分配资源和精力，专注于产品的核心用户和核心流程，设计师应该做什么？这个问题虽然不是本文的重点，但是确实困扰着很多做B端设计的小伙伴，希望结合自己的理解给予一些启发。1.多层沟通的需求收集过程。对于B端产品，尤其是对外销售的SaaS产品，需求往往是由客户的决策代表转发给项目经理&销售，而不是业务人员直接向产品设计团队提出。它是第一层信息损失；然后团队内部通过业务经理/销售经理将其传递给产品设计团队，这可能会导致第二层信息丢失。同时，由于产品经理和设计师在这个过程中只能被动接受信息，失去了深入挖掘和客户讨论的机会。很难完全了解需求场景，无法根据自己的理解提出比客户要求更好的解决方案。计划，从而失去主动权。为解决这一问题，产品设计团队需要在需求收集过程中更加积极主动：首先，尽量创造参与需求讨论的机会，与项目经理、销售人员现场沟通；第二，积极与销售、项目经理等直接接触客户的同事打交道；长期与客户直接接触的人，往往对产品的核心卖点和竞品的优劣有敏锐的洞察力，这对产品设计师了解客户的观点很有帮助。最理想的情况是尽量精简用户调研：在需求讨论前期，组建专门的团队，到客户现场进行实地调研，通过角色详细收集需求场景和用户需求基于访谈；在产品设计过程中，您可以同时参考用户研究团队的结论和销售同事的输入；在产品交付之前，还可以进行分角色的可用性测试，帮助产品及时调整；交付后，收集客户反馈以进一步改进产品。如果资源不够，可以把所有的研究尽可能的集中在主要用户身上。这样做的好处是，产品设计团队可以扭转信息丢失、沟通不畅造成的被动局面，建立对客户更深入、更全面的了解，做出更高满意度、更容易成功交付的产品；有利于产品设计团队对目标客户场景的深入理解和标准化产品的沉淀。而基于流程的用户调研环节，可以向客户传达一种专业的感觉，让客户感受到被重视，可以成为客户服务体验过程中的加分项。（不用担心打扰到客户，他们其实是需要存在感的：）2.标准品vs.非标品另外要考虑的是标准化品和非标品的区别。打造标准化产品，需要长期精准的定位和分析；这些分析往往不是加法，而是减法。只有强势把控需求，将标准化产品定位相对清晰，适当剥离衍生需求，不断打磨核心流程，才能避免成为我们所做的一切。但两者都不适用于庞然大物。但是，如果发现产品本身面对的场景是非标准化场景，每个客户的需求和处理方式完全不同，甚至找不到足够大的有共同需求的客户群体，那就是短时间内不可能通过。教育市场将场景化为标准化场景。这时，根据每个客户定制的项目化产品往往比标准化产品更适合用户的实际需求。项目式产品趋向于短、顺、快，在最短的时间内抓住客户设计开发的核心需求，并成功交付；这时候，设计师需要站在客户的角度，以快速交付项目为主要目标。在实际工作场景中，有时会将标准化产品和定制化需求打包销售。这时候设计师就需要及时调整自己的定位，以开放的心态看待定制化需求，而不是用标准化的产品需求来批判客户。选择。结语由于B端和C端产品的商业性质不同，产品设计的目标和套路也会相应发生变化。对于C端产品，视觉层的重要性相对更高，界面是否美观流畅非常直观，更容易体现设计师的价值；对于视觉层优先级不那么高的B端产品，设计师的价值体现更加隐性。从C端切换到B端的设计师往往会感受到很大的反差。很多朋友甚至抱怨B端产品不注重设计，很少有机会做出一些新奇时尚的界面和交互，工作上没有成就感。与C端产品相比，B端产品在业务场景、功能逻辑、用户构成等方面更加复杂，在业务理解/产品认知/交互能力/逻辑思维等方面极具挑战性。可以很好的锻炼设计师的综合能力。第一步，让我们从正确划分用户类型入手，定下设计的重心，调整心态，迎接更多的挑战~
