他们把临床软件压缩到20秒，却拯救了200万印度患者

在印度的基层诊所里，医生给每位病人的时间只有2分钟。这场分享最反直觉的观点是：好软件不是更强大，而是“几乎不存在”。Figma Config 2022 上，两位设计师讲述了如何用20秒的软件设计，撬动一个国家级公共卫生系统。

没人关心你的软件，这句话在印度是真的

如果你做 AI、做产品，大概率听过一句话：用户体验很重要。但在印度的公共医疗系统里，这句话要被翻译成一个更残酷的版本——“请你不要让我更忙”。Daniel Burka 和 Mahima Chandak 在田野调查中得到一个高度一致的反馈：医护人员每天要面对上百名患者，他们来上班不是为了用软件，而是为了救人。

在旁遮普的公立医院，一名护士平均每天要处理约100名患者。量血压、开药、做生活方式咨询、手写登记、再把病人送去医生那儿——每个环节都挤在极短的时间里。在这种环境下，任何多余一步操作，都是对患者时间的掠夺。

于是他们提出一个听起来几乎“反产品经理”的结论：“No one cares about your software.” 真正的目标不是让用户喜欢你的界面，而是让软件彻底隐身，成为工作流的一部分。这一判断，决定了 Simple 这个项目之后的所有设计选择。

20秒 KPI：把设计目标定到“近乎不可能”

大多数团队先做功能，再想指标；Simple 则反过来。项目一开始，他们就设定了一个极端 KPI：在印度，典型的临床问诊只有2到4分钟，软件最多只能占用其中20秒。

这个数字并非拍脑袋——20秒已经相当于一次就诊时间的六分之一。换句话说，如果你的系统慢一点，患者就可能少说一句关键信息。

这也让很多“看起来很合理”的功能直接被砍掉。没有复杂表单，没有层层确认。团队用元数据持续追踪真实使用情况，结果是：今天，随访登记的中位时间是14秒，新患者建档也只需1分钟多一点。这不是设计美学的胜利，而是对现实约束的极端尊重。

对 AI 从业者来说，这里有个重要启示：当模型、系统被部署到真实世界，KPI 必须来自现场，而不是来自白板。

真正的难题不在界面，而在“水面之下”

Burka 用了一个非常有力量的比喻：公共卫生项目像一座冰山，软件只是露出水面的那一小块。如果下面的治疗流程、用药方案、本地协作机制是混乱的，再漂亮的界面也救不了你。

所以他们做了一件不那么“设计师”的事——深度参与公共卫生体系设计。与前 CDC 主任 Tom Frieden、印度卫生部门、本地组织一起，把复杂的高血压管理，压缩成“简单到可以规模化”的方案：统一的治疗路径、简化的药品采购、清晰的诊所工作流、以及极少但关键的指标。

只有当底层系统被简化，软件层面的“简单”才成立。这一点对 AI 产品尤其重要：如果你试图用一个模型去覆盖混乱流程，最后只会得到一个放大混乱的 AI。

几个“不像设计”的细节，决定了能不能活下来

真正落到软件层面，Simple 的设计选择看起来几乎不起眼，但每一个都直指效率。

例如血压录入界面。血压有收缩压和舒张压两个数字，他们根据常见数字位数，自动在输入框之间跳转。这不是视觉设计，却显著减少了操作时间和错误率。

再比如搜索。电子搜索本应比纸质快，但在印度，很多患者同名同村、没有身份证号，“搜索”反而可能更慢。解决方案不是更聪明的算法，而是服务设计：为患者发放带二维码的卡片，一扫即得完整档案。这张卡片还能在护士、医生、药房、不同诊所之间流转。

最终的结果是规模化：从旁遮普一个邦，扩展到印度17个邦，以及斯里兰卡、孟加拉国、埃塞俄比亚，累计注册患者超过200万。

总结

Simple 的故事给 AI 和产品从业者一个不太舒服、但极其重要的提醒：真正伟大的系统，往往不是更“智能”，而是更“克制”。当你面对高压、低资源、真实后果的场景时，成功不取决于你能做多少，而取决于你能删到什么程度。

如果你正在设计 AI 工具，不妨问自己三个问题：第一，用户一天最忙的时候，你的产品会不会让他更忙？第二，你的 KPI 是不是来自真实现场？第三，如果底层流程不合理，你是不是在试图用技术硬扛？

也许，下一个真正改变世界的 AI 产品，看起来会“简单得不像 AI”。

关键词： 医疗设计， 公共卫生， Simple应用， 以用户为中心设计， AI产品思维

事实核查备注： 需要核查：1）印度典型临床问诊时间为2-4分钟；2）Bangladesh 约2分钟；3）随访登记中位时间14秒、新患者注册约1分钟；4）项目扩展到17个印度邦及斯里兰卡、孟加拉国、埃塞俄比亚；5）累计注册患者数约200万；6）Tom Frieden 身份为前 CDC 主任