前几天有朋友问我需求文档应该如何写作？需要注意点什么？其实需求文档在每个公司和每个人的产出的都可能是不一样的，基本上没有固定的格式，如果简明扼要的概括就是需求文档把你这个需求描述清楚你想要什么就可以了。

需求文档注定是给所有人看的，它就是产品的定义。

• 文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。
• 在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。
• 所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。
• 在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。

需求文档写作的一些建议

• 格式无所谓。用WORD的多，HTML，在线文档都成，我还见过PPT写的！
• 产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。
• 使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？
• 多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。

比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。

比较正规的文档目录

1. 文档信息，版本记录，责任人等
2. 项目背景，产品目的
3. 文档约定（采用的标准，通用名词等）
4. 可行性分析
   • 前期调研
   • 产品预期
   • 对其他产品的影响
5. 产品定义功能详述（文档主体部分）
   • 功能模块
   • 用例
   • 用户流程
   • 数据需求
   • 业务规则流程
6. 产品非功能需求
   • 对性能的需求
   • 安全性需求等
7. 产品风险或潜在问题

这种文档现在更多的出现在软件行业和严谨开发行业，对于互联网而言已经慢慢简化了需求文档的冗余程度，只要这个文档能很清晰的把这个产品描述清楚就好。

如：微博上有好友推荐关系，需求文档中可以描述为

向用户A 推荐 用户B 为他有共同爱好的人，那么他们需要有>10个共同关注的人；
向用户A 推荐 用户C 为他可能感兴趣的人，那么他们需要有共通过的粉丝>10人；

　　这两句话描述了微博用户推荐机制产品经理需要给开发产出的需求描述，也经常遇到会有开发问“他们之间怎么关联在一起”“这两个表不在一个数据库“等问题，如果产品经理是开发转型能提供解决方案并且时间很充裕可以协助一下，但大多数产品经理也许不会开发，所以这些问题开发要自己想办法解决，不要凡事遇到问题就找产品经理。产品经理也是人，不是神；

本文译自Facebook产品设计总监Julie Zhuo 发表于Medium的《How to Work with Designers》。以下为译文；本文转自公众微信：互联网er的早读课（zaoduke）

　　多年前，我曾当过产品经理，然后是工程师，而过去七年我从事的是设计工作。每天我都跟担任这些角色的人一起工作，每一天，我对产品开发背后的责任、挑战和艺术都有新的体会。对于想要搞经楚设计这个奇怪、锐利、helvetica-typed 世界的工程师和产品经理们，这篇文章正是为你们而写。

若想使用设计师语言，请停止说那些指标的事，改聊使用者。

　　其实大多数的情况下，「指标」跟「使用者」意思不会相去太远。举例来说，你或许是希望设定一个目标，让注册页面的转换率提高X%；另一种说法其则是：你想要扫除那些阻止使用者注册、使用产品的障碍。但是你看，「说法」在这里就变得很重要——让使用者更容易注册vs. 优化注册流程的转换率。前者谈的是对使用者的价值，后者则是公司为了成功所产生的需求。设计师做事的心态一般来说是比较偏向使用者这边。
继续阅读 →

　　接触金融网销市场也有一年多了，与之前做的产品设计基本上属于两个思路，前些日子在做新版首页改版时讨论到一个对电商很重要的问题「搜索」对保险电商的重要性如何？

1、保险非实物并且大多属于同质化产品
2、购买保险的用户意向很明确需求不明确
3、不知道搜什么

以上几个观点是为什么得来的呢？

1、保险同质化

　　其实现在市面上大多数如：国内旅游险、短期意外险，这种简单的险种保险责任基本相同，不同的只有保险公司、保费、保额的区别，也许个别公司会增加几个特殊的保障责任；

2、意向明确、需求不明确

　　为什么这么说呢，模拟一下比如我们是一个驴友，要去欧洲旅游需要买申根签证保险，这个是大使馆要求的这种保险需要医疗险达到30万，这个是必须买的所以用户知道我要去旅游，我要买申根签证保险，但是具体买什么公司的保险，买什么保险他并不知道；

3、不知道搜什么

　　综合以上两点特别是第二点，用户并不知道我要搜索什么，不像淘宝、京东，意向和需求都很明确（如：我的电饭煲坏掉了，我要买个电饭煲；夏天了我要买个空调）。

