如何构建一个能够“容纳”不同角色的用户体系？

我们之前谈过基于用户洞察力设计产品的业务结构。其目的是实现业务解耦，构建“轻”2B业务系统，实现可扩展架构，使整个系统能够跟上业务快速发展的步伐，而无需重构新业务的增长。我们还花了几个空间介绍了“产品结构”的概念、思路和设计方法，并回顾了2B产品的多租户结构设计案例。如果你稍微小心一点，你会发现还缺少一个关键环节。是的，这个链接是“用户对象”的问题，也就是如何构建一个能够“容纳”不同角色的用户系统，并在整个业务系统中平行处理业务，如何实现跨流程合作。事实上，这个问题对系统的影响还包括如何构建角色和权限模型，这将在未来继续。作为整个系列的第12篇文章，本文仍以“O2O平台”为例。01基于工作流梳理用户对象2B的产品，简单来说就是解决很多用户(发布在很多业务部门，涉及各种交叉并行业务流程)如何高效协同工作的问题。无论是我们常见的OA系统，还是各种复杂的ERP、前几年流行的O2O平台CRM系统。对于任何面向企业的产品来说，都是一个挑起各种用户角色，另一个挑起合作效率的重要任务。对于普通用户来说，该系统的价值在于节省时间和工作量，通过使用该系统来提高自己（个人或部门）的“性能”和能力。对于企业管理和决策者来说，该系统的最大价值在于如何有效地提高整个企业的业务能力。换句话说，2B产品本身就是实现企业经营合作的工具。其难点在于：如何更有效地容纳N中的角色和N多个并行业务的处理能力，并通过本产品实现企业业务流程的优化创新？2B产品的设计实践，即思考如何根据企业客户的业务场景，实现个人vs组织的“矛盾”需求。无论各种新颖的理论是什么，我们做的第一件事就是围绕用户展开。通过现场业务模拟、调查、分析和演绎，结合具体的业务流程和工作流程，我们可以将每个“群体”——系统的服务实体对象进行拆分。1.业务恢复正在构建O2O平台的整个过程中。我们大致梳理的业务流程包括三个流程：用户启动服务请求、后台处理服务请求和前端完成服务请求。简要描述如下图所示：闭环业务示意图服务请求：用户（无论是2B客户还是2C终端用户）可以通过多种方式启动客户服务请求，在此过程中，座位的主要任务是如何及时响应用户请求，完整记录用户问题，快速解决用户问题。在此过程中，可拆分的产品价值包括用户端的体验和座位端的效率。也就是说，在这个过程中，需要拆分和解决的问题包括：如何建立一个完整的用户请求渠道（全覆盖渠道可以改善用户的整体体验）？如何快速解决座位上的用户问题（任何服务平台都希望提高服务过程中解决用户问题的比例，这需要一个足够有效的知识库）？如何帮助座位快速、完整地记录用户请求的内容，以及如何在服务请求过大时分配合理的座位资源？这些问题不仅涉及到产品的结构设计，也是产品交互和视觉设计的重要参考。必须充分考虑交互的便利性，甚至结合实际工作场景、方法和流程，在视觉上减少用户的疲劳。事实上，这也是技术选择的一个重要指标因素。因此，一般来说，产品需求文档必须有明确的技术指标，包括响应时间、并发数等。ps：在对产品信息架构、产品架构和业务架构的分析中，“产品抽象能力”是指从上到下的业务分析能力，而不是从下到上看每一个细节。对于产品经理来说，面对任何业务需求，首先要从大方面思考，然后深入到细节流程。一旦反过来，整个产品只有功能，没有业务。服务调度：调度是指对某类用户/客户发起服务请求的响应和处理。也就是说，基于“效率第一”的原则，如何分配最合适的工程师来解决用户的问题是最经济、最高效的？在这个过程中，涉及到许多场景的优先事项，如：有些问题只是一般咨询，有些问题是严重的质量问题，有些问题可能会导致群体和舆论问题。这不仅需要建立完整的处理机制和流程，还需要赋予一线“接线员”相应的权限和能力，第一时间识别风险，快速调动相关资源，及时处理用户问题。在产品和技术的处理细节中，还需要考虑资源的瓶颈。系统必须能够人工干预调度资源，建立“众包”渠道，为“平台”开辟更多的社会资源。同时，也在一定程度上激发了工程师的积极性，提高了服务的处理效率。服务绩效：这一环节也是最终如何处理用户服务请求的过程。它也是评估服务质量的关键节点，包括服务响应时间、服务质量、用户评估等过程。在业务方面，服务和产品的二次销售也可能存在于某些场景中。综上所述，我们可以将整个复杂的业务流程抽象成三个“业务行动”，即支持整个系统正常运行的基本节点。想象一下房子的支柱，你就能理解这种思维设计系统的优势。换句话说，当我们在第一阶段设计产品架构时，我们不需要考虑太多的分支流程和细节逻辑，只需要建立一个支持平台来完全恢复整个业务流程。也就是说，我们可以想象，我们正在建造一个桌面，我们只需要考虑桌子四个角之间的结构合理性、稳定性和承载能力，以确保未来的业务扩张。在架构设计阶段，我们可以进一步抽象上述业务流程。整个业务模型可以表达如下：从整个模型来看，O2O平台业务模型不仅可以看到需要服务的用户对象，还可以看到整个过程中各种服务的实体和关键业务行动。围绕这些动作，可以在不同场景下完成业务订单。该平台是一个高度解耦的系统，可以兼容不同的业务和不同的文件格式和内容。对于整个系统，性能层的内容不会影响业务本身，整个平台只依赖于“业务行动”的有效运行。2.实体拆分从整个业务模型中梳理出一个业务全貌，可以清楚地识别出每个服务层所承载的服务能力，进一步将实体的“业务范围”根据各自的能力进行拆分。基于对整个业务场景的透彻理解，我们可以从实际业务的角度逐步分解整个用户角色的边界以及在过程中的承担和交互关系。在系统设计中，这种从逻辑层面的分解直接演变为实际的“业务实体”，即不同的业务应用对象，它们直接承载着整个平台的业务运营。(ps：在实际的产品设计中，整个平台的业务关系只需要根据业务场景进行完整的勾勒。为了便于描述，本文的示例进行了大量的简化。)从上图可以清楚地看到不同的实体，它们的业务边界非常清晰。在这种逻辑下，我们可以清楚地设计自己的工作流，并清楚地定义不同的用户角色权限。以“门店”为例：TA在这种角色关系中，实际上处于“上下承担”的关系。向上对接订单调度，负责总部调度机制和工单协调机制；向下对接其服务工程师，负责工程师调度和工单协调。按照这个想法，我们可以在设计“门店”这个角色和工单的流通业务中明确限制它在这个平台上的地位。换句话说，它的权限范围和需求范围可以定义。由于整个平台的管理规范，不会有任意变化。基于这一理念，我们可以有效地拆分复杂的应用程序，解耦整个系统的框架设计，并清楚地描述平台上每个用户角色的责任、权限和价值。整个平台以角色的工作流为出发点，而不是账户，可以实现灵活的关系，而不是强制性的管理关系。任何用户都可以在平台上自由完整地执行业务动作，只需要满足一定的角色身份。这也是整个平台账户系统设计的基本思路。系统越大，界定边界越重要，沥青责任越重要。02专注于动机设计用户标签“标签”的目的。除了简化系统设计外，另一个重要属性是建立灵活的网络管理规则，可以根据不同的业务需求直接配置不同的对象。标签系统可以根据角色的类别、属性、业务动作等进行分解，如下图所示：此图中有“类别”、“属性”、“可视范围”、“商业动作”这些名词。事实上，这四个术语并不是一个通用术语，而是一种在构建平台和制定整个平台的SOP中使用的项目语言。根据我的经验，使用这种约束性的项目语言可以帮助团队快速理解需求，并加快产品在标准范围内的应用。还引入了一个重要的属性：可视范围。简单地说，这是一个座位，或一个商店，工程师可以根据他们的实际情况分配他们可以完成的业务范围，如：商店有*的能力等。对于一个产品/系统来说，决定业务的是每一个独特的物理对象，即整个工作过程中的角色。只要与角色对象紧密相连，就可以清楚地定义整个平台的边界范围——直接标记业务实体。但是，我们很容易停留在表面，没有深入的业务，更不用说对用户动机的深刻洞察了。换句话说，在用户研究过程中，我们倾向于过于关注用户的行为，而不是在个人信息和人口学属性的集合中停留太多的动机——用户肖像，而不是深入到实际业务中。(我们最常犯的错误是过于停留在产品的功能上，而不是在商业场景中。）例如，研究发现，用户需要经常打印有计划地点和线路的订单。如果他们只是设计一个高效的打印和排版订单处理和研究界面，这显然不是一个更好的解决方案。对于产品来说，不能提供“用户态度和行为特征”的角色只是一个“鸡肋”。由于无法真正理解用户的痛点，无法真正解决用户的“绩效问题”，因此无法设计出真正满足用户期望的产品。“当用户使用某个产品时，他们是为了完成某个特定的工作(达到某个结果)”，这是一句产品名言。在设计产品时，真正值得高度关注的是用户的目标、产品的使用场景和用户与产品的关键交互阶段，而不是关注用户的任务是什么以及如何完成任务。因此，在设计用户角色模型时，应分为两个步骤：建立对角色的同理心，包括简历、年龄、收入等人口学属性。关注角色的动机，包括用户的态度和行为，使用产品的目的和动机，以及使用产品时的行为细节、偏见和心理感受。