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

0 评论 5012 浏览 14 收藏 16 分钟

编辑导读:场景是一个产品的灵魂,生产出来的东西,要明确 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端应用增加“预约取消”功能,这里工单相应的状态应该还有“用户已取消”。

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

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

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

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

4. 医院——终端显示屏

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

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

03  写在最后

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

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

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

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

 

本文由 @南方碟道 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!