復雜場景產品設計實踐與思考——【醫患看病】場景

編輯導讀：場景是一個產品的靈魂，生產出來的東西，要明確 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協議