复杂场景产品设计实践与思考——【医患看病】场景

01 引言

“大家在做产品时，经常提及、用到的词儿有哪些？”

用户、客户、市场、业务流程、产品功能、痛点、产品定位、产品价值、竞品、产品优势、产品规划、MRD、PRD、迭代、上线、bug、排期、测试、效果？除了这些之外，还有哪些词儿是经常用到，同时又是非常重要的呢？可跟着我一起想一想哈~

是不是，还有“场景”、“数据”、“优化”、“定价”、“计收”……数不胜数，就是这么些一个又一个短小精悍的词语，构成了我们产品汪的工作日常。

再深究一步，开头我罗列的那些“词儿”都是什么时候用到的，是否清楚？在回答这个问题之前，首先要弄清楚一个新产品/一个新的产品功能/一个新的产品矩阵，从0-1，然后再从1-0的完整阶段是什么样子的，可参考下图：

当你试着将这些词语按照上述流程（0-1-0）归类的时候，实际上你同时也在回答着“在什么阶段、谁该干什么事儿”的问题，即“这些词儿的应用场景是什么”。下图是我梳理的，在什么环节该干什么事儿的示意图，可参考：

“我认为场景是一个产品的灵魂。”

——即生产出来的东西，要明确 for who，for what，用来谁的解决什么问题。

而今天这篇文章，我主要想探讨的是如何从实际业务场景中抽象出一个功能、一个产品或一组产品。我将以一个【病患预约看病】业务模拟场景为例，尝试搭建一套产品矩阵，来实现“病人预约看病、医生看病诊断、病患复查医生复诊”的业务需求，假定需求来自于销售。

02 场景产品设计实践——【病患预约看病、医生接诊】场景

在进行场景产品设计前，我们要先调研、梳理清楚实际的业务流程，都有哪些环节，哪些角色参与，每个环节哪个角色做什么？在整个业务流程中，哪些是客户已建设的？你的团队要做的是全套流程产品，还是其中某几个环节的产品？然后是怎么做？做成什么样？做完了，能够解决哪些问题/提供哪些服务？作为场景PM心里要一清二楚。

【病患预约看病】场景的业务流程大致如下：

1. 新建就诊预约——“看病预约”微信小程序

对于患者（需要预约挂号的用户）来说：应该有一个平台，可以为患者提供看病预约，应支持按科室（如内科、外科；妇科、儿科；肝肠科、牙科等）、按医院、按医生、按地理位置进行组合筛选、按日期-时间创建预约。

所以这里我考虑 以“即插即用”小程序的形态，为患者提供“看病预约平台”。初期可以先打通1-2个医院的数据库（需包含医院信息、医生档案等信息），后续考虑打通多个医院的数据库，供用户新建预约时选择和查看；至于我们新建一个库表，用于存储医院、医生档案等信息，还是我们要用的时候去客户 数据库里现查，这个主要由实际情况和需求实现难易程度等多个因素决定，对于PM来说，我们只要将需求、数据情况、客户数据对接情况阐述清楚即可，剩下的事情交给研发。

由于用户可能需要按地理位置远近进行医院筛选，所以需要自动定位功能；

为保证医生资源得到合理的利用，需要用户支付挂号费才能预约，超时未支付，预约自动取消，因此还需要和支付系统打通；

此外，在实际场景中，病患只能在选定时段内（如8:00-10:00）参加一个就诊，无法同时参加多个就诊，故系统功能上还要考虑： 同一病患在同一时段只能创建一个预约任务这种边界情况。

在进行上述系统设计时，还需要考虑资源分配的问题，即两个人同时预约了同一时段的同一医生，这种情况该怎么解决？一个手段是按照预约任务提交时间的先后顺序决定，另一个手段可以是谁先支付谁优先，还可进行策略的组合。类似于抢票、打车场景，背后需要有一套资源分配和合理调度的策略逻辑，当然这需要PM 指导业务，研发人员具体设计策略实现。

假定患者在既定时段内，前往医院顺利完成了就诊。在就诊后，患者应能够查看医生出具的诊断证明和诊断记录，以及自己当时创建的预约信息（预约看病的时间、科室、医生姓名、医院地址、填写的病情描述等）。

此外还需考虑，患者创建的预约是否支持取消，取消的规则又是怎样的？

至此，小程序（看病预约平台）的功能点已基本产出了，这里我将【取消预约】、【就诊提醒】这两个功能的优先级放在了P1，原因是：“取消预约”、“就诊提醒”，并不影响业务流程的完整性，故考虑后续再建设（仅供参考，读者可以有自己的思考）。

留心的读者可能还注意到了：我增加了“登录”功能，登录后才可挂号，这是为何？许多小程序都要求用户微信或手机号登录后才能使用 其中的一些功能，这又是为何？我认为，原因有二：

