2. 医疗App需求分析与用户研究

在患者端医疗App的开发中,需求分析不是简单地罗列功能清单,而是要从真实患者的就医行为中提取出可验证、可排序、可落地的产品需求。本节围绕四个相互衔接的工作环节展开:建立患者画像、绘制就医旅程地图、从旅程中挖掘核心痛点、对需求进行优先级排序。这四个环节构成一条从“理解用户”到“确定做什么”的完整分析链,最终输出一份可指导原型设计和迭代排期的需求优先级清单。

一、患者画像:从人口属性到就医行为特征

患者画像不是给用户贴标签,而是建立一组能够影响产品决策的用户模型。一个可用的患者画像至少应包含四类信息:基本属性(年龄、地域、职业、数字素养)、健康状态(慢病类型、病程阶段、是否多病共存)、就医行为(就诊频率、常用科室、是否异地就医、是否使用医保)以及工具使用习惯(常用手机型号、是否愿意在线支付、是否使用过在线问诊)。

以“65岁、二型糖尿病、居住在地级市、每月到内分泌科复诊一次、由子女代为操作手机”的患者为例,其画像直接决定了产品需要支持“家属代管”“大字号模式”“复诊提醒”等能力。画像的价值在于:当团队对某个功能产生分歧时,可以回到画像判断“这个功能对目标患者是否真的必要”。

二、就医旅程地图:把就医过程拆成可观察的阶段

就医旅程地图将患者从出现症状到完成治疗的全过程拆解为若干阶段,并标注每个阶段的行为、触点、情绪和障碍。对于患者端App而言,典型的旅程阶段包括:症状感知与信息搜索、选择医院与科室、挂号与预约、到院签到与候诊、就诊与检查、缴费与取药、离院后随访与复诊。

绘制旅程地图时,关键不是画得漂亮,而是把每个阶段的“触点”和“情绪低谷”标出来。例如在“选择医院与科室”阶段,患者常见的障碍是“不知道挂哪个科”;在“到院签到与候诊”阶段,情绪低谷往往出现在“排队时间长且不知道还要等多久”。这些情绪低谷就是后续痛点挖掘的入口。

患者就医旅程地图与痛点—需求映射 时间 症状感知 搜索/问人 选院选科 挂号决策 预约挂号 支付/取号 到院候诊 签到/等待 就诊检查 问诊/检验 缴费取药 离院随访 情绪 不知挂哪科 候诊时间不明 缴费排队重复 核心痛点 • 科室选择困难,反复退号 • 候诊进度不透明,焦虑等待 • 缴费取药多窗口往返 • 报告结果看不懂、找不到 • 复诊提醒缺失,依从性低 对应需求 • 智能分诊/科室推荐 • 实时叫号进度推送 • 诊间支付与药房导航 • 报告解读与归档 • 用药提醒与复诊预约 优先级判断依据 • 影响患者数量(广度) • 情绪低谷强度(痛感) • 实现成本与合规风险 • 是否依赖院内系统改造 • 能否独立闭环交付

三、核心痛点挖掘:从情绪低谷到可验证的问题陈述

痛点挖掘不能停留在“患者觉得不方便”这种模糊描述上,而要转化为可验证的问题陈述。一个合格的问题陈述应包含:谁、在什么场景下、遇到什么障碍、导致什么后果。例如,“首次就诊的异地患者,在挂号时无法判断应挂哪个科室,导致反复退号或挂错科室,平均多花费半天时间”。

挖掘方法上,建议组合使用三种手段:一是对10~15名目标患者进行半结构化访谈,重点追问最近一次就医的完整过程;二是分析App内已有行为数据,如挂号取消率、页面跳出率、客服工单关键词;三是观察候诊区、缴费窗口等现场行为。三种手段交叉验证后,保留出现频次高、情绪强度大、且现有方案未解决痛点的问题。

四、需求优先级排序:用可解释的规则替代拍脑袋

需求排序常用的框架是“价值—成本”矩阵,但在医疗场景中需要增加两个维度:合规风险与依赖条件。合规风险高的需求(如在线开具处方)即使价值高,也可能因政策限制而延后;依赖院内系统改造的需求(如实时叫号接口)即使价值高,也可能因对接周期长而排在后面。

一个可操作的排序方法是加权评分法。对每个需求按五个维度打分(1~5分):患者覆盖广度、痛点强度、实现成本(反向计分)、合规风险(反向计分)、独立交付能力。再根据当前阶段目标设定权重,例如MVP阶段将“独立交付能力”权重设为0.3,“实现成本”设为0.25,其余各0.15。计算加权总分后排序,得分高者进入首个迭代。

需求 覆盖广度 痛点强度 实现成本(反向) 合规风险(反向) 独立交付 加权总分
智能分诊/科室推荐 5 5 3 4 4 4.25
实时叫号进度推送 4 4 2 4 2 3.20
诊间支付与药房导航 4 4 3 3 3 3.40
报告解读与归档 3 4 4 4 5 3.95
用药提醒与复诊预约 4 5 5 5 5 4.80

上表为示例评分,权重设定为:覆盖广度0.15、痛点强度0.15、实现成本0.25、合规风险0.15、独立交付0.30。计算方式为各维度得分乘以权重后求和。例如“用药提醒与复诊预约”得分为 4×0.15 + 5×0.15 + 5×0.25 + 5×0.15 + 5×0.30 = 4.80。该结果说明在MVP阶段,独立交付能力强、合规风险低的需求应优先进入开发。

排序结果不是永久结论。当院内接口对接完成、合规政策明确后,原先因依赖条件被压后的需求(如实时叫号)应重新评估并可能提前。建议每个迭代周期重新跑一次评分表,保持排序与阶段目标一致。

五、从分析到交付:本节的可执行产出