“专注于角色的业务，而不是每一个具体的功能。
谈到如何基于用户洞察设计产品的业务架构 ，其目的是为了实现业务的解耦，以便构建一个“轻型”的2B业务系统，实现可扩容的架构，使得整个系统能够跟上业务快速发展的步伐，而不必为了新业务的增长而重构系统。
我们也花了几个篇幅来介绍 “产品架构”的概念、思路和设计的方法，并复盘了一个 2B产品的多租户架构设计 案例。
如果你稍微细心，就能发现其中还缺少了一个关键的环节。
是的，这个环节就是 “用户对象”的问题，就是整套业务系统里面，到底应该如何构建一个能够“容纳”不同角色的用户体系并行处理业务，如何实现跨流程的协作。
（图片来源：微言）
事实上，这个问题对系统的影响还包括如何构建角色和权限模型，这一点在后续将继续展开。本文仍然以“O2O平台”作为案例展开。
01
基于工作流梳理用户对象
2B的产品，简单的来说，就是解决很多的用户（发布在很多业务部门，涉及各种交叉并行的业务流程）如何高效率的协同工作的问题，不管是我们常见的OA系统，还是各种复杂的ERP、CRM系统，还是前些年火热的O2O平台。
对任何面向企业的产品来说，都是一头挑起各种不同的用户角色，另一头挑起协作效率的重任。对普通的使用者来说，这套系统的价值在于节省时间和工作量，通过使用这套系统来实现自身（个人或部门）“业绩”和能力提升。对企业的管理、决策者来说，这套系统的最多价值在于如何有效的提升整个企业的业务能力。
换一种说法就是，2B的产品，本身就是一个实现企业业务运作协作的工具，它的难点在于，如何更有效率的容纳N种角色和N多并行业务的处理能力，并通过这一产品，实现企业业务流程的优化创新。
2B产品的设计实践，也就是思考如何基于企业客户的业务场景，实现个人 vs 组织的“矛盾性”需求的过程。
不管各种新奇的理论如何，我们首先做的第一件事情始终都是在围绕用户展开，通过实地的业务模拟，考察和分析推演，结合具体的业务流程和工作流程，拆分各个“群体”——系统的服务实体对象。
在构建整个 O2O平台的过程，我们大致梳理的业务过程，包括用户发起服务请求、后台处理服务请求、前端完成服务请求三个过程。
（图片来源：微言）
用户（不管是2B的客户，还是2C的终端用户）可以通过多种方式发起客服服务请求，在这个过程中，坐席端的首要任务就是如何及时响应用户端的请求，完整的记录用户的问题，并快速解决用户的问题。
从这个过程中，可以拆分的产品价值包括用户端的体验问题以及坐席端的效率问题。
也就是，在这个过程中，需要拆分和解决的问题包括：
. 如何建立完整的用户请求的通道（全覆盖的通道能够提升用户的整体体验）；
. 如何解决坐席的快速解决用户的问题（任何一个服务平台都希望尽可能的提高一次服务过程解决用户问题的比例，这需要一个足够高效的知识库）；
. 如何帮助坐席快速，完整的记录用户请求的内容，也涉及到当服务请求过大时如何分配合理的坐席资源。
这些问题不但涉及到产品的架构设计，也是产品的交互和视觉设计的重要参考依据，必须充分结合实际工作场景，方式和流程，来考虑在交互上的便捷性，甚至视觉上减轻使用者的疲劳感。
实际上，这也是技术选型的重要指标性因素，所以通常来说，产品的需求文档必须要有明确的技术性指标，包括响应时间，并发数等。
ps：在前文 浅析产品的信息架构、产品架构与业务架构 谈到的" 产品的抽象能力 "，指的是这种从上往下的业务分析能力，而不是指能从下往上看各个细节。
对产品经理来说，面向任何一个业务需求，都首先要从大方面思考，再深入到细节性流程，一旦反过来，则整个产品只有功能，而没有业务。
调度，指的是针对某类型用户/客户，发起服务请求的响应和处理。
也就是基于“效率至上”的原则，如何调配最合适的工程师解决用户的问题是最经济，最高效，在这个过程，涉及到很多种场景的优先考虑，比如有些问题只是一般性的咨询，有的问题则严重的质量问题，还有的问题可能已经引发了群体性和舆论性问题。
这不但需要建立一种完备的处理机制和流程，首先则是需要赋予一线“接线员”相应的权限和能力，能够第一时间识别到风险，也能快速调动相关的资源，及时处理用户问题。
在产品和技术上的处理细节，还需要考虑到资源的瓶颈性，系统必须要能人工干预的调度资源，还要能建立一个“众包”的通道，打通更多的社会性资源加入“平台”，同时也在一定程度上激发工程师的积极性，来提高服务的处理效率。
这个环节，也是最终如何处理用户服务请求的过程，也是一个对服务质量考核的关键节点，包括服务响应时间、服务质量、用户评价等过程。
业务上，这个环节在某些场景还可能存在服务和产品的二次销售行为。
综上所述，我们就能够把整个复杂的业务过程，抽象成三大“业务动作”，也就是支撑整个系统能够正常运转的基本节点，想象一下房子的支柱，即可理解这种思路设计的系统有的那些优势。
换言之，我们在第一阶段设计产品的架构时，根本无需过多的考虑分支流程和细节性逻辑，只需要构建一个支撑平台即可完整的还原整个业务流程。
也就是，我们可以想象自己在打造一个桌面，只需要考虑桌子的四个角之间的构造合理性、稳定性和承重能力，就可以保障未来的业务扩展。
在架构设计的阶段，我们可以把上述的业务流程进一步抽象，整个的业务模型可以表达如下：
从整个模型上，我们既能看到要服务的用户对象，也能看到各个服务的实体，以及在整个过程中关键业务动作，围绕这些动作，即可完成各种不同场景下的业务订单。
这个平台是一个高度解耦的系统，能够兼容不同的业务和不同的单据格式和内容，对整个系统而言，表现层的内容对业务本身不构成影响因子，整个平台仅依赖“业务动作”的高效运转。
从整个业务模型中，我们梳理出了一个业务全貌，可以清晰的识别到各个服务层所承载的服务能力，即可根据各自的能力进一步的拆分出实体的“业务范围”。
我们也就能基于对整个业务场景的透彻理解，从实际业务的角度逐级分解整个用户角色的边界和在流程中的承接和交互关系。
这种从逻辑层的分解，在系统的设计中，就直接演变对应到实际中的“业务实体”，也就是不同的业务应用对象，他们直接承载着整个平台的业务运作。
(ps，在实际的产品设计中，只需要依据业务场景的展开，即可完整的勾绘出整个平台的业务关系，本文为方便描述，本文示例进行了大量的简化工作。)
（图片来源：微言）
从上图可以清晰的看到不同的实体，他们的业务边界非常的清晰，在这个逻辑下，我们可以清晰的设计各自的工作流，也就能清晰的界定不同的用户角色权限。
以“门店”为例，TA在这个角色关系中，实际上处于一种“上下承接”的关系。
向上对接订单的调度，负责总部的调度机制和工单协调机制；向下，对接其旗下的服务工程师，负责工程师的调度和工单的协调。
按照这种思路，我们在设计“门店”这个角色和工单的流转业务中，就能很明确的限定它在这个平台中的地位，换句话说，也就能界定它的权限范围和需求范围。
也就不会再出现随意性的变更，因为它受制于整个平台的管理规范。
基于这种思路，我们就能够有效的拆分复杂的应用，解耦整个系统的框架设计，也就能清晰的描述各个用户角色在平台上的职责、权限和价值体现。
整个平台是基于角色的工作流作为出发点，而不是账户，两者可实现柔性的关联关系，而不是强制性的管理关系。
任何用户，只需要符合某种角色身份就可以在平台中自由完整的执行业务动作。这也是整个平台账户体系设计的基本思路。
“标签”的目的，除了简化系统设计以后，还有一个重要属性就是构建柔性的网络管理规则，可以根据不同的业务需求，直接配置不同对象。
标签系统可以根据角色的类别、属性、业务动作等进行分解。如下图所示：
（图片来源：微言）
这个图，有出现“类别”、“属性”、“可视范围”、“业务动作”这些名词。实际上这四个名词并非通用性术语，而是在构建这个平台以及制定整个平台的SOP采用的一种项目化语言。
根据我的经验，采用这一约束性的项目化语言，有助于团队快速的理解需求，并在规范的范围内加速产品的应用落地。
这里还引入了一个重要的属性：可视范围。简单的说，就是一个坐席、或者门店，工程师可以根据他们的实际情况，配置他们所能履约完成的业务范围，比如A门店具备上门服务的能力等。
对于一个产品 / 系统来说，决定业务的是每一个独特的实体对象，也就是在整个工作流过程中的角色，只需要紧扣角色对象，就能够清晰的界定整个平台的边界范围——直接给业务实体打标签。
但我们却容易停留在表面，而没有能够深入业务，更谈不上对用户动机的深刻洞察。
换句话说，我们在用户调研过程中，过于倾向于关注用户的行为动作，而不是动机——用户画像过多的停留在个人信息和人口学属性的集合，而没有能够深入到实际业务中。（我们最容易犯的错误就是过于停留在产品的功能上，而不是业务场景中）
比如，调研发现用户需要频繁的打印那些有规划地点、线路的订单，如果只是去设计一个高效的打印、排版的订单处理和调研界面，显然不是更好的解决方案。
对产品而言，不能提供关于“用户态度和行为特性”的人物角色只是一个“鸡肋”般的存在，因为无法真正理解用户的痛点，无法真正解决用户的“绩效问题”，也就根本不能设计一款真正符合用户预期的产品。
“当用户使用某个产品的时候，他们是为了完成某个特定的工作(到达某种结果)”，这是一句产品名言。
在设计产品时，真正值得高度关注的是用户的目标、产品的使用场景以及用户与产品的关键交互阶段，而不是把焦点集中在用户的任务是什么以及如何完成任务。
所以，在设计用户角色模型时，应该分成两个步骤来完成：
1、建立对人物角色的同理心
包括用户的履历和年龄、收入等人口学属性。
包括用户的态度和行为，使用产品的目的和动机，以及在使用产品时的行为细节、偏向和心理感受。
通过对全新的企业类产品形态的探索，发现很多TO C领域的设计方法在面对企业级的用户时，在运行架构上显得格格不入，为了能够提高企业生态的高效运作， 今年IXDC邀请到了来自腾讯云设计中心高级交互设计师苏旎来分享企业产品设计方面的设计经验与设计方法论，帮助设计创作者们了解更多在产业互联网下设计师应有的设计视野和格局、方法与技巧。
（图片来源：苏旎）
在这次工作坊当中会以华星光电、银户通等等腾讯云标杆项目为案例，讲述如何利用3I空间模型设计师在投身产业互联网相关的企业项目时，能获得更多的灵感与思考。从执行到归纳验证形成一个重叠的空间构成的体系，帮助参会者掌握企业项目设计的方法。
企业的工作与发展的过程当中，“会议”是一个必不可少的环节， 是保持对内和对外的信息交流和沟通的一个重要的路径。 今年的IXDC工作坊就请到了来自GE 通用电气的航空亚太区设计负责人林雅，来讲述如何通利用一些简单实用的工具帮助我们降低与客户的沟通成本，提升工作坊效率。
在人的五大感官中，视觉在接受和传达信息方面的占比高达80%，这说明在信息的处理过程当中有了视觉化的表达作为帮助，可以明显提升人对信息的理解力和记忆力。这次工作坊主讲人将视觉化会议在一次用户访谈工作坊中的应用为例，剖析视觉化与设计思维的结合，帮助参会者可以更深入地了解视觉化会议，掌握通过视觉化会议提高对内对外的工作效率。
互联网市场转向，众多一线互联网公司在ToB业务中倾入了更多的资源，以此来解决ToB系统中用户角色复杂，职业惯性和行业特性鲜明等问题。 在今年IXDC工作坊当中，会有来自京东物流用户体验部的交互设计经理穆倩雯来为现场为参会者现身说法，搭建一套能快速理解产品模型，精准定位用户痛点，快速抓取业务场景的设计方法
这次的工作坊将逐个击破复杂业务场景中的设计冲突，在ToB设计中为大家打开新的设计思路，结合用户体验地图及服务设计蓝图，细化并规范每个阶段应用到的设计方法及产出物，形成一套好执行、可落地的体验方法，从而帮助设计师了解ToB系统的全流程设计分析方法。
企业级产品的最终目的就是用体系化的设计思维、设计方法和设计工具搭建起产品与最终用户之间桥梁，扩展设计的边界、帮助业务价值的最大化， 今年IXDC邀请到了来自Alibaba Design-阿里云的体验设计专家杨涛来分享通过建立云产品易用性测试，体验质量度量方法促进企业级产品体验管理升级。
（图片来源：杨涛）
在这次工作坊当中会3个云计算行业的设计团体标准的案例为案例，讲述如何建立云计算行业的设计标准，了解云产品与中后台产品的系统化思维导入。再学习体系化的产品体验度量方法以及中后台产品易用性测试方法，学习整套设计SOP体系应用实践。
（图片来源：杨涛）
【IXDC2020工作坊选课攻略推荐合集】
智慧企业工作坊内容集合
文娱教育工作坊内容集合
智慧医疗服务工作坊内容集合
生活服务工作坊内容集合
智能科技与产品创新工作坊内容集合
出行服务工作坊内容集合
电商与新零售工作坊内容集合
品牌升级工作坊内容集合
普惠金融服务工作坊内容集合
https://mp.weixin.qq.com/s/9byVfjAnnZN4b5St6ktfGQ
