需求发生了，产物司理就可以持续撰写需求文档了。因为设计师已经介入了前面的需求剖析工作，此时对产物情形、用户情形、设计偏向已经有了必定的懂得。需求文档对设计师来说，更像是一个彼此商定好的产物功效清单，赞助提示设计师接下来要做什么。

这就似乎在预备宴席前，你须要供给给厨子一份具体的菜谱。不外，设计师不像厨子，他每次面临的都是全新的内容，所以不仅须要供给菜谱，还须要写清晰每个菜都是什么，须要什么配料，等等。当然前提是两边之前已经经由异常具体的沟通，彼此都明确对方的设法主意和期望。

需求文档不仅面向设计师，也面向团队中的开辟和测试人员，是项项目成员参考的主要根据。

● 需求文档应当包括什么内容?

需求文档到底要写什么内容，这个弗成一概而论，应当依据具体的项目情形酌情斟酌，选择最合适当前情形的文档格局。在惯例情形下，帮求文档应当包括前面提到的产物定位、需求内容、需求优先级等，以及关于需求的具体描写解释。下面是关于尺度需求文档的内容示例。

文档修正与审核记载:需求文档若有修正，须要扼要记载，如图5-9所示。

目次：如内容过多最好供给目次。

配景描写:为什么要做这个产物/模块、市场行情、营业目的、产物定位等。

用户类型和特点:简略的描写目的用户情形或现有应用人群的情形。

项目时光支配:何时启动，何时完成等。

信息构造:这里可简略懂得为内容或页面的层级，如图5-10所示。可以由设计师和产物司理合营完成，也可由产物司理自力完成，设计师做参考用。

整体营业流程解释:对于涉及操作较多的产物/功效，须要营业流程图，赞助设计师和项目成员懂得具体的营业逻辑。好比一个告白投放体系，当告白排期被占用时，用户是否可接收相干地位；如不接收，体系若何处置账户金额，等等，如图5-11所示。

需求具体解释:每一条需求的具体解释。一个文档里会有若干条如许的解释，如图5-12所示。

●需求文档的后续迭代

如同设计稿须要赓续修正一样，需求文档也须要赓续的

破茧成蝶-用户体验设计师的成长之路

修改、迭代。

起首要熟悉到，需求文档弗成能一次到位。谁也不克不及包管一次把所有的问题想清晰。一般来说，在完成需求文档后，须要进行需求评审。评审时重要看需求有没有显著的破绽、不合理的处所，在技巧上有没有实现难度，能不克不及按期完成等。评审事后，产物司理会依据年夜家的看法从新修正文档迭代3次以上是很正常的现象

别的，有一些较细节的器械在需求阶段不轻易斟酌清晰，要到具体的设计阶段才会有更深刻的思虑。但一些产物司理为了便利年夜家懂得，会在需求文档中增长一些UI示意图。设计师可把它们作为参考，但不要过多地受其影响 。

最后一点要留意的是，设计师不要严厉依照需求文档来做设计。产物司理的斟酌角度和设计师弗成能完整一样，需求文档更多的是表现营业、产物请求、功效等内容，而设计师还须要更多地去斟酌目的用户的特点、应用场景、痛点等。这些信息综合起来，才是设计的重要根据。假如设计师介入了之前的产物定位、需求采集与剖析进程，就会对用户的情形比拟懂得

是以，深圳网站扶植专业的交互设计师产出的设计成果一般都邑和需求文档供给的内容不太一样，如信息构造、义务流程、内容、界面情势等。只要经由有用的沟通，产物司理一般都是可以接收的。这相当于是在交互设计阶段对文档进行了迭代。产物司理可以在设计完成后再修改需求文档，也可以让设计师把响应的修正部门注释在原型稿上，如许开辟人员只看原型稿就可以了。