当前时间： 2026-03-28 18:20:46
更新时间： 2026-03-28
分类：软件教程
评论(0)
做医疗 H5/APP 的那些坑,我替你踩完了
我做产品这几年，有两段经历让我对”需求”这个词有了完全不同的理解。
一段是跨境电商，用户要什么给什么，转化率就是一切，快就是好；另一段是医药大健康，你以为你懂用户，结果发现你连”用户为什么不信任你”都搞不清楚。
这篇文章不讲方法论框架，我就讲我亲历的几次踩坑——每一次都觉得自己要做出来了，然后数据告诉我：不，你还差得远。
坑一：你以为用户要”功能”，其实他们要的是”不害怕”
我第一次做医疗类 APP 的时候，是给一家做慢病管理的公司。产品定位很清晰：帮高血压患者记录血压、用药，连接医生远程复诊。
我当时特别自信，把核心功能做得很完整——血压趋势图、用药提醒、一键问诊、健康报告……说实话，从产品层面看，这个东西是真的好用。
新用户注册率还可以，但第一步——”绑定血压计”这个动作，完成率只有 31%。
我看着这个数字，完全想不通。流程很简单啊，蓝牙配对，三步搞定。我拉着运营去做用户访谈，结果一个大叔说了一句话，让我至今记得：
“这个 APP 是哪家医院的？不是医院的，我不敢往里放数据。”
我当时脑子里只有一个想法： 完了，我连这个用户在想什么都不知道。
他的逻辑是：血压数据是隐私，万一被卖了怎么办？万一数据不准，医生误判怎么办？这个 APP 没有医院背书，凭什么相信它？
这跟我做跨境电商时完全不同。电商用户的心理是”我试试，不行退款”，损失有限，决策成本低。但医疗用户的心理是”这个东西跟我的身体和健康相关，我不确定我要付出什么代价”。
信任，是医疗产品的第一道门槛。不是功能，不是 UI，不是价格。
-
在首页最显眼的位置加了”三甲医院合作机构”的 Logo（我们确实有合规合作）
-
绑定血压计的前置页，加了一段 30 字的隐私声明，用大白话写，不是法律文本
-
增加了一个”医生认证主页”模块，让用户在问诊前能看到医生的执照编号和坐诊医院
方法论输出： 医疗产品设计的第一步，不是画流程图，是”信任审计”——把你的产品从头到尾走一遍，列出所有可能让用户产生”我不确定这个东西安不安全”的节点，逐一消除它。
我们在做一个面向 C 端的健康科普 H5，配合一款 OTC 药品的营销活动。当时运营提需求说，要做一个”症状自测”功能——用户输入症状，系统给出可能的健康建议，顺带推荐产品。
我一听，逻辑很通，用户路径也清晰：自测 → 认知问题 → 了解产品 → 购买。转化链路完整。
原因是：H5 里有一句文案写着”您可能患有 XXX，建议使用 XXX 产品缓解症状”。这句话在医疗广告法里属于 暗示诊断 ，OTC 产品的宣传不能有诊断性语言，哪怕是”可能”。
我们在 72 小时内紧急修改上线，损失了一部分活动窗口期。复盘的时候我很沮丧，因为这件事完全可以在设计阶段就规避掉。
我在设计阶段没有把”合规审核”纳入流程。我以为合规是法务的事，产品做完交给他们审就行。但实际上， 合规约束应该在需求评审阶段就进来，而不是等到上线前 。
医药类产品的合规雷区，每个 PM 应该心里有一张基础地图：
-
不能有诊断性语言 （”您患有 / 可能患有 / 症状符合”）
-
不能有绝对化功效描述 （”彻底治愈 / 100% 有效”）
-
健康类内容如果有具体数值建议 （如”每日服用 X 毫克”），必须有医生背书或标注来源
方法论输出： 建议在项目启动时就拉一个”合规 checklist”，把你们产品涉及的监管边界列清楚，变成需求评审的标配流程。不用自己搞懂所有法条，但要知道哪些地方需要拉法务进来。
坑三：H5 的用户路径，你测试过”网络差”的情况吗？
这个坑听起来很基础，但我敢说，90% 的医疗 H5 项目都踩过。
我们有一次做一个患者教育 H5，核心是一个 5 步的问卷 + 结果页，最后引导用户扫码加医生助手。内网测试完全没问题，流畅丝滑。
上线之后，我们发现有一批用户在第 3 步大量流失。
起初我以为是第 3 步的题目太难，或者太多，就去改题目。改完没什么变化。
后来做漏斗分析，发现这批流失用户有一个特征：他们来自某次在医院大厅做的线下推广扫码。
第 3 步有一个图片加载——是我们嵌入的一张医学示意图，压缩前 1.2MB，网络差的时候加载超时，用户看到一片白，以为页面崩了，就退出了。
解决方案很简单：图片压缩到 200KB 以内，加一个骨架屏，加载失败给一个重试提示。
改完之后，第 3 步流失率从 41% 降到了 18%。
但我真正想说的不是这个技术方案，而是一个思维习惯：
医疗类 H5 的用户使用场景，往往是网络最差的时候。
医院候诊室、病房、药店收银台旁边……这些场景的网络质量都不乐观。而且医疗产品的目标用户（中老年、慢性病患者），手机性能往往也偏弱。
我后来做医疗 H5，测试环节会专门加一条： 用 4G 限速模式跑一遍全流程 ，当成 standard case，不是 edge case。
方法论输出： 医疗 H5 的测试矩阵里，必须包含”弱网 + 低端机”这个组合。建议直接在测试用例里写死，不要靠自觉。
我们做一款面向基层诊所医生的工具 APP——帮助他们做患者档案管理和随访记录。0 到 1 的阶段我们做了充分调研，访谈了 20 多个诊所医生，迭代了 3 个版本的原型，终于上线了。
上线第一周，日活 200+，好评不少，团队很兴奋。
我们开始追着用户问：哪里不好用？他们说挺好用的。那为什么不用了？他们说……太忙了，忘了。
这句”忘了”，差点让我以为是留存问题，去做推送、做签到、做积分体系。
但实际上，真正的问题是： 这个产品没有嵌入他们的工作流。
诊所医生的工作流是：患者来 → 问诊 → 开药/开检查 → 收钱 → 下一个。档案和随访，是”做完这些之后还有精力才做的事”。我们的 APP 是额外的操作负担，不是他们工作流里的环节。
这个问题在调研阶段没有暴露，因为医生在访谈里会说”这个功能挺有用的”——有用，和”我会在工作中用它”，是两回事。
后来我们做了一个很重要的改版：把随访记录的触发点，从”主动打开 APP”改成”接到患者电话时的弹窗提醒”，并且接入了诊所的叫号系统，让档案在患者到诊时自动弹出。
本质上，我们把产品从”独立工具”变成了”嵌入式模块”。
改完之后，日活稳定在 150+，次月留存从 22% 涨到了 51%。
方法论输出： 医疗工具类产品，0 到 1 阶段最重要的问题不是”用户需不需要这个功能”，而是”这个功能在用户的哪个工作流节点触发，谁来触发，触发的成本是什么”。如果你的产品需要用户专门”记得打开”，留存大概率会很难看。
不是因为技术复杂，而是因为你面对的是一个对错误容忍度极低的领域。用户的信任很难建立，一旦破坏几乎不可修复；合规的边界很模糊，踩一次雷可能伤筋动骨；用户的实际使用场景和你想象的往往差很远。
但也正因为如此，这个行业的产品一旦做对了，壁垒非常深。
如果你现在正在从 0 到 1 做一个医疗产品，这四句话可以贴在你的需求文档第一页。
不一定能让你少踩所有坑，但大概率能让你少踩这几个我踩过的。
如果你也在做医疗/大健康方向的产品，欢迎评论区交流，或者私信我，我们聊聊。
夜雨聆风
