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

小青爱吃草2021-06-19  171

编辑导读:场景是一个产品的灵魂,生产出来的东西,要明确 for who ,for what,用来谁的解决什么问题。本文作者以医患看病的场景为例,分析在这样的复杂场景下,要如何进行产品设计,希望对你有帮助。

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端应用增加“预约取消”功能,这里工单相应的状态应该还有“用户已取消”。

转载请注明原文地址: https://www.pcnow.com.cn/tech/503655
00