　　如果用户不知道搜索什么内容我们把搜索模块设计的非常突出就没有必要了，开心保在新版设计时我将搜索模块弱化，需求导向强化按需求进行流量导入如：我要去旅行、意外保障、家庭责任、投资理财、团体订购；让用户可以一目了然看到按照需求进行分类筛选好的保险产品，在做搜索的竞品分析时有一家知名保险电商将搜索模块放在显著位置但是搜索规则又很弱很不明白这个是如何设计的。

　　近几日在设计帮助中心参加评审过程中遇到的一些问题，帮助中心到底是干什么用的？帮助中心应该帮助用户什么？帮助中心流量大了是否要充分利用起来？帮助中心是否应该增加UGC模块？这篇博文记录一下我对帮助中心的思考和设计过程，希望能对大家有所帮助，如果有不同意见欢迎指出和探讨。

#帮助中心到底是干什么用的？

　　就目前各大网站帮助中心的设计帮助中心属于网站中重要的组成部分，但是在UE和UI设计的过程中全部都是弱化设计无一例外，帮助中心到底是干什么用的呢？我个人认为，帮助中心是在用户遇到问题解决具体问题而设计，并不需要像产品使用说明书一样大而全唯恐网站哪个功能讲解的不全面，目前帮助中心分为两大内容：1、功能类导航；2、使用介绍

#帮助中心应该帮助怎么帮助用户？

　　就目前使用习惯来看，帮助中心大多数适用于互联网初级用户对特别是电子商务网站对网上购物不是很了解或者该网站的整个购买流程很特殊需要单独说明，就我个人目前的使用习惯各大网站帮助中心我从来没主动进去过，那么对于互联网初级用户我们怎么能更好的帮助他们呢？

1、功能类导航

　　用户在使用过程中想对整个购物流程中的某一个环节进行操作但又不知道这个功能在哪里，帮助中心首页起到一个很好的导航作用，如上图京东帮助中心首页，京东作为比较有代表性的B2C网站帮助中心的功能类导航就按照售前、售中、售后电商的三个基本模块来划分的，京东根据用户最关心的内容将这三个模块重新排序：第一列售后、第二列售中、第三列售前；

2、使用说明

　　使用说明又分为两种，①操作流程类、②文字说明类。

①操作流程类

　　主要讲解网站整个流程购买流程从注册到最终购买结束退换货等，如上图所示，京东帮助中心首页按照售前、售中、售后这三个顺序对网站操作类说明进行排序，对各个模块功能进行介绍，点击进去的介绍京东很直观用操作示意图直接展示没有冗余的文字介绍清晰直观，对需要使用帮助中心的初级用户很容易理解。

②文字说明类

如上图所示首先设计思路是支付宝这个功能需要具体说明又无法用一言两语概括，但又很重要必须要让用户知道这个功能或者这个模块是干什么用的，如上图所示支付宝余额宝的收益介绍，京东的211限时达

#帮助中心流量大了是否要充分利用起来？

　　就我目前的观点帮助中心如果流量在网站有占比例就是这个网站产品经理的失败，就目前的产品设计主导思想如果一个产品不能马上让用户拿到手就可以轻松上手还要去翻帮助中心和说明书我觉得这个产品就是一个失败的设计，举例说明爱卡汽车，用户在使用时注册完全可以使用更智能化的方式，这种让用户亲自动手发送短信注册完全是多此一举增加注册难度这个功能比没有还可怕，并且用大量文字说明。（图片来自@寻少华的朋友圈）

#帮助中心是否应该增加UGC模块？

　　有很多同学认为帮助中心有流量就要充分利用起来这部分流量，在帮助中心加入问答模块让用户创造内容将问答模块的内容丰富起来既可以减少工作人员录入内容的工作量又可以被搜索引擎收录增加流量，我的观点根据上面一个观点流量大就是错误的，在电子商务网站要让用户创造内容更是可笑，我们关注的UGC内容应该是如何引导用户在【购买后】进行产品评论，并不是在遇到问题时不是尽快帮助他解决问题而是让他用非即时的方式来提问，往往这个问题解决了用户也没有购买的冲动了，再则也许是保险类电子商务和其他产品不一样。

　　最后，对于电子商务我也一直在摸索中，之前做社交类网站我知道用户创造内容对于一个网站需要付出多大的成本和精力，但电子商务特别是保险类电子商务我觉得一切不以促成订单为目的、提高转化为目的的产品设计都是耍流氓，以上个人一点小小的观点很久没发这种文章了，欢迎拍砖和探讨。