产品说明文档的形式其实早就该改革了。有人说干脆放弃产品说明文档。虽然这样做用存在一些问题，但我认为他们的方向没错。

先来看看现今产品说明文档存在的问题。产品说明文档包含的范围很广，名称五花八门，有产品需求文档、市场需求文档、业务需求文档、功能规格书等等。内容覆盖范围、详细程度、文档本身的质量差别很大，就连形式也变化多端，有的是 Word 文档，有的是电子表格，还有的是用专业需求管理工具生成的。这些不同的文档本来作用各不相同，但是随着时间流逝，彼此间的界线越来越模糊。

大部分产品说明文档既没有提供必要的细节，也不包含关键信息，不能很好的解决问题，虽然花费了大量时间撰写，却很少有人阅读。对管理层和产品团队来说，产品说明文档很容易成为个幌子，仿佛一切都进展顺利。

产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档。认同这一点的人只要仔细审视产品是如何定义的，就不得不承认现有产品说明文档存在不足之处。

我认为理想的产品说明文档应该满足以下要求。

1.产品说明文档应该完整地描述用户体验一不只是用户需求，还包括交互设计和视觉设计。希望大家已经明白用户需求和用户体验是密不可分的。

2.产品说明文档必须准确地描述软件的行为，文字和图片的表达能力实在有限，不足以完成这项任务。

3.产品说明文档的受众较广---  开发人员、 测试人员、市场营销人员、运维人员、销售人员管理层等等。因此，产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。

4.产品说明文档应该可以修改，虽然进入开发阶段后，应该尽量避修改产品说明文档，但总有意想不到的问题，需要修改产品说明文档以适应新情况。

5掼写产品说明文档的过程中会出现许多衍生物，比如，按优先级排列的需求列表、线框图、实体模型，  但应该有一个主体来代表产品，避免混淆不清，版本错乱。

只有一种形式的产品说明文档可以满足以上所有要求，那就是高保真产品原型。

“高保真”的含义是原型应该真实地体现用户体验。除了描绘用户界面的某些细微之处以外，我不建议使用“纸上原型”。如今使用工具创建高保真原型既简单又快捷，成本也不高，没理由不这么做。为了获得接近真实的用户体验，甚至应该模拟后台处理流程和某些数据。

随着各类辅助工具的出现，现在原型基本上都可以体现产品细节一包括所有的页面和主要的用例。尽管还是会出现些意想不到的错误和极端状况，但原型毕竟能让产品团队更直观地把握设计要求，其优势完全可以弥补增加的成本。

当然仅仅有原型是不够的，因为有些产品行为不容易用原型体现，比如业务逻辑(税务表单和运费等)、发布要求(性能表现、可靠性、扩展性等)、平台交付要求(安装要求、浏览器兼容性等)。用例可以作为有效的补充，用来描述重要的产品行为。

另外，如何展示补充的说明不过这种技术还没有实现，退而求其文档也值得考虑。最理想的方原型上增加注释，在线的文档比较方便，能保存说明文档的更新情况，方便大家提问和可以定期通知大家产品讨论，并保存所有决策记录。

高保真原型最突出的优势是可以用于测试。你可以把它放到真实用户面前，观察他们是否清楚如何使用(可用性)，是否渴望使用你的产品(价值)。只有通过这两项测试，产品说明文档才算合格，产品才值得开发。

开发人员是最直接的受益者，因为他们终于看到了明确有效的产品说明，遇到不清楚的地方，随时可以参考。测试部门的工作也变得容易了，因为他们终于知道什么样的测试结果是正常的。部门和客服部门也会很高兴提前了解产品。  市场部门、销售产品原型远比 PPT 来得有效。种做法。因为向投资者、董事会成员和商业伙伴管理层也会支持这展示产品时，高保真原型的优势还不止于此。

使用高保真原型可以大大缩短产品上市，因为传统的产品说明文档统(不完整、含糊不清，特别是未经测试)，几乎没有确定关键细节，也不解决实际困难，必须等到开发阶段这些问题才能得到解决。这导致项目要么被迫反复调整(产品说明文档不断变更，造成项目延期、士气低落)，要么开发人员只能凭空猜测，交付的产品团糟，用户不得不等待下一个版本或多个补丁发布后才能使用。无论哪种情况，产品上市的时间都将推迟。

所以我建议大家尝试高保真原型，与其花几个星期撰写冗长的 Word 文档，既没人读，也无法测试，还不如和设计师一起创建产品原型。把产品原型拿给团队检查，交给目标用户测试。也许要反复修改多次才能确定原型，但现在修改总比开发几个月做出糟糕的产品强。

Powered by Froala Editor