关于前段时间工作中遇到的产品改版，结合改版厌恶梳理全过程的卡点。伴随着用户的初始、习惯、精通，直到产品“1.∞”的生命周期完结，产品经历了从验证期、过渡期、爆发期再到平台期的全过程，产品的功能模块也逐步得到了完善。业务方向也刚步入稳定期，在具备了一定量的内容和数据积累后，大家一致决定是时候推进“2.0”了。

01. 改版驱动

与“0-1”的产品不同，销售主导下清晰的业务主线，明确的用户人群和定位，固定的使用场景...这些条件和约束能推动产品往更有深度的方向延伸。

为什么是“1.∞-2.0”而不是“1.0-1.∞”？在经过需求池的梳理之后，我们发现以下的问题： 改版驱动.jpg

• 尽管产品上线后，在某些功能上多次的迭代只是将口头需求叠加，零碎的构建使得产品版块分层有重叠部分出现不够整体化，后期维护成本高；
• 初期研发阶段，产品的设计者与研发执行者之间理解的偏差，使得当前阶段的某些需求盘根错节，积重难返；
• 上线后收集到定量的用户反馈数据，结合落地场景后的深入分析，发现有些需求的深度不够；
• 销售数据的反馈，产品的复购率低，需要从体验层紧抓用户。

经过各部门的讨论之后一致认为，与其不断的补缀还不如大刀阔斧地整体解决，合理排期后开始了这次从“1.∞-2.0”的改版。

02. 明确改版初衷

选用“整体性分析”方法，分析用户对产品的全阶段接受过程。我们的服务对象主要是三甲、二甲、专科医院，是对接于HIS系统下的集合CIS电子病例、检验系统的B端医疗产品。采购方通常为医院某定向科室的管理人员，真实用户为一线实操的医护人员；为保障医院网络信息的安全和稳定运行，产品通常进行院方本地部署，于是产品的初期上线与后期的更新迭代需要院方信息科的人员进行配合（一定程度提高了迭代的沟通成本）。 相关人员.jpg

• 销售驱动

  • 通过分析角色的阶段变化可以了解到，提高复购率和NPS值（净推荐值）的关键点在于提升用户体验。在产品满足用户业务效率需求的基础上，通过提升用户的产品体验来助力解决业务问题、促进产品优化升级、赋能科室降本增效。 阶段角色变化.jpg

• 需求驱动

  • 深入业务场景进行实地调研，挖掘到更细分的用户需求。B端产品侧重于将用户的行为表现及态度反馈转化为对业务的影响，有的时候用户反馈的需求是由其自身业务熟练度造成的，而并非产品设计的问题。降低用户学习成本，提供适当的引导和操作文档，以提高产品易学性。

• bug驱动

  • 1.0版本上线时，产品的专业性处于标准且待提升状态，随着用户量的不断增多，收集到的专业方面建议也逐渐多样化。从最初的各地区保持同一版本的内容库（统一性），到后期依据各地区的使用特性分开迭代（差异性）。然而在产品“1.0-1.∞”不断满足用户差异性需求的迭代过程中，没有彻底梳理清各版本的内容区别、关系，研发执行时误差率较高，以至于用户抱怨产品不可用、不好用的情况频繁出现。

03. 改版注意事项

• 建议使用可配置型的组件化设计来提升工作效率。设计的复用、开发的复用、用户体验的复用。复用可以在产品的迭代过程、用户体验的提升等多方面提高效率，避免用户因产品同类功能的操作不一致而降低使用体验，而且后期组件可以同步迭代更新。
• 改版中合理利用“1.∞”版本中可复用的部分，在达到产品目标的下，考虑改版的实现成本，尽可能多复用现有的产品框架，可通过多个局部处理来实现优化目标。
• 对于异地用户，需要对方医院信息科协助远程部署，使得沟通成本增高而更新效率不够及时。严格做好版本管理，确保2.0产品上线前的可用性。