DRD交互文档规范
交互的规范
交互的规范交互的规范是指在进行人与人、人与机器、机器与机器之间的交互时应遵守的一系列行为准则和规则。
良好的交互规范能够提高交流效率，减少误解和冲突，提供更好的用户体验。
以下是交互的规范，全文约1000字：一、尊重和礼貌1. 与他人交流时应保持尊重和礼貌，不使用粗鲁、冒犯的语言。
2. 注意不要打断他人的发言，听完对方的观点后再做回应。
3. 在使用机器交互时，也要遵循礼貌原则，尊重机器的反馈和指示。
二、明确和简洁1. 在表达自己的观点时要尽量明确和简洁，避免冗长和模糊的陈述。
2. 使用简洁明了的语言、图标和符号，使信息更易理解。
3. 在机器交互时，要注意遵循机器的提示和指示进行操作，避免不必要的操作或信息输入。
4. 提供清晰而简洁的反馈，让对方明白交互是否成功。
三、准确和可靠1. 提供准确的信息，在回答问题或传达观点时要确保信息的准确性。
2. 避免故意提供虚假或误导性的信息，对待数据和事实要负责任。
3. 在使用机器交互时，要确保输入的数据准确无误，避免因输入错误导致错误的结果。
四、配合和合作1. 在与他人交互时，要积极配合和合作，不断寻找共同的解决方案。
2. 在团队合作时，要尊重他人的意见，充分发挥个人的优势，相互配合，共同完成任务。
3. 在机器交互时，要按照规定的步骤进行操作，与机器保持良好的配合和合作。
五、耐心和倾听1. 在交流中要保持耐心，听完他人的观点和需求，不要匆忙做出回应。
2. 对于不懂的问题要虚心请教，听取他人的意见和建议。
3. 在机器交互中，耐心地按照机器的指示进行操作，遇到问题时可以阅读说明文档或寻求帮助。
六、关注隐私和安全1. 在交互过程中要注重个人隐私的保护，不泄露自己和他人的个人信息。
2. 在使用机器交互时，要确保自己的账户和密码安全，避免被他人冒用。
3. 如果发现他人的隐私或安全受到威胁，应及时提醒对方并寻求帮助。
七、反馈和改进1. 对于不满意的交互体验，应及时提出反馈意见，并提供改进建议。
交互说明文档-规范
交互说明文档教学一. 什么是交互说明文档（DRD）？所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。
在项目中，交互设计师的主要产出物可能依次是：site map，page flow，wireframes。
有的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD产出的市场需求文档不一样的是，URD更多侧重于对目标用户的需求分析）。
DRD则很少有人专门撰写。
如果需要对交互设计进行说明，聪明的交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。
二. 为什么要写？DRD非项目必需环节，一般情况下也不会为交互设计师专门留出相应的时间预估。
没有这份文档，项目也会继续，但是可能项目会为此承担不必要的沟通成本和时间成本。
严重的话，项目的质量也会受到影响。
所以写与不写，交互设计师需要做把握，时间被统一包含在“线框图”环节内——如果你要写，请在评估时预留1-2天的时间。
那么，结合我过去的经历，谈一下此文档的必要性。
下图是一个产品开发项目基本的流程。
敏捷开发意味着很多不同角色的流程需要并行操作。
如果等到产品经理的FRD已经全部敲定，交互设计师再开始去画线框图，固然会减少沟通成本和返工风险，但是同时意味着交互设计师的很多想法不被采纳。
如果产品经理再强一些，他甚至会在FRD里连原始的DEMO也一并绘制出来了，功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在FRD里直接要求每页条目40条，超过40条即分页。
而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和……所以，我们希望是和产品经理同时开始工作，在术业有专攻的时候相互补充。
同样，开发工程师也希望及早介入需求，在FRD并未确认的时候就了解需求，进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单（这个清单，大部分叫做UC，即USE CASE）,当这份清单由工程师需求分析师——在过去，这个角色被叫简称为RA，但是目前已经取消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将做这件事情的人称为RA——交付给具体的执行工程师后，执行工程师基本上可以当作一条条的checklist开始高效工作，而不必再思考商业逻辑和需求。
交互规范文档
交互规范文档一、引言交互规范是指在设计产品或系统时，为了确保用户体验的一致性和高效性而制定的一系列规定和标准。
良好的交互规范可以帮助用户更加轻松地使用产品，提升用户满意度和忠诚度。
本文档旨在为我们的产品交互设计团队提供一份统一的交互规范指南，以确保我们的产品在交互设计上能够达到统一的标准。
二、设计原则1. 用户为中心：在设计交互时，始终以用户的需求和体验为首要考虑，确保产品的易用性和友好性。
2. 一致性：保持产品内部和不同产品之间的一致性，包括交互风格、操作习惯等，让用户能够轻松地在不同产品间切换。
3. 反馈及时性：在用户进行操作后，及时给予反馈，让用户清楚地知道他们的操作是否成功，避免用户迷失在界面中。
4. 简洁性：避免在界面上出现过多的冗余信息和操作，简化用户的操作流程，提高用户的效率。
5. 可控性：给用户提供可控的操作方式，避免强制性的操作，让用户可以根据自己的需求进行选择。
三、交互设计规范1. 导航规范1.1 导航的位置应当统一放置在页面的顶部或左侧，避免在不同页面中导航位置的变化，让用户可以快速找到导航入口。
1.2 导航栏中的链接文字应当简洁明了，避免过长或者模糊的文字，同时需要保持一定的排版和样式一致性。
1.3 当用户进行某一导航操作后，需要明确标识当前所在位置，让用户清晰地知道自己所处的页面。
2. 内容呈现规范2.1 内容的排版应当合理，避免出现过长的段落或者过小的字体，保证用户可以轻松阅读。
2.2 图片和文字的搭配应当合理，避免出现文字和图片之间的重叠或者错位。
2.3 页面中的重要内容需要突出显示，可以采用颜色、大小、位置等方式进行突出。
3. 操作规范3.1 操作按钮的样式和位置应当统一，避免在不同页面中出现不同的操作按钮样式，让用户可以快速找到需要的操作。
3.2 用户在进行操作后，需要及时给予反馈，告知用户操作是否成功或者失败，并给出相应的提示。
3.3 避免出现强制性的操作，如弹窗广告、强制登录等，给用户留有一定的操作空间。
交互规范文档
交互规范文档交互规范文档主要用于规范和统一人机交互的行为和设计，以确保用户在使用产品时能够获得良好的体验。
下面是一个交互规范文档的示例：1. 页面布局：- 确定顶部导航栏的位置和样式；- 内容区域要与侧边栏保持一定的间距；- 页面底部应该包含版权信息和其他相关链接。
2. 导航菜单：- 导航菜单应该清晰、简洁，并且与产品的功能结构一致； - 用户点击菜单项后应有明显的变化，以提示其当前所在位置；- 导航菜单的子菜单应该以下拉列表或者其他方式展示。
3. 表单设计：- 标签、输入框和按钮应该以清晰的方式进行布局，方便用户输入；- 输入框应该在未输入内容时提供默认提示信息；- 验证错误时需要给出明确的错误提示，并且将错误信息显示在相应的输入框附近。
4. 按钮和链接：- 按钮和链接的样式应该具有明显的点击效果，以便用户区分；- 链接应该有清晰的文字描述，指明目标页面或功能；- 避免在按钮和链接上使用模棱两可的文字或图标，以避免用户困惑。
5. 弹窗和提示信息：- 弹窗的设计应该突出重点信息，避免过多的内容；- 提示信息应该简洁明了，以便用户快速理解；- 错误提示应该清晰明确，避免给用户造成困惑。
6. 用户反馈和确认：- 对于用户的操作需要给出明确的反馈，以确保用户明白其当前状态；- 对于涉及到重要操作的情况，应该进行二次确认，避免误操作。
7. 键盘快捷键：- 对于常用的操作，可以提供相应的键盘快捷键，以提高用户的操作效率；- 快捷键的设计应该与用户的习惯相符，避免与系统快捷键冲突。
这只是一个交互规范文档的简单示例，实际的文档内容可以根据具体产品和需求进行调整和扩展。
文档应该被所有相关人员共同遵守，以确保产品的一致性和用户体验的良好。
Director第七课行为与交互(一)
在库面板中任何一个行为的上部单击鼠标右键，都会弹 出“显示名称”框，该框用来设置是否在库面板上显示 行为的名称。 单击库面板左上角的第二个按钮，可以改变库面板的显 示方式。 3、行为的附着和设置 要使用行为就必须将行为附着精灵或帧上。该行为的参 数对话框将会出现，要求用户为其设置参数。
指定的参数只对当前的精灵或帧起作用，并且， 指定的参数只对当前的精灵或帧起作用，并且，这 些行为的设置不会影响行为在其他地方的操作。 些行为的设置不会影响行为在其他地方的操作。 对于已经附着到精灵的行为， 对于已经附着到精灵的行为，使用行为检查器可以 更改该行为的参数。 更改该行为的参数。 Director中 用户可为同一个精灵附多个行为， 在Director中，用户可为同一个精灵附多个行为， 但是帧只能附一个行为 但是帧只能附一个行为
5、改变已附着行为的参数 在为精灵或帧附着好行为之后， 在为精灵或帧附着好行为之后，如果要对行为的参数 进行修改， 进行修改，可以使用下面的基本操作 选中要更改参数的行为所附着的精灵或帧 打开行为检查器 双击行为检查器中要更改参数的行为， 双击行为检查器中要更改参数的行为，或在选中行为 的情况下，单击行为检查器右上角的“参数” 的情况下，单击行为检查器右上角的“参数”按钮 在打开的参数设置对话框中为行为重新设置参数。 在打开的参数设置对话框中为行为重新设置参数。
在库面板中，用户可以对多种类型的行为进行选择。另 外，在某些类型的行为库中，还包含有子行为库，例如 “动画”行为库。 单击库面板左上角的按钮，可以打开当前可用的行为库 菜单。从行为库菜单中选择一个菜单选项，即可使该行 为库中的所有行为显示在库面板中。例如打开“动画” 行为库中的“交互”子行为库 将鼠标指针放置到任何一个行为图标的上部，与该行为 相关的提示信息就会自动弹出。
规范化数据交互的操作标准
规范化数据交互的操作标准1. 引言本文档旨在制定规范化数据交互的操作标准，以确保数据交换的准确性、安全性和一致性。
该标准适用于所有涉及数据交互的工作流程和系统操作。
2. 数据交互准则在进行数据交互时，应遵循以下准则：2.1 数据准备- 所有待交互的数据应经过严格的验证和清洗，以确保数据的准确性和完整性。
- 数据应以统一的格式进行存储和编码，便于交互和解析。
2.2 交互权限- 只有经过授权的人员才能进行数据交互操作。
- 不同的用户角色应有不同的交互权限，以确保数据的安全性和隐私保护。
2.3 加密和解密- 对于敏感数据，应使用加密算法进行加密，以确保数据在传输过程中的安全性。
- 接收方在接收到加密数据后，应使用相应的解密算法进行解密，以还原原始数据。
2.4 数据传输- 在数据传输过程中，应记录传输日志，以便追踪和排查可能的问题。
2.5 错误处理- 在数据交互过程中，可能发生各种错误。
应根据错误类型制定相应的错误处理策略，并及时通知相关人员进行修复。
3. 数据交互流程数据交互的具体操作流程如下：1. 数据准备：验证和清洗待交互数据，确保数据准确性和完整性。
2. 加密数据：对敏感数据进行加密处理。
3. 验证权限：根据用户角色验证交互权限。
4. 数据传输：通过安全通道进行数据传输。
5. 解密数据：接收方使用相应解密算法对加密数据进行解密。
6. 数据处理：对接收到的数据进行处理和存储。
7. 错误处理：根据错误类型执行相应的错误处理策略。
8. 记录日志：记录数据交互的相关信息和日志。
4. 总结通过遵循规范化数据交互的操作标准，可以保证数据交换的准确性、安全性和一致性。
所有涉及数据交互的工作流程和系统操作都应遵循此标准，以确保数据交互的顺利进行。
谈谈原型设计中配备的原型交互规格说明书(DRD)
谈谈原型设计中配备的原型交互规格说明书（DRD）大家好，上一期我讲了“产品经理应该如何有效地开展原型设计的工作”，结合上期的内容，这期咱们以“浅谈原型设计中配备的原型交互规格说明书（DRD）”为课题来进行探讨。
在实际的项目中，设计方案如何传达给开发人员和视觉人员，如何将一个需求所涉及到的多个页面以及每个页面的规则准确地传递给相关人员？在整个开发过程中，如何维护并改进方案，并且将改进过的结果展示给相关人员，保证在后面的迭代过程中都做一个存证？每个设计方案可能会经过很多次的迭代，也可能会有多个版本，那如何保证在一个文档里面体现多个版本的迭代呢？这就引出了原型交互设计文档的概念，原型交互设计文档也被称之为DRD（Design Requirement Document）。
这期我们主要围绕浅谈原型交互规格说明书（DRD）的规则、原型交互规格说明书（DRD）的结构分析、撰写原型交互规格说明书（DRD）的注意事项这三个方面来进行阐述。
一、浅谈原型交互规格说明书（DRD）的规则一个完整的交互设计文档，不只是一个简单的原型设计文档，而是一套体系、一个完整的产品，所以我们从产品的角度来给大家分析一下交互文档。
交互设计说明书是指用来承载交互设计说明，并交付给前端、测试以及开发工程师参考的文档，是产品经理和交互设计师的一项基本功。
它是把抽象的产品需求转化为具象的线框图呈现的过程，在交互设计日常工作输出的最终产物，用来告诉别人「页面设计细节」的一个说明文档。
在项目中，产品经理或者交互设计师的主要产出物可能依次是：站点地图（site maps）、页面流（flow charts）、线框图（wireframes）、视觉样式（screen designs）。
如果需要对交互设计进行说明，有些产品经理或者交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。
交互设计规范(内部文档)(仅需1个财富值)
交互设计规范( 基于后台)产品部2011年08月24日修订历史目录1概述 (4)1.1设计说明 (4)1.2读者对象 (4)1.3名词解释 (4)2页面信息规范 (5)2.1页面标题规范 (5)2.2链接新窗口规范 (5)2.3页面图片信息规范 (5)3信息交互规范 (6)3.1预先信息提示 (6)3.2操作信息提示 (7)3.3结果信息提示 (8)4通用组件规范 (9)4.1导航 (9)4.2按钮 (9)4.3输入框 (9)4.4搜索 (9)4.5浮层 (10)4.6列表 (10)1.概述1.1设计说明交互设计是很自由的事情，因此规范不会对细微之处作明确规定。
该文档为通用性质，通用交互规范目的是保证整站的交互体验的一致性。
并且保证一些体验较好的交互方式能在各个模块中得以使用，从而保证产品设计的一致性，提升整体产品质量。
注：本交互规范基于55后台制定，与前台部分设计可参考。
➢页面信息规范针对页面交互信息的标准，包括：页面标题、链接新窗口打开规范、图片信息。
➢信息交互规范交互流程中包含的信息交互方式，包括：预先提示信息、操作提示信息、结果信息提示。
➢通用组件规范对于一些可在多页面中使用的通用组件进行规范，包括：按钮、导航、输入框、搜索、浮层、列表。
1.2读者对象产品开发人员，产品交互人员，产品UI设计人员1.3名词解释2.页面信息规范2.1页面标题规范➢用于规范整个产品中所有不同层级不同功能的页面应该使用的标题。
标题需要加粗，不同层级的标题均需要加粗，设计过程中可自定义字体大小。
2.2链接新窗口规范➢用于规范页面链接是采用新窗口打开还是本窗口打开。
1.本窗口打开查询结果、上下翻页、内容保存等操作在本窗口打开。
2.新窗口打开各类详情页面、商品预览页面（编辑）采用新窗口打开、2.3页面图片信息规范➢用于规范页面图片信息显示是否带有alt、title值、BLANK链接。
目前后台图片分为：按钮图片、内容型图片1.按钮图片Alt：交互使用的按钮图片（不带文字）：如编辑、添加、警告等。
【补充学习资料】交互文档输出规范及细节
交互文档输出规范原型交互文档输出规范及细节交互文档输出规范交互输出规范交互文档覆盖内容（参考）内容概述项目封面整体文档的封面，包括：项目名、版本号、作者、时间、功能需求项目背景•背景：为什么要做这个项目？项目的范围？当前存在的问题？•产品目标：满足什么需求？解决什么问题？提升什么指标？•用户目标：目标用户、核心场景、核心任务、关注重点等•其他目标：包括运营、业务等业务流程图展示业务流转概况和逻辑，强业务/强流程类型的项目建议放信息架构图网站或App的基础架构（层级结构的主导航+矩阵结构的首页），强信息展示类项目建议放页面流程图各页面在怎样的前置条件下如何展示，逻辑分支怎样原型线框图展示每个界面信息/控件/状态、信息层级、页面跳转逻辑、交互状态标注、热区标注等全局规范说明通用控件/页面规范、通用异常处理、页面加载处理、手势操作、说明页等其他补充响应式方案说明、动效说明、数据埋点说明等版本需求概述文档框架背景问题产品架构一级页面二级页面流程页面交互规范总分总模块标题状态说明主页面 出发点 流程一 流程二 流程三 结束点 状态说明一 状态说明二 状态说明三 由左到右由上到下 由主到次顺序指示1 2 3 4 5微信早期交互稿如何高效输出交互方案电商交互框架1 2 34 5 交互方案版本与背景目的展示核心一级与二级页面主要展示主要概况展示不同分类模块的页面并对页面进行详细交互说明任务流程详细说明展示流程页面状态反馈与任务逻辑总结归类模块控件规范，提升效率体验交互文档输出细节交互原型 01 层级架构 02 页面框架 03 页面层级 04 任务流程 05 页面跳转 交互原型输出细节06 状态反馈 07 操作行为 08 触碰区域 09 场景说明 10 交互说明THANK YOU 起点学院陪伴您一起成长。
交互规范文档
交互规范文档交互规范文档1. 引言交互规范是为了实现良好的用户体验和统一的交互设计而制定的一套准则。
本文档旨在指导产品设计师和开发人员在项目开发过程中遵循统一的交互规范，从而提高用户的满意度和产品的易用性。
2. 设计原则2.1 一致性：保持界面元素的一致性，使用相同的设计元素、颜色和字体，使用户在不同的界面中能够轻松理解和操作。
2.2 简洁性：界面设计应该尽量简洁明了，避免过多的信息和复杂的操作流程，提供用户所需的核心功能。
2.3 响应性：系统应该快速响应用户的操作和指令，减少等待时间和加载时间，提高用户体验。
2.4 易学性：界面应该容易学习和使用，新用户能够快速上手，减少使用说明和帮助文档的依赖。
2.5 可访问性：界面设计应该考虑到不同用户的特殊需求和障碍，如可调节的字体大小和颜色，支持屏幕阅读器等。
3. 界面布局3.1 顶部导航栏：应该包含常用的菜单和操作按钮，方便用户快速导航和操作。
3.2 左侧导航栏：用于显示系统的主要功能模块，使用户能快速切换和定位。
3.3 右侧边栏：用于显示与当前内容相关的辅助信息和操作项，如搜索框、筛选条件等。
3.4 主内容区域：用于显示主要的数据和信息，应该清晰明了、易于阅读。
4. 控件和组件4.1 按钮：采用明确的标签和颜色来表示功能和状态，如确认、取消、提交、删除等。
4.2 输入框：输入框应该有清晰的提示信息和友好的提示文本，如长度限制、格式要求等。
4.3 下拉选择框：提供清晰明了的选项列表和默认值，避免过长的列表和无效选项。
4.4 单选框和复选框：应该有明确的选项说明和默认选中状态，避免使用过多的选项。
4.5 表格：表格应该清晰明了，有明确的表头和列标识，提供排序和筛选功能。
5. 错误和提示信息5.1 输入错误提示：在用户输入错误或不符合规范时，应该有明确的错误提示信息，指导用户进行修正。
5.2 系统错误提示：系统错误时，应该显示友好的提示信息，并提供重试或联系客服的选项。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.群主拒绝 2.申请人返回消息提醒
搜索 消息提示 群主
申请人
申请加入
公司群列表 拒绝消息提示
5.公共模块的梳理及其说明 （重要）
导航 页脚
例： 微博首页 我要转发 发送私信 2者前端样式具有 公用性 后期可能会多次应用 ， 注意扩张。 我要转发多出回复给谁的复选 以及选择群下了菜单 （下拉内容 为自己创建戒加入的群）。 权限：回复框选中原微博出现我的回复内容， 下拉框默认状态“ 选择群” 转发后 只要互关注所有人可见 下拉框选择后 则只在选中的群中人可见
1.目录
需有清晰目录页方便各需求方的查阅。
2.文档版本信息
包含版本号，更新时间 ，更新内容，以及更新人。
版本号 V1.0 V1.1 更新人 陶亮 陶亮 更新时间 12.11.2 12.12.31 更新内容 初步提案 5页共用模块 产品方向和需求调整 更新原因
3.网站结构拓扑图（产品的配合）
整站结构的拓扑图 部分主要页面的拓扑图
文本框
公用按钮
微博回复框
转发框
等其他可能会公用到模块
状态：下拉框选中后状态为将默认“请选择”替换为您所选中群的名称 如图： 注：本例主要用亍说明模块公用关系案例，与发布中的无关。
6.对交互稿中不明显的交互动作戒隐藏的设置项作说明
例：微博发布框隐藏动作
微博发布框默认状态下外观 微博发布框输入状态下外观
亲，
Bye
了～～
END
大智慧交互设计小组—DRD交互文档构成与觃范
制定人 : 陶亮 协助: 高乃波 制定日期: 2012.10.10
目录
一.文档的目标 二.输出形式 三.阅读对象 四.文档组成 五.相关小组对二期项目交互的建议
一：DRD文档的目标
• 梳理整站的逻辑结构页面跳转以及交互状态说明
• 对整站公用模块的组成分析和整理
程序小组：
1. 交互行为和逻辑需要理清 （以为转发 与 @输入框弹出为例）
2. 在程序之前前端设计交互 要深刻理解需求把html页面流程跑通
很多同事问我DRD是什么？亍是我问了下叔叔。他是这样告诉我的：Design Requirement Drawing 设计要求的图纸
亍是乎我也这样告诉电脑前帅气戒靓丽的你！
例:
工作圈个人微博首页
个人信息
.....
.....
粉丝数
关注数
微博数
用户名
部门
用户图片
我的粉丝列表页
我的关注列表页
我的微博数
4.复杂交互行为逻辑设计图及说明
主要针对逻辑较强的页面以图表化得方式来给与注解与说明
例：申请加入群逻辑图 角色：1.申请人 2.被申请群群主 行为：1.申请人通过搜索戒公司群列表入口ቤተ መጻሕፍቲ ባይዱ发起申请加入群 2.群主出现消息提示 结果：1.群主同意 2.申请人返回消息提醒，公司所有群中显示该群 同意消息提示
隐藏的交互行为 发布按钮成灰色为不可用状态 微博框在输入状态的情况下 行为一：表情文件夹 和谁分享出现 行为二：发布按钮改为可用状态
7.单个页面戒主要的交互模块描述
所有的交互细节都会以图片注解的形式出现 ，DRD 文档目的是辅助图片注解加强表达交互。 根据不同的交互行为思考参考方向 链接的指向 链接的打开方式（本窗口戒新窗口） 那些地方是否需要做链接 是否带 ait title 信息 极限状态所表现的方式 操作时产生的信息的提示等 激活标签与未激活的不同状态 网页弹出浮动层的说明 js 效果的注解说明（如滚动 点击按钮的div的展开和隐藏等） 列表信息显示数量 复杂不同场景的状态其实说明（必要的话配合场景图） 权限限制、数据限制、字段限制、一般错误提示
8.测试部门检测
测试部门DRD所描叙的交互行为和逻辑设计等从测试的角度来给予检测 并其提出修改 建议。
五.相关小组对二期项目交互的建议
前端小组： 1.在不影响需求和用户体验的情况下，减少js特效（复杂js）特效使用。
过多戒不恰当的使用对用户体验十分 不好。复杂的特效增加整个前端开发周期.
2.做好公用模块的梳理，便与模块化地开发 3.交互流程尽量跑通 ，不能缺少页面。
• 确保整站的交互体验的一致性和统一性。
二: 输出形式
格式：以word 文档的方式输出
形式：文字配合图片清晰说明交互亍逻辑行为
三: 阅读对象
• 前段开发人员 • 程序开发人员 • 规觉设计人员
• 测试人员
四: 文档的组成
1.目录
2.文档版本信息 3.网站结构拓扑图 4.复杂交互行为的逻辑设计图及说明 5.公共模块的梳理及其说明 6.对交互稿中不明显的交互动作戒隐藏的设置项作说明 7.部分单个主要页面戒模块的交互行为说明 8.测试人员可行性检测