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

文章插图
在系统建设初期，首先需确保按照一定的分发逻辑，使得工单能够正确地送达至接收对象处，而后需要考虑的是，如何盘活池子里的医院和医生资源，使得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产品”的基因，负责他们的产品经理们必然也逃不脱对业务流程和业务场景的梳理。
因此掌握业务流程和业务场景，是场景产品搭建和市场分析的第一步。
学习，思考，实践，成长，是产品经理永远的必修课，共勉。