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