我的知识库

产业成熟 → 细致分工 → 固化流程 → 原型+文档交付 → 产品管理

大家都已经意识到了文档不足的问题，其实完全可以参考软件工程的项目管理。有机会同几位工程师讨论，看了推荐的信息，发现产品文档和开发文档很相似，都是系统工程思想的应用。

实施必要性

产品只要不倒闭都是长期的，人员来来往往，环境特别复杂，而每个产品又只是更大产品的一部分。当新人进来时，很难指望同事通通讲一遍，只有通过阅读大量文档来了解产品历史和现状。

讨论和面谈的确是性价比极高的方式，如果公司人员稳定、项目组内部团结、设计开发能力强、规范和习惯统一、项目规模不大，不写文档问题不大，关键是国内有多少公司满足这些条件？

应该包含的内容

至少应该分演示和技术两种，演示给用的人看，技术给做的人看。都应该以设计传达为出发点，主要是逻辑和关系说明，除了文字图片，还应该包括概念图、结构图、流程图等。

演示部分，就是曾经提到的产品原型文档，后续流程都应该以此为准。曾经某公司QA同事，要求我们设计的数据展示表格必须严格按照PRD的字段描述，每个字段一列呈现，实在无语。

1. 用户角色，典型用户群代表的描述。
2. 原型结构，信息可视化说明。
3. 交互流程，功能块的逻辑展示。
4. 任务分解，项目管理中用户故事、测试用例、Test case差不多的意思。

技术部分，暂时还没有完整实施经验。

1. 代码框架逻辑，页面呈现的结构搭建。
2. 代码解决方案，功能难点的攻关。

文档协作模式

与其去花一个小时写文档和其它人花半个小时读文档，真不如坐下来面对面的谈上15分钟有效，这个也是很多人不愿意写和看文档的原因。有时候明明写了文档，同事确实不愿意看，还是跑过来要你手把手演示讲解，非常打击写文档的积极性。

文档维护是件代价很高的事情，不同步的文档比没有文档更加麻烦，因为它有误导作用，使别人在自以为正确的基础上，作一些很可能没有意义的事情。

Less document is better

不需要涉及过多的细节，细节性的东西原型已经表达了。文档是原型的一种补充，只突出重点。文档作为一种索引，在需要了解细节时，可以快速定位至原型相关位置。

文档的目地是减少重复沟通，但文档又没有智商。所以，在频繁的反馈之后再写的文档，一定比一开始就写的文档准确易懂。

价值体现

做原型的能力，在公司里面不容易体现出来，因为一般没人去看代码抠细节，只有等你走了之后，维护的人才会去仔细分析，因为做得好他受益。写文档的能力，就不一样，你上面的人及你的合作同事基本上都会看到。

另外，如果打算换工作，给将来的领导看啥？那些土了吧唧的页面原型还是几百上千行的代码？人家可没这么多时间来一个个详细理解，而且时间一久，恐怕自己都说不清楚。

总有人在背后鄙视产品太烂，说某些人光说不做。你可能不知道产品方除了要顶住上边压力，还需要项目方来支持落实，其实是很弱势和尴尬的地位。都知道最终用户看到的是产品设计，而不关心实现技术，但又有多少公司能保证对产品方的绝对支持？怎么能凡事都让设计师买单呢？

如何量化产品设计师的价值？很简单：原型+文档！