以模拟C端项目“医疗魔方”为例，剖析产品设计流程

本文以一个模拟的C端项目——医疗魔方为例，分析了其中的设计流程与思路。

一、前言及说明

1. 团队现状

由于所在的事业群性质，设计团队对接了集团大部分的界面设计需求，有B端也有C端。通常一位设计师要对接好几个项目，因此要求每位设计师都有独立负责项目的能力。综合情况来看，每位设计师都有擅长的领域，也各自有不同的短板。

2. 训练目的

本次训练目的主要有以下几点：

1. 明确在PMF之前的项目应采用的设计思路；
2. 为设计注入增长思维；
3. 平衡设计与商业之间的关系，优先考虑商业需要，对产品要有全局思维；
4. 建立有效的用户画像。

3. 项目简述

本项目名为“医疗魔方”，是我为了这次训练而模拟出来的C端项目。

“医疗魔方”是一款为长期慢病患者管理个人病历的工具型产品。具体的产品分析会在原型阶段体现，此处不作详述。

即便很多研究报告描述智慧医疗有多么智能，但在一线城市看三甲医院的我们，仍然感觉落不到实处。目前只做到了单个医院的智能，但是多方打通还做不到。

假设智慧医疗头部企业最终能够让所有医院的电子病历打通，“医疗魔方”就有可能活不下去。而我仍然选择用这个项目来做设计训练，是因为这符合了大多数公司的现状。大公司的小项目也好，小的创业公司也好，由于对市场不完全了解，只能通过调研报告或其他途径，感知到机会，想抓住机会，创造产品放到市场上试验。

作为设计师，接触到这类型的项目是非常多的。

面对这个阶段的产品，我们应该怎么做？

这是这次训练我们需要探讨的问题。

另，在做项目时，由于我们接触的主流APP都是比较成熟的产品，功能齐全丰富。有些设计师在做项目竞品分析的时候，会想当然地为项目添加功能，跟产品讨论现在加这个功能会不会更好；或者试图去纠正产品或者老板的想法，认为自己的想法才是对的。但是并不去考虑增加功能后整个项目的工期是否需要延长、自己所认为对的想法是否适合公司当前的情况，缺乏全局思维。

这一点需要着重强调：在合适的时间做正确的事情，一切对错交给市场验证，用数据说话，错了就改，小步迭代。

最后重申：请留意设计流程和思路，勿将重点放在深究商业创意上。

3. 版权说明

本项目版权归属本人，提供部分原型图给大家做练习，但不提供文档说明。请勿商用。

后续展示的设计稿，版权归属于该设计稿的作者，文中会标明作者名字，请勿商用。

二、项目背景

1. 全球医疗困境

2. 中国特色困境

3. 分级诊疗推行中遇到的问题

4. 大数据在健康医疗行业中的应用价值

三、商业洞察

以上项目背景中，我关注到两点：

1. 上下级医院连接困难、电子病历难以共享。
2. 在线问诊的产品中体验过平安医生、快速问医生，发现要提供检查单提升问诊准确度。

医院连接困难、电子病历难以共享的原因在于利益与技术的问题。由于涉及医院比较看重的患者就诊信息，并且当所有医院的信息打通后，患者掌握数据进行对比，很容易跟医院打官司，医院需要承担责任。

提供智慧医疗的机构中，以网易云信为例，他们方案的适配场景是医疗智慧协同、远程医疗、医学教育等，多学科多院方联合在线会诊，以音视频通话、图片、文字、文档共享等形式进行信息互动与数据共享。虽然出发点是为了提升用户的医疗体验，打通医疗体系，但是这种方式没有切实去解决用户现实中存在的困难。以下几点值得思考：

1. 由古至今，望闻问切都是医生与患者面对面，患者与医生面诊的时候更有安全感；
2. 医院的挂号费比APP的服务费更便宜；
3. 医疗保险在医院使用才能报销。

综合所有的数据，我洞察到这样一个机会：各大医院的病历不一，系统没有打通，在其他医院看的结果不被认可，需要重新检查。跨医院看病时，历史病历是纸质样式，或只有其他医院系统的电子版，医生查阅困难，分析需要花费时间，不直观。

如果以“给患者提供智能病历分析的功能，由患者拍照上传病历和检查单，系统识别里面的字段和数据，自动生成病历分析”这个较为亲民的方案，先解决患者纸质病历难以管理的问题，使患者养成习惯，并根据其过往病历综合分析，提供有效的疾病风险评估、医疗建议和指数监测服务，再推行其他医疗服务，是否能够对智慧医疗有所帮助呢？

针对这一点，我研究了平安医生、阿里健康、网易云信、病历夹、微医、好大夫、妙健康、春雨医生、用药助手、丁香医生等平台，发现他们的功能集中于：预约挂号，问诊、资讯、知识、社区、名医讲堂、医生管理病历等。就算有患者的病历管理，也是要手动输入文字，非常麻烦，没有一个软件从患者的病历管理入手。

（编辑：焦作站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!