规范
首先我们应该了解，规范的文档撰写源于规范的流程（我已经在流程篇中向你介绍过），因我们在流程中做的大部分事情，都会有相对应的工作“产出”，这些产出可以统一被称为“文档”。
策划前期
l
BRD是一个在企业商业战略层面撰写的文档，在文档中分析大环境和市场前景，得出产品的商业目标，并核算投入产出等。对于小团队而言……好吧，我认为这篇文档的实用价值不太大。
1．
2．
3．
4．
5．
6．
嘿~你在我的文件夹中找不到这篇文档，它的所有内容都在boss的脑子里。
策划中期（产品目标、用户需求、内容与功能需求）
l
这篇文档说明“怎么做产品”，以达到（BRD中的）商业目标。它会是未来所有文档的参考源头。
1.
a)
b)
2.
a)
b)
c)
我们（企业要从这个产品中得到什么）
3.
a)
b)
c)
假设真实存在的一个用户Gara，为他设计年龄性别、生日、收入职业、居住地、爱好、性格等
根据他的背景推理他的技能情况（熟练使用电脑办公等）
推理与产品相关的特征（使用微信，单身，喜欢皮肤白长头发的女孩子）
d)
如何使用我们的产品，讲一个完整的故事（时间、地点、人物、任务等）。
周五下班途中，在公交车上，无聊又寂寞的Gara打开了微信看看周围有美女在线，加了对方好友，快乐地聊起来……
a)
用户需求：在旅途中方便地充电
用户的真实需求：手机电池更耐用
b)
不仅要罗列因素，还要详细分析这些因素如何影响用户使用产品的过程。
a)
简单描述用户群体
b)
我们将用什么样的产品满足用户需求
c)
我们的目标用户要从这个产品中得到什么
产品帮助用户解决什么问题
d)
我们需要哪些类型的内容
我们需要怎么样的功能去支撑这些内容
5.
成功标准：了解我们的开发过程，知道我们什么时候到达终点
设定一些可追踪的指标，一般会以项目甘特图的形式体现，包含时间、任务、说明等内容
BRD：嗨~为了放松心情~我们出去玩吧~
MRD：那我们就来商量下去哪里玩，几个人，完成什么任务，空出多少时间，准备多少钱…
B、M：小P快去干活！
策划后期（界面交互与设计、信息架构、布局与导航设计）
l
有时候也叫做产品说明书，最细致也最繁琐的文档，开工之前一定要深呼吸，摆好姿势。这个文档会是所有项目成员做事的直接依据，描述要低调肤浅简单粗暴，这样大家才能愉快滴继续玩耍。
1.
2.
a)
b)
如果可能，我们也可以为后台功能做命名。这样前台语言是给用户看的，后台语言是给我们自己看的，把两者对应起来以防错误。这样程序员的沟通压力就不会太大（设计人员更加喜欢使用用户语言，导致程序员的理解困难）。
c)
3.
a)
b)
4.
全局是指可以被套用在大部分的页面或操作中的一些通用的规则，如果某个内容或功能与全局情况不同，就在细化中再进行描述。
以下举例两种全局说明：
a)
b)
（退出软件、打断、切换、手势等内容经常使用在APP产品中）
5.
接下来我们就要描述清楚产品细节。
我经常使用和上文中“产品结构”相同的顺序来进行说明，从频道、页面、模块、元素进行描述。这种方式适合对技术不太了解的小伙伴，描述的重点是用户看到的部分。
原型
严格来说原型是为了更形象地说明PRD中所描述的页面布局信息，它在需求传递中扮演了重要的角色。
它会随着需求的逐渐明确，变得更加精致：从低保真只表达布局和重点，到中保真表达动态和细节，到高保真的仿真产品。
避免常见的错误
客观
主观：“这里要使用第一人称”
客观：“参考文案规范”
这样可以避免反复修改。
具体
“具体”而不是“详细”，确保文档中不要出现漏洞，清楚明确，但是不要追求描述每一个细节。包含设计或开发过程中出现的存在可能产品混淆的动能定义。
记录
不是“展望未来”，是“记录”当下的决议。
灵活
你完全可以把文档内容拆分开来，或者合并，或者重组，或者删减。你只要确保以下几点：
1.
2.
3.
今天的文章产品设计文档及工作流程分享到此就结束了，感谢您的阅读。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/11255.html
