题干与适用场景
请为需要长期服用多种药物、独居且偶尔漏服的老年人设计一款用药提醒产品。你会如何划分用户、识别核心痛点、定义 MVP、处理误服与照护协作风险，并验证产品有效？
这是一道产品经理的产品设计题，核心考察能力是能否从模糊人群和高风险场景中选定用户、问题与边界，再把方案推进到可验证的最小产品。当前公开的产品面试资料仍把 product sense、product design、产品案例和 product thinking 列为面试环节或评价维度。本文据此说明题型具有现实代表性，不声称某家公司使用了这道具体题目，也不声称无法核验的出现频率。
为便于推导，设定一个虚构练习场景：主要用户独居，长期服用 4 种药物，每天有 3 个计划用药时段；会使用智能手机，但对复杂设置缺乏信心，偶尔因忘记而漏服。产品由本人持有，照护者只能在本人明确同意后参与。
首版产品只帮助用户保存经本人或专业人员核对的用药计划、发出提醒、记录用户自行确认的状态，并在用户授权下通知照护者。它不诊断、不推荐剂量、不判断漏服后是否应补服，也不把点击“已服用”当作临床依从性的证明。药物发放硬件、严重认知障碍照护和需要实时临床监测的高风险用药不在首版范围。
面试官考察点
第一项信号是是否会切分“老年人”。独居但能自主用药的人、需要家人协助的人、存在严重认知障碍的人，目标、权限和产品形态都不同。普通回答把所有人放进一个画像；强回答选择一个首要人群，并说明哪些用户需要硬件、专业照护或另一套产品。
第二项信号是能否区分原因。漏服可能来自忘记、看不清标签、计划已经变更、药物太多、担心副作用、费用压力或主动停药。提醒只能直接处理一部分非故意漏服。若原因是副作用或费用，增加通知次数既不能解决问题，还可能让用户关闭全部提醒。
第三项信号是安全边界。产品必须区分“提醒已送达”“用户已操作”和“药物确实已服用”。它还要处理计划过期、重复确认、用户不确定是否服过、照护者越权和通知疲劳。强回答不会让应用自行给出“现在补一片”或“双倍服用”等临床建议，而是把具体处置交给处方说明、药师或医疗专业人员。
最后看候选人能否形成产品闭环：从真实场景研究，到状态模型、MVP、明确不做项，再到用户结果指标和安全护栏。功能上线、通知打开或“已服用”按钮点击量都不是充分成功标准。
回答前需要澄清的问题
- 主要用户、付款者和照护者分别是谁？ 若老年人自主使用，控制权和可理解性优先；若子女购买但本人使用，仍不能默认把全部数据开放给子女；若机构负责用药，产品会转向任务分派、审计和专业流程。
- 用药计划从哪里来，谁负责更新？ 手工输入、扫描标签、药房导入和医疗系统同步的错误风险不同。首版若只支持手工输入，就必须要求用户或受信任人员核对名称、剂量、用途、时间和特别说明，并清楚显示最后更新时间。
- “漏服”在产品中如何定义？ 提醒后 10 分钟未响应、超过计划时间窗口，和用户主动选择“跳过”是三种状态。阈值必须允许个性化，产品不能把未点击直接断言为未服药。
- 哪些药物和风险在范围内？ 若某类药物的时间窗或漏服处置风险很高，纯软件提醒可能不够，应先由临床、药房和合规人员定义流程，或把该类用户排除在试点之外。
- 照护者能看到什么、何时收到通知？ 只看未响应状态、查看完整药物清单、代为修改计划和联系用户是不同权限。授权对象、字段、时间范围、撤销方式和紧急情况规则会改变产品设计。
- 用户常用什么设备和提醒方式？ 只有智能手机、同时使用手表或家中音箱、网络不稳定，以及视力、听力、手部操作能力不同，都会改变通知通道与交互。
- 成功目标是什么？ 首轮可以验证“用户能否正确设置并及时自我确认”，不能仅凭自报数据宣称降低医疗风险或改善临床结局。
30 秒回答框架
“我会先把首要用户限定为能自主用药、会使用智能手机、但偶尔因忘记而漏服的独居老人，不覆盖严重认知障碍或需要实时临床监测的人。先通过在家访谈和任务观察区分忘记、看不清、计划错误与主动停药；首版只解决忘记和计划管理。MVP 保存经核对的药物清单，在三个计划时段用可个性化的声音、震动和大字提醒，让用户选择已服用、稍后提醒或跳过；未响应超过本人设置的时间窗后，才在明确授权下通知照护者。应用不建议补服或改剂量。先用原型验证设置与确认流程，再做有限试点；主指标看计划时段内的及时自我确认率，护栏看错误计划、重复确认、误操作撤销、通知关闭、求助和隐私投诉。”
这段骨架先锁定用户与边界，再说明研究、MVP、风险和验证。完整回答需要解释为什么选择这类用户、每个状态如何转移，以及指标能证明什么、不能证明什么。
分步骤深入解答
第一步：把目标写成用户结果和产品边界
目标可以写成：“帮助仍能自主用药的独居老人，以更低认知负担记住计划、确认自己的操作，并在需要时主动获得帮助。”这里有三个刻意限制：
- “自主用药”排除了需要持续监督或代为发药的人；
- “确认自己的操作”说明记录来自用户自报，不等于产品观察到吞服；
- “主动获得帮助”保留本人控制权，不默认把照护者变成监控者。
产品不应把“提高依从性”直接写成已经证明的效果。临床依从性还受副作用、费用、理解、生活安排和治疗意愿影响。首版能测的是设置是否正确、提醒是否可理解、用户是否在约定窗口内作出可信的自我报告，以及升级流程是否按授权工作。
第二步：选择首要用户，并明确暂不服务谁
可以先列三组人：
- A 组： 能独立管理药物，但偶尔忘记或混淆时段；
- B 组： 大部分时间能自主完成，需要家人远程协助；
- C 组： 存在严重认知、视觉或动作障碍，需要照护者或设备直接管理。
首版选择 A 组，并给 B 组提供可选、受限的照护协作。原因是软件提醒和简化交互能够直接作用于 A 组的问题，用户本人也有能力核对和撤销操作。C 组的核心问题不是提醒界面，可能需要锁定式药盒、专业照护、线下核验和更严格的责任边界；硬塞进同一个 MVP 会制造安全假象。
“老年人”还需要继续按用药复杂度、数字熟练度、感官和动作能力、是否独居、是否有可信照护者切分。首版画像只是进入研究的假设，不能代替真实用户。
第三步：在真实环境中找出漏服链路
先与目标用户在他们实际整理药物的环境中访谈和观察，同时征得同意后分别访谈照护者、药师或相关专业人员。访谈从日常习惯开始：药放在哪里、用什么判断时间、外出时怎么办、计划改变后谁更新、忘记时如何处理。不要只问“你想要什么功能”，还要观察标签是否易读、药盒是否相似、手机是否静音、提醒是否与吃饭或睡觉等习惯绑定。
把发现放进一条任务链：
取得最新计划 → 辨认药物 → 到时收到提示 → 决定并执行 → 记录状态 → 异常时求助 → 计划变化后更新
每个断点对应不同解法。若用户根本没有可信的最新计划，提醒得再准也会放大错误；若用户担心副作用而主动跳过，问题需要医疗沟通；若只是在做饭时没听到声音，才可能通过多通道和稍后提醒改善。
研究结束时不应得到一张功能愿望清单，而应得到可排序的问题陈述。例如：“自主用药的独居用户在忙碌或离家时错过一个计划时段，之后无法确定自己是忘记了还是已经服过，因此可能继续等待、重复操作或向家人求助。”
第四步：用状态模型避免把通知当成结果
每个计划用药事件至少经过这些状态：
已计划 → 到时 → 已提醒 → 已服用 / 稍后提醒 / 跳过 / 未响应 → 已解决或升级求助
“已提醒”只说明系统尝试通知；“已服用”是用户自报；“未响应”也不能自动等于漏服。每个状态都要保留时间、计划版本和操作者，允许短时间撤销误触。计划被修改时，旧事件不能继续按过期剂量提醒，新计划还应显示生效时间和核对来源。
这个模型也决定照护者逻辑。只有事件进入“未响应且超过用户设置的时间窗”，并且本人已授权对应照护者与通知范围时，系统才发送升级信息。照护者收到的是“尚未确认，请联系本人”，不能收到“患者一定漏服，请让他立即补服”。
第五步：从三个方案中选出 MVP
可以比较三条路径：
- 纯提醒清单： 成本低、上线快，但无法处理不确定状态、计划版本和求助；
- 带确认与授权协作的软件产品： 能覆盖首要链路，仍依赖用户自报；
- 联网药盒或药房深度集成： 能获得更强的发药或计划证据，但硬件、覆盖、运营和责任显著增加。
首版选择第二条，同时把范围压到一条可验证链路：
- 建立药物清单，至少保存名称、规格、用途、服用说明、计划时段、信息来源和最后核对时间；
- 用户完成或请受信任人员协助核对后，计划才可启用；
- 到时使用大字、高对比度、非颜色唯一提示，并允许用户选择声音、震动和提醒节奏；
- 单次事件只提供“已服用”“稍后提醒”“跳过”三个主要动作，并支持撤销；
- 用户不确定或选择跳过时，显示事先保存的专业求助方式，不自行生成补服建议；
- 未响应超过个性化时间窗后，按授权通知照护者；
- 用户可以暂停、修改和撤销照护权限，所有变化都有清楚记录。
首版不做拍照识药、自动推断剂量、开放式 AI 医疗建议、全量医院集成和联网药盒。它们可能有价值，但会引入新的准确性、合规、设备和运营未知项，无法帮助最小试点先回答“简单软件流程能否被正确理解和持续使用”。
第六步：把安全、可访问性与隐私变成产品规则
安全规则应直接进入交互：
- 用户标记“已服用”后又不确定，允许撤销并显示联系药师或医疗专业人员的方式；产品不判断是否再服一次；
- 计划变更必须明确谁修改、何时生效、由谁核对；旧提醒立即失效；
- 同一事件的重复确认要提示并记录，不能创建两次“已服用”；
- 用药清单应同时包含处方药、非处方药、维生素和补充剂，便于用户维护完整记录，但产品仍不自行判断相互作用；
- 跨时区旅行或夏令时变化时，先要求用户确认计划按当地时间还是原时区执行，不静默移动高风险时段。
可访问性不能只写“字体放大”。年龄相关变化可能影响视觉对比、精细操作、听力、短时记忆和注意力，因此首版需要大触控区域、清楚层级、简短文字、声音与震动组合、屏幕阅读支持，以及由用户选择提醒方式和数量。颜色只能辅助状态，不能作为唯一差异。
隐私采用最小授权：本人逐个选择照护者、可见字段和通知类型；默认不共享完整药物清单；授权可以随时撤销；照护者不能在没有额外确认的情况下更改计划。若用户没有授权照护者，产品应停留在本人提醒和专业求助入口，不能为了“安全”绕过同意。
第七步：分阶段验证，而不是直接看留存
第一阶段用可点击原型完成任务测试：用户能否建立 4 种药物、设置 3 个时段、理解三个动作、撤销误触、找到求助和撤销照护权限。观察实际完成过程，不用“你觉得好用吗”代替。
第二阶段做有限时间的真实提醒试点。主指标是有效计划事件中，用户在自己设定的时间窗内完成自我确认的比例。它是流程代理指标，不是临床服药证明。再看：
- 计划建立后经核对并成功启用的比例；
- 未响应事件中，用户本人或授权照护者最终解决的比例；
- 用户需要多少次提醒才响应，以及“稍后提醒”的使用情况；
- 用户是否能在处方变化后及时更新计划。
安全与体验护栏包括：错误计划被启用、重复确认、短时间内撤销“已服用”、用户报告不确定是否重复服药、通知被系统级关闭、退出照护共享、隐私投诉和求助量。任何严重安全事件都应触发暂停和复盘，不能等主指标汇总后再处理。
只有当原型任务完成、试点使用可持续、主指标改善且护栏没有越界时，才扩大人群或研究药房导入、智能药盒和更复杂的照护协作。若提醒被频繁关闭，应先判断是通道、频率还是问题本身不适合提醒解决，不能简单增加通知。
高质量示范回答
“我先限定首要用户：能自主用药、会使用智能手机、独居且偶尔因为忘记而漏服的老年人。练习场景中，他长期服用 4 种药，每天有 3 个计划时段。严重认知障碍、需要实时临床监测或由照护者直接发药的人不进入首版，因为他们需要的是更强的照护或硬件流程。
我不会一开始就画提醒页面。先在用户整理药物的真实环境中访谈和观察，区分四类问题：有没有可信的最新计划、能否辨认药物、到时是否能收到提醒，以及漏掉后是否知道下一步。若用户因为副作用或费用主动停药，提醒不是答案，需要转向专业沟通。
MVP 会保存经用户或受信任人员核对的药物清单，包括名称、规格、用途、服用说明、时段、来源和最后核对时间。到时用大字、高对比度、声音和震动提醒，用户只能选择已服用、稍后提醒或跳过，并能撤销误触。选择跳过、表示不确定或错过时间窗时，产品只提供预先保存的药师或医疗专业人员联系方式，不建议补服或改变剂量。
照护协作默认关闭。用户可以授权某位照护者只在未响应超过自定时间窗后收到通知，也可以选择是否共享药物清单。照护者看到的是‘尚未确认，请联系本人’，不能代替产品下临床结论，也不能默认修改计划。
我会先用原型测试用户能否正确建立 4 种药物、设置 3 个时段、理解三个状态、撤销误触和收回授权。之后做有限试点，主指标看有效计划事件在个性化窗口内的及时自我确认率；同时看错误计划、重复确认、短时间撤销、通知关闭、用户求助和隐私投诉。这个指标只能证明流程是否帮助用户记住并记录，不能证明药物已经吞服或临床结局改善。
如果及时确认改善、用户愿意持续使用且安全护栏没有越界，我再研究药房导入和联网药盒。若用户频繁关闭提醒，或主要问题来自副作用、费用和计划不可信，我会停止扩大发送通知，回到问题定义，而不是把提醒做得更响。”
这段回答的关键是把产品目标、临床边界、用户控制权和验证证据连在一起。面试官改变人群或风险时，方案也应随之改变。
常见错误
- 把所有老年人当成同一用户 → 自主使用、远程协助和专业照护的需求冲突 → 选择一个首要人群，并明确排除条件与后续人群。
- 直接提出闹钟、语音和大字体 → 还不知道问题是忘记、看不清、计划错误还是主动停药 → 先画任务链并为每个断点建立证据。
- 把“已送达通知”写成“已服药” → 系统能力被夸大，指标和安全判断都会失真 → 区分送达、用户操作、自我报告和临床事实。
- 让应用告诉用户漏服后补一片 → 不同药物和处方的处置不同，产品越过临床边界 → 显示已核对说明和专业求助入口，不自行生成剂量建议。
- 默认把全部数据给子女 → 付款或亲属关系不等于持续授权 → 由本人选择照护者、字段、通知和撤销方式。
- 第一版同时做医院集成、AI 识药和智能药盒 → 无法判断哪项解决了问题，且引入多重准确性与运营风险 → 用软件状态链先验证最关键假设。
- 只看日活、点击率和通知打开率 → 用户可能被迫点开，却没有更安全或更确定地完成任务 → 使用及时自我确认等结果代理指标，并配置安全、体验与隐私护栏。
- 看到提醒关闭就增加通知频率 → 通知疲劳会进一步降低可用性，也可能说明根因不是忘记 → 检查用户分群、时间窗、通道和漏服原因，再决定迭代或停止。
- 用一次访谈代替验证 → 口头偏好无法证明用户能正确设置和长期使用 → 先做任务测试，再进行有限真实试点。
追问及应对
追问一：如果子女付费，为什么不能默认看到全部用药记录？
付款者、用户和数据主体可能不是同一个人。默认全量共享会削弱本人控制权，还可能让用户拒绝使用或隐瞒状态。产品应让本人逐项授权照护者、可见字段和通知条件；若法律或监护关系改变权限，则需要单独的身份与合规流程，不能由“子女付费”推导。
追问二：如果某种药漏服会带来严重后果，MVP 还够吗？
先把这类药物排除在普通试点之外，由临床、药房和合规人员定义时间窗、升级与责任。可能需要药房导入、联网药盒、电话确认或专业人员介入。高风险场景的强证据和可靠升级优先于扩大用户量，纯自报软件不能伪装成实时监测。
追问三：用户点了“已服用”，几分钟后说自己不确定怎么办？
允许撤销并保留审计记录，立即显示处方中已核对的求助信息或联系药师、医疗专业人员的入口。产品不根据时间差自行建议再服一片，也不删除先前记录。这个场景还应计入安全护栏，用于判断确认按钮是否容易误触或信息是否不足。
追问四：用户跨时区旅行，提醒应该自动切换吗？
不能静默移动全部时段。产品应检测时区变化，展示原计划与当地时间的差异，请用户依据专业说明选择维持原时区还是转换，并记录生效时间。若用户无法确定，就引导联系药师或医疗专业人员；高风险药物应使用预先定义的旅行方案。
追问五：及时自我确认率提高，但用户大量关闭通知，算成功吗？
先检查分母是否只剩最积极的用户。通知关闭属于体验护栏，也可能造成幸存者偏差。按用户群、提醒次数和使用周期分析；若关闭率超过预设边界，即使剩余用户的确认率提高，也应暂停扩大范围，调整频率、通道或目标人群后重测。
追问六：研究发现很多人是因为副作用或费用主动少服，产品怎么改？
把这类用户从“忘记提醒”问题中分离。产品可以帮助记录原因、整理问题并连接药师、医生或费用支持资源，但不能用更多提醒逼迫服药，也不能自行更改处方。若主动停药是主要原因，路线图应从提醒工具转向沟通与支持流程，原 MVP 的优先级会下降。