• 一是由某些产品的功能权限决定的。比如微信支付，支付宝支付功能，在付款时，是要求用户登录微信/登录支付宝账号，才能付款，保证 安全性。
• 二是由产品设计的功能本身决定的。对于“看病预约”这个小程序，后台需要识别哪个用户创建了哪天的预约，这是最基本的，那后台到底怎么区分用户A 还是用户B呢？一个常见的方式，就是要求用户登录授权，用户授权后，后台便可通过用户微信ID，或手机号，来区分哪个用户是A，哪个用户是B。有了用户唯一ID，后台便可以记录每个用户必要的操作信息，用于完成某个产品功能，还可以提供个性化推荐等功能。

关于该小程序登录，我的需求是这样的：登录后才可挂号。即 挂号功能是有权限限制的，即登录后的用户才可使用；未登录的用户不可使用。这里我提到的是功能权限，与用户权限、角色权限又有什么区别和联系呢？我们来看下图：

所以，在设计带有用户权限的产品时，一个逻辑通常是：先确定该产品有几类角色，每类角色的功能权限/数据权限是怎样的？然后为各个角色赋予功能权限/数据权限，最后才是角色与用户的关联；因为功能和角色是数得过来的，而用户量是无法精确预知的，没办法每次都为一个新用户开通/禁用每一个功能权限，这样做就很傻。

通过用户是否登录来判断， 用户是哪种角色，是新用户、老用户、还是游客？通过用户身份判断是管理员、超级管理员、还是普通用户？然后再判断当前用户的功能权限有哪些。

2. 看诊任务分发

在进行任务分发设计前，要明确 任务/工单的接收对象都有谁？这里任务/工单的接收对象为“医院”和“医生”两大类对象。

在系统建设初期，首先需确保按照一定的分发逻辑，使得工单能够正确地送达至接收对象处，而后需要考虑的是，如何盘活池子里的医院和医生资源，使得C端用户（患者）能够预约到想预约的科室/医生？这时就需要一整套智能分发逻辑了，由此整个系统也从 『传统应用系统』 向 『智能化应用系统』转变。滴滴、美团、携程等工单分发的策略，是非常复杂的，想进一步了解和学习的，可以阅读下面这篇某大佬的文章，可能会有些领悟。

https://blog.csdn.net/jinjin603/article/details/78793243/

3. 医生看诊——PC端web应用『看诊系统』

按业务流程，系统分发后，该某医院的医生看诊了。没错，这里，我考虑做一套『看诊系统』，PC端web应用。用户是各个医院的医生和各个医院主体。

系统功能很简单，核心功能是『查看详情』和『开始看诊』。看诊工单分为两个状态：“待看诊”和“看诊完成”。若C端应用增加“预约取消”功能，这里工单相应的状态应该还有“用户已取消”。

• 对于超级管理员来说，可以查看所有医院、所有医师的看诊工单；
• 对于医院管理员来说，只能查看当前医院的所有医师的看诊工单；
• 对于医师来说，只能查看自己的看诊工单，同时填写诊断意见和上传诊断报告；

在实际业务中，还需清晰定义各个状态的含义，比如“待看诊”指的是，当前时间还未到达用户预约的看诊起始时间；“已看诊”的判断逻辑是，医师填写完诊断意见和上传完 诊断报告，提交“看诊完成”时，即认为 当前工单的状态是“已看诊”。当然，还可增加其它状态，如看诊中。

医院、医生该如何使用该系统？

工程狮们开发完成这套软件后，要依次给各个对接的医院开通账号，没错，假设对接了100家医院，且这100家医院都有医生要用你这套系统，那么你们团队就要为这100家医院开通账号，在每个医院账号下，还要挂接该医院的医生信息，医生用其姓名/医生代码（我编的，类似于职工编号）可登录系统进行看诊操作。

4. 医院——终端显示屏

医院通常会有一个显示屏，用于向来医院看病的人，展示当天的就诊记录，通常长这样：

这里就是一个简单的信息展示功能，需要明确展示哪些信息，不展示哪些，哪些信息展示时需要脱敏处理即可。比如要向患者和医生，展示本医院，当天等待就诊的全部就诊记录，包括：序号、患者姓名、就诊医生姓名、诊室名称及诊室门牌号、候诊状态（等待看诊、就诊中）用不同交互区分（如颜色不同或滚动效果）。

03  写在最后

本文以 〖看病预约、到医院就诊〗的实际经历出发，尝试搭建了一套 【用户看病预约】场景的产品矩阵，重点在阐述场景产品的设计思路，希望可以提供一些经验。

身处这个互联网时代里，可以发现，不论是ToC 的产品还是 ToB 、ToG 的产品，只要涉及 机构、组织，基本上都需要多产品、多方角色参与才能走通 某一场景的具体流程，滴滴、淘宝、美团、医美类产品，无一例外。任何产品最后都逃不开商业化变现，当抖音、快手、小红书开始引入电商，允许用户注册为商家后，就带有了“To B产品”的基因，负责他们的产品经理们必然也逃不脱对业务流程和业务场景的梳理。

因此掌握业务流程和业务场景，是场景产品搭建和市场分析的第一步。

学习，思考，实践，成长，是产品经理永远的必修课，共勉。

本文作者 @南方碟道

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！