这就好像在准备宴席前，你需要提供给厨子一份详细的菜谱。不过，设计师不像厨子，他每次面对的都是全新的内容，所以不仅需要提供菜谱，还需要写清楚每个菜都是什么，需要什么配料，等等。当然前提是双方之前已经经过非常详细的沟通，彼此都明白对方的想法和期望。
需求文档不仅面向设计师，也面向团队中的开发和测试人员，是项项目成员参考的重要依据。
● 需求文档应该包含什么内容?
需求文档到底要写什么内容，这个不可一概而论，应该根据具体的项目情况酌情考虑，选择最适合当前情况的文档格式。在常规情况下，帮求文档应该包含前面提到的产品定位、需求内容、需求优先级等，以及关于需求的详细描述说明。下面是关于标准需求文档的内容示例。
文档修改与审核记录:需求文档如有修改，需要简要记录，如图5-9所示。
目录：如内容过多最好提供目录。
背景描述: 为什么要做这个产品/模块、市场行情、业务目标、产品定位等。
用户类型和特征: 简单的描述目标用户情况或现有使用人群的情况。
项目时间安排: 何时启动，何时完成等。
信息结构: 这里可简单理解为内容或页面的层级，如图5-10所示。可以由设计师和产品经理配合完成，也可由产品经理独立完成，设计师做参考用。
整体业务流程说明: 对于涉及操作较多的产品/功能，需要业务流程图，帮助设计师和项目成员理解具体的业务逻辑。比如一个广告投放系统，当广告排期被占用时，用户是否可接受相关位置；如不接受，系统如何处理账户金额，等等，如图5-11所示。
需求详细说明: 每一条需求的详细说明。一个文档里会有若干条这样的说明，如图5-12所示。
● 需求文档的后续迭代
如同设计稿需要不断修改一样，需求文档也需要不断的
破茧成蝶-用户体验设计师的成长之路
修正、迭代。
首先要认识到，需求文档不可能一次到位。谁也不能保证一次把所有的问题想清楚。一般来说，在完成需求文档后，需要进行需求评审。评审时主要看需求有没有明显的漏洞、不合理的地方，在技术上有没有实现难度，能不能按期完成等。评审过后，产品经理会根据大家的意见重新修改文档迭代3次以上是很正常的现象
另外，有一些较细节的东西在需求阶段不容易考虑清楚，要到具体的设计阶段才会有更深入的思考。但一些产品经理为了方便大家理解，会在需求文档中增加一些UI示意图。设计师可把它们作为参考，但不要过多地受其影响 。
最后一点要注意的是，设计师不要严格按照需求文档来做设计。产品经理的考虑角度和设计师不可能完全一样，需求文档更多的是体现业务、产品要求、功能等内容，而设计师还需要更多地去考虑目标用户的特征、使用场景、痛点等。这些信息综合起来，才是设计的主要依据。如果设计师参与了之前的产品定位、需求采集与分析过程，就会对用户的情况比较了解
因此，深圳网站建设专业的交互设计师产出的设计结果一般都会和需求文档提供的内容不太一样，如信息结构、任务流程、内容、界面形式等。只要经过有效的沟通，产品经理一般都是可以接受的。这相当于是在交互设计阶段对文档进行了迭代。产品经理可以在设计完成后再修正需求文档，也可以让设计师把相应的修改部分注释在原型稿上，这样开发人员只看原型稿就可以了。
本文地址：//www.gogoparty.cc//article/2742.html
