产品有什么工作是没坑的呢？恰逢十一有空，阶段性总结一些经验和要点，先说一说自己对文档的理解。通过分享不同的视角，帮助有需要的朋友更好的形成自己的认识。
我接触的三种文档
Word
哈，我相信这个是绝大多数人最开始接触的文档形式吧？虽然近来大家都对「又臭又长」文档深恶痛绝，但是不可否认Word能力强好处多，不管是对版本控制、审阅批改、链接跳转，还是对拓展文件的支持性来说，Word都可以很好的hold住。而且，多人协作还可以尝试Google Docs嘛。
当文档变得「又臭又长」之后，只会被团队束之高阁，丧失它应有的价值。所以，为了避免「又臭又长」的Word文档出现，我会多讲几句自己使用Word构建文档的习惯，写在后文的「组织与逻辑」小节。
Axure
感觉最近也蛮流行这种Axure的文档的（搜一下「Axure文档」一大堆），好处是在使用Axure画原型的工作流程里，可以直接导出作为可交互的文档。不但文档结构清晰，而且效果还挺酷（我一开始就是被这个吸引了hh），对看文档的人蛮友好。
自己尝试之后发现一些小缺点，就是对太大体量的内容支持性不够好，而且维护起来也挺麻烦。首先，Axure毕竟不是专门为文档服务的，所以当实际工作中需要频繁对文档增删改查和进行版本管理时，会把人烦死（大家的文档都不是一蹴而就的对吧？）。
嗯，由于设计师的不良习惯，我个人比较嫌弃Axure界面丑，所以我用Hype3或JustinMind做这种文档（小声说其实我不做这种文档，怕累hh）。窃以为这种方式做大版本定稿时还是蛮合适的。
Wiki
工作一段时间后接触到的文档形式，在团队合作、大项目支持上，Wiki可以说是有其不可替代性，简单高效的方式会提升工作体验，自己在用的Wiki是amwiki。我现在和Wiki正处于蜜月期，觉得这种文档形式更有利于项目的管理。
图片文档
哈哈，这个是我自己懒的时候喜欢出的文档格式。
因为之前是做设计的，还比较喜欢用sketch，里面有个很好用的插件叫Notebook（9.99欧元），可以在原型的右侧生成一个笔记本，用来对原型内容做标记补充。
这个套路简单快速，针对少量内容的改版需求或简单的功能需求来说，简直不要太方便。
文档面向的三类主要用户
开发
不知道大家怎么样哈，我们开发是不怎么看文档的，给他们讲完就拿着原型和UI的图吭哧吭哧开发去了（果然全靠嘴。。），哪不懂了就来问。结果最后被测试拿着文档测了满身Bug，莫名喜感。
测试
测试或许是文档的「最忠诚」的用户了吧（测试其实心里是苦涩的），它们要根据文档描述，对开发出来的产品进行测试，保证开发结果符合原始设计方案（这么说测试是产品的好伙伴啊）。
运营
主要是根据文档了解产品功能，最简单的客服人员培训，到编写新用户帮助，还有很多产品运营的工作，都可以依据文档来开展，她们一般看不太懂专业性描述，所以尽量让文档更直白一些吧。
文档的目标
简单、准确、易读、易理解
组织与模块
第一呢：自上而下
在文档编写之初，要自上而下的梳理文档目录，从最上层的结构开始逐层细分，使文档目录结构形成体系，避免想到什么写什么这种自下而上的方式。在文档里还应尽量让每一点描述有唯一性位置，尽量避免对相同内容在不同位置出现多个描述。
第二呢：组织整理
当自上而下的梳理了文档目录，也许会发现有的地方需要描述的内容很多，形成了很深的层级，有的地方很少很简单，甚至没有层级。这就是组织结构不太适宜，当目录的结构超过三层时，我一般会将其中的内容重新组织整理，或提高部分的层级，或重新划分内容。这样能保证文档最大的可读性。
第三呢：精简结构
精简结构是说，在整理好目录之后，再检查其中有没有一些内容有包含或重复等关系，将这些会导致重复的内容精简为唯一性内容（唯一的描述地址），避免后期为维护产生不必要的复杂性。
第四呢：模块复用
最简单，之前都整理好了的内容，看看有什么东西是全局性的，都拿出来，做为一个个模块「封装」，一般放在文档前几小节，将之统一描述，这样后文涉及到这些内容的时候，直接放一个跳转链接「调用」就好了，极大的增强了文档的完整可控性。
第五呢：还没想好
大道至简，大象无声，大音希声，不要拘泥于形式，这就剩随机应变了。
关于逻辑、结构、组织的进阶阅读可以找我推荐一些书。
数据与逻辑
后台及隐藏数据交换
额外的需求要额外描述，在涉及到数据流前后台操作的时候，文档中最好能清晰的描述数据的流向，具体的某项数据由哪产生，传递到哪，由什么控制，在哪里储存。多和开发沟通，他们一般会给你结构性的建议。
业务处理逻辑
文档一定要清晰准确的描述出业务处理逻辑，好在大家一般都很擅长思维导图。关键／复杂性的流程单独描述，比如登录注册流程，下订单支付流程，邀请分享流程等。
原型的规范
原型是个坑啊
请原谅我设计出身带来的毛病，个人对很多丑陋的产品原型很抗拒。但原型最重要的是表意清晰，可以不注意对齐排版，但要尽量控制整体原型的规范，保持一致的风格，不然下游工作的开展实在是崩溃，完全不理解原型要表达什么。
原型的标注
个人觉得最好能让原型达到可用性标准，界面元素逻辑清晰，这样可以直接在原型上进行界面元素的标注，更加直观可读。
保真度
在普遍性低保真都很难达到的情况下说高保真我也是含泪了。如果有条件，还是尽量多和交互设计师合作，产出高保真原型。有了它，在业务逻辑验证，异常情况控制，还有商业演示等方向都将有极好的支持。
形成规范
要说出交互文档是难为人了，但是尽量让原型的各个控件是统一化可复用还是能做到的，如果没有特殊原因，不要相同的元素不同的样子，那个不叫原型，叫畸形。
全是表格
善于利用表格，能减少很多的沟通成本
数据限制
输入框的字数限制，允许输入的字符集控制等，我一般会把整个文档涉及到的这部分内容全汇总一下，放在一个单独的表格里，这样既方便查找，也方便唯一性修改。要是怕乱，可以在涉及数据输入／输出的地方编个号，又方便又直观。这也算对测试友好吧？（毕竟测试也是我们的用户啊）。
异常情况
既然是异常状态，一时还真还不知道怎么说hh。断网弱网空数据等等，很多乱七八糟的问题，最好也有规则性的集中描述，这样可以避免自己在设计过程中被大量异常状态打乱思路，增强产品整体的可控性。
好用的状态机
清晰描述不同状态下的业务逻辑，简单来说就是用表格的方式清晰的将某些条件下的某些东西的状态变化描述出来。比如，同一个按钮，「游客」点击时发生什么，「成员」点击时发生什么，「管理员」点击时又发生什么。
状态机图其实是UML中的一种，我们常用的状态机就是那种简化版本，更多知识可以去研究一下UML，对培养概念建模的思维也有挺大帮助，这方面我也不是专家就不多说了，不过要是感兴趣仍然可以找我推荐一些书。
概念性描述
不知道大家是什么情况，但是我在在实际产品中，会遇到很多需要描述的概念性问题，例如社交产品中「圈子」这个概念，积分系统中「会员」这种概念，产品中涉及到的概念都要定义清楚，不应该草草略过，因为这会增加许多的沟通成本（又变？你上次不是说会员要交999吗？）。
其实概念描述最好用的表述方式是图表，类图、用例图、业务图等都是很好用的表述工具，面向对象和面相过程两种编程思维也很适合用来思考概念性问题。
概念描述其实是决定了整个产品是什么的东西，所以一般都放在文档的开始，用各种思维导图来表现（唉其实概念建模真是个苦活）。
角色权限表
对于含社交的软件来说，一个用户往往扮演许多「角色」，比如我在这个群是管理员，那个群是创建者，而且这里还会涉及到不同身份之间的权限变化，更让人糟心的是，当身份权限与用户关系产生关联的时候，比如一个用户可以在自己管理的群里修改成员备注，而在另一个自己为普通成员的群里则看不到之前给同一个人的备注，也不能修改。这类问题很多凑到一起是挺晕的，所以也常常建立「用户角色或权限」这类的表，来逐条解释，就清晰易懂得多了。
积分系统表
对于涉及游戏化机制的产品，这类积分等级身份勋章排行榜的体系表就必不可少（因为如果不画表，你还能怎么办 ＝ ＝）。通常这种表内容很多，但好消息是不怎么用进行规则逻辑性的描述。通常都是采取阶梯制度的建表方式，比如当用户满足条件A>0，触发什么，当A>10，又触发什么。一般来说这个表只要做好数学计算就不难搞定（什么！你说数学不难？）。
数据埋点
这个我一般单独出文档，根据业务阶段和项目要求吧。不是什么时候都需要埋点，而且个人觉得埋点这事和主业务相关度不大（如果主业务是测试就当我没说），应该作为单独文档提交。
拆分文档
灵活组装
在实际生产状况中，将整个文档拆分为数个小文档工作是蛮靠谱的开发方式，不但能优化开发节奏，有利于分工协作，还能强迫文档形成统一的规范，保持完整性。
特殊模块
为了保持专注性（这个很重要啊），和避免「又臭又长」文档的出现，通常将文档的许多不是强相关性的模块拆分为单独的文档，比如说埋点文档，交互文档，UI文档，后台文档等。
关于交互
被过多考虑的内容
我一直认为交互不应是产品的主要工作，原因有以下几点：
产品更应该关注产品的全貌
交互只是产品价值链中的一环
交互设计师是一个专业性很强的职业
通常很擅长交互的产品，总会过多干涉交互设计师的工作（和指导程序敲代码一个道理）
所以，如果工作中能有专人负责交互设计，还是建议各位尊重团队的力量（如果整个工作流程全是你自己，那就多加油吧，干巴爹）。
这个交互设计自查表
看过很多在文档内拉出一份思维导图来检查各种设计的状态的图，做过交互的都知道，这玩意儿叫交互设计自查表。首先我不是说交互设计自查表不好啊，但是过分强调总让人觉得言过其实。是的没错，产品设计的完整性可以通过使用这些工具来完善。
但，更重要的确确实实是产品的业务逻辑，可以允许Bug，可以允许异常，甚至可以允许体验差，但是谁敢允许业务不闭环？
而且窃以为，这些工具展现出来的意义更多在于——构建自查清单式的思维模式。新手学习使用工具，但是应该明白并思考工具背后的逻辑，这才会慢慢走向成熟，构建出自己的工具与思维方式，千万不要把工具奉为圭臬，舍本逐末。
最后一句，在精力有限的时候，要学会聚焦关键任务（所有的工作都是成本）。
关于体验
应该涵盖的内容
窃以为相比交互，体验才是更应该被纳入文档内的内容，我不知道是因为市场教育还是职位发展的原因，体验设计师被人提及的概率远远小于交互设计师，而其实在当下，体验设计师确确实实起着不可忽视的作用。
体验设计要根据业务阶段调整节奏，考虑在什么时刻纳入文档范畴，以及涉及的深度。
关于修改
善于修补达到极致
想要没有问题的文档，就像想要没有BUG的程序。只有虚心接纳，并善于经营，我们才能达到更好。
关于沟通
设定目标，阶段可控
设计经验告诉我，要想获得稳步的项目推进，就需要在项目之初，提前设置好关键的沟通节点，保持项目的每一阶段的进展变化可控（比如内部提案）。
文档真的不是写好了交出去就可以了。最好要在前期就与相关人员展开沟通，理清了了是逻辑与数据层面的问题，确定了主要功能和框架之后，才是慢慢完善文档处理细节的时候。
好的文档也是善于管理项目进度的体现，毕竟这种东西也要消耗大量精力啊。
大家说，产品开发不用文档行不行？比如……用爱？
