做产品至今，林林总总写过的需求文档有近百份，复杂的有100页+的word，简单的是一张截图配几句说明，经历过的公司产品文档模板也是五花八门，在不同的产品间复用性极差。而在实际的产品研发过程中，最有效的沟通依然是和开发当面交流，熬夜写出来的需求文档，往往成为一种追责溯源的证据和考核升迁的KPI。
做产品的都知道什么是换位思考，什么是用户角度。针对需求文档的读者，无论是设计、开发还是测试都是我们的用户，我们是不是缺少了换位思考，缺少用户角度。试问，若你是开发：你能静下心来花一两个小时，看几十上百页又臭又长，全是文字描述的需求文档？你能在几千字中找到你想要的重点内容，快速高效的设计表结构和撰写开发概要？
所以最高效的方式依然是，产品那个谁滚过来，给我说说这个需求是咋样的。然后，产品汪汪汪。己所不欲勿施于人，我猜大多数的产品，写完需求文档自己都不愿意看第二遍吧？想写一份易用性强的需求文档，就需要先搞清楚这样一个问题：
当开发工程师在看产品需求文档时，主要在看些什么？
我归纳为流程、数据、边界、交互四个关键词。
一、流程
这里的流程有业务流程、功能流程、页面流程三种。业务流程不用说，这是整个产品的核心，所有的产品都是基于为其业务流程服务的。页功能流程即是复杂功能的流程，如登录注册，下单支付，提交审核等。而页面流程是页面间的父子层级关系结构图，亦成为信息结构图或页面结构图。
二、数据
做原型图时，我建议大家一定要时刻记住，每添加一个按钮，一个图标，一段文字或者一张图，都要问自己这个数据有没有？这个数据从哪里来？很多外行人指点江山，都喜欢让这里加个按钮，那里加个广告，然后说这么简单的小需求一个小时搞定。他们可以这样，因为人家是外行，只会也只要动嘴。而产品不行，你要为自己每一句话负责，为团队所有人劳动成果负责。
三、边界
边界包含数据规则、限制条件、异常判断等内容，如订单生成规则及位数？订单标题的最高字符数？不足和超出时分别如何显示？商品列表页为空时显示什么？多条数据时以什么规则排序？加载方式是分页还是瀑布流？默认加载几条？当网络异常或服务器问题时如何显示？总之，一句话尽可能考虑每一个小功能的边界条件，针对不同边界给出限定或解决方案。
四、交互
关于交互，有可触元素是哪些？触控范围多大？点击页面跳转还是弹窗？弹窗以什么形式出现等。常规的交互方式只要多赏玩几款主流的App，应该都能描述清楚。在此，我给出的建议是不要太过于追求花哨的交互方式，同一个页面不要用超出3种不同的交互，类似的功能尽可能保持交互一致性。
以上为本期所有内容，欢迎留言讨论~
