交互设计文档
- 格式:doc
- 大小:724.21 KB
- 文档页数:17
交互设计文档范例模板-回复什么是交互设计?交互设计是指为用户提供功能的设计过程,旨在提供一种积极参与的用户体验。
它涵盖了用户与数字产品或服务进行交互的各个方面,包括界面设计、动画、人机交互、信息架构等。
交互设计的目标是确保用户可以轻松、高效地使用产品,并在使用过程中获得愉悦的体验。
交互设计文档的定义和作用是什么?交互设计文档是交互设计师编写的文档,用于记录和传达产品的交互设计细节和要求。
它是一个重要的沟通工具,用于确保整个项目团队对交互设计的理解一致,并指导开发人员实现设计师的意图。
交互设计文档包含了一系列的信息,如用户需求分析、用户故事流程、信息架构、界面原型、交互动效等。
交互设计文档的基本结构是什么?交互设计文档的结构可以根据具体项目的需求进行调整,但一般都包括以下几个基本部分:1. 项目概述:介绍项目的背景、目标、范围和关键利益相关者。
这部分内容可以帮助读者对项目有一个整体的了解,并明确设计师的职责和约束条件。
2. 用户需求分析:分析目标用户的需求和期望,包括用户画像、用户痛点和用户心理模型等。
这可以帮助设计师更好地理解用户的使用场景和行为模式。
3. 用户故事流程:描述用户在使用产品时的典型流程和路径。
这可以帮助设计师确定用户需要哪些功能和如何组织这些功能。
4. 信息架构:定义产品的内容组织结构和导航系统。
这可以帮助设计师构建一个清晰和易于理解的信息结构,让用户快速找到所需的信息。
5. 界面原型:展示产品界面的设计和布局。
这可以帮助设计师传达界面的外观和交互细节,以及各个界面之间的关系。
6. 交互动效:定义产品的交互动效,如动画、过渡效果和状态变化等。
这可以让设计师展示产品的动态交互效果,提升用户体验和可用性。
如何编写一个好的交互设计文档?编写一个好的交互设计文档需要考虑以下几个方面:1. 简明扼要:文档应该清晰、简洁,并用易于理解的语言描述设计细节和要求。
避免使用过多的行话和技术术语,以免造成误解。
竭诚为您提供优质文档/双击可除交互设计文档模板篇一:什么是交互设计什么是交互设计用户界面有两部分的设计:交互设计和视觉设计。
在下图中,左边和右边分别是微信的交互设计和视觉设计。
交互设计vs.视觉设计交互设计的产出物是可交互的低保真原型,设计内容包括:oo信息架构;页面布局;o流程跳转。
一、信息架构信息架构,是为了让用户在使用app、软件、网页的时候,能够快速找到自己需要的信息、资料、功能,并且在使用的过程不会迷路。
它有层级、有逻辑顺序、要能反映信息(功能)的重要程度和关系。
信息架构的组成部分:1.组织系统:关注如何组织信息。
比如小说,按篇幅,可以分为短篇、中篇、长篇;按年代,可以分为:古代、近代、现代、当代;按题材,可以分为武侠、推理、历史、言情等等……从哪个角度来组织、到底多少层合适,需要设计者的判断和权衡。
比如当当网的商品组织方式:组织系统2.导航系统协助用户了解他在哪个位置,以及可以到何处去。
比如微信的功能导航:微信功能导航豆瓣的功能导航:豆瓣功能导航3.搜索系统关注用户如何搜索信息。
比如淘宝的搜索:篇二:交互设计求职笔试面试题目某公司:1:列出至少5个国内外对应网站,如googleVs百度。
2:列出至少5个生活中用户体验不方便的案例,如电梯的上与下。
3:选择上述5个案例之一进行分析并解决之。
4:流程题。
在发送邮件过程中,若小于50m,正常邮件界面发送,若大于50m,进入超大附件界面,此时进行判断,条件一:开通手机邮件功能,条件二:安装手机邮件插件。
只有在这两条件都满足的情况下,才可以成功发送,否则不成功。
5:一句话解释下交互设计的意思6:公司想针对于“节假日回家”这一行为开发一款互联网产品,需要写一个项目策划,用户潜在需求,时间和工作人员分工,功能流程框架,网站首页草图和另外某一屏草图。
淘宝1.说一下你觉得用户体验最好的互联网产品有哪些,为什么?2.比较一般的网页翻页设计和移动平台产品的翻页设计。
交互设计文档范例模板交互设计文档是记录和传达交互设计过程和决策的重要文件。
下面是一个交互设计文档范例模板,你可以根据实际情况进行修改和扩展。
**一、项目概述**1. 项目背景和目标简述项目的背景和目标,包括项目的由来、目标用户群体、关键业务需求等。
2. 设计范围明确交互设计的具体范围,包括涉及的功能模块、界面布局、用户流程等。
**二、用户研究**1. 用户画像创建用户画像,描述目标用户的特征、需求、行为习惯等。
2. 用户场景描述用户在使用产品或服务时的典型场景,包括用户的目标、操作步骤、环境等。
3. 用户需求分析用户的需求和期望,以及他们在使用过程中可能遇到的问题和痛点。
**三、设计理念和原则**1. 设计理念阐述交互设计的核心理念,如用户中心、简洁直观、可操作性等。
2. 设计原则列出交互设计应遵循的具体原则,如一致性、反馈及时、防错机制等。
**四、界面设计**1. 信息架构绘制产品或服务的信息架构图,展示各个功能模块和页面之间的关系。
2. 界面布局描述各个界面的布局和元素,包括页面标题、导航栏、内容区域等。
3. 交互元素定义交互元素,如按钮、链接、表单等,并说明它们的功能和行为。
4. 界面流程通过流程图或线框图展示用户在各个界面之间的操作流程。
**五、交互设计细节**1. 交互方式描述用户与系统之间的交互方式,如点击、拖拽、滑动等。
2. 反馈机制说明系统如何向用户提供反馈,如成功提示、错误提示、进度条等。
3. 动画效果如果有动画效果,描述它们的目的、动画类型和持续时间等。
4. 可用性和可访问性考虑用户的可用性需求,如色盲用户、老年用户等,并确保设计符合相关的无障碍标准。
**六、测试与评估**1. 测试计划制定交互设计的测试计划,包括测试目标、测试用例、测试环境等。
2. 评估标准确定评估交互设计的标准,如可用性指标、用户满意度等。
3. 结果反馈描述测试和评估的结果,包括发现的问题、改进的建议等。
手把手教你写出优秀的交互设计文档优秀的交互设计文档对于一个项目的顺利进行至关重要。
它不仅可以清晰地表达设计团队的想法和决策,还能提供一个共享的参考点,以便与开发和其他相关方沟通。
下面,我将为您提供一个手把手的指南,帮助您编写出优秀的交互设计文档。
1.引言在文档的开头,应该包含一个简短的介绍,描述项目的背景、目的和范围。
这个部分可以帮助读者了解项目的背景以及它的关键目标。
2.设计目标在接下来的部分,明确设计项目的目标和预期的结果。
例如,您可能希望通过改进用户界面来提高用户满意度,或者通过改变交互流程来增加转化率。
这些目标应该是明确的、可衡量的,并且与项目的整体目标相符。
3.用户研究4.用户故事用户故事是描述用户在使用产品或服务过程中遇到的问题和需求的简短描述。
通过提供一些关键的用户故事,可以帮助读者更好地理解交互设计的挑战和优势。
确保每个用户故事都具有明确的用户角色、目标和需求,这样读者就能够更好地理解设计的背后意图。
5.信息架构在这一部分,要详细描述产品的信息架构。
包括网站或应用程序的页面结构、导航层级和内容组织方式等。
使用流程图、线框图或其他可视化工具,清晰地呈现出信息架构的层次结构和关系。
这样做可以帮助读者更好地理解整个系统的组织结构。
6.原型设计针对每个关键页面或功能,制作详细的原型设计。
这些原型可以是低保真的草图或高保真的交互原型。
确保每个页面上的关键元素和交互流程都得到详尽的说明与解释。
这样做可以让读者更好地了解交互设计决策的基础和细节。
7.视觉设计如果可行的话,将视觉设计的细节和规范也加入到文档中。
这包括色彩搭配、字体样式、图标以及其他视觉元素的选择和使用。
确保设计与品牌形象一致,并能够有效地传达设计目标和用户体验。
8.交互细节在设计文档的最后,列出关键的交互细节和规范。
这可以包括用户界面上的悬停效果、按钮状态、页面过渡动画等等。
详尽地描述每个细节的目的和行为,以便开发人员能够准确地实施设计。
交互设计规范文档一、引言。
交互设计规范文档是指在设计交互界面时所遵循的标准和规范,它是保证交互界面设计质量的重要工具。
本文档旨在为设计师提供一套完整的交互设计规范,以确保设计的一致性、可用性和用户体验。
二、设计原则。
1. 用户为中心,在设计交互界面时,必须始终将用户的需求和体验放在首位,确保用户能够轻松、高效地完成任务。
2. 一致性,交互界面的设计应该保持一致性,包括布局、颜色、字体等方面,以便用户能够快速熟悉并掌握界面操作。
3. 可用性,交互界面的设计应该简单直观,用户可以快速找到所需功能,避免复杂的操作流程和混乱的布局。
4. 反馈和提示,在交互设计中,应该为用户提供及时的反馈和提示,帮助用户理解当前操作的结果和下一步的操作流程。
5. 可访问性,交互界面的设计应该考虑到不同用户的需求,包括视觉障碍用户、听觉障碍用户等,确保他们也能够顺利使用界面。
6. 简洁性,交互界面的设计应该尽量简洁,避免过多的信息和功能,以免给用户造成混乱和压力。
三、界面设计规范。
1. 布局规范,交互界面的布局应该简洁明了,避免过多的元素和混乱的排版,确保用户能够快速找到所需功能。
2. 颜色规范,交互界面的颜色应该搭配合理,避免过于刺眼或对比度不足的情况,确保用户能够轻松辨识界面元素。
3. 字体规范,交互界面的字体应该清晰易读,避免使用过小或过大的字号,确保用户能够舒适地阅读界面内容。
4. 图标规范,交互界面的图标应该简洁明了,避免过多的细节和复杂的设计,确保用户能够快速理解图标的含义。
5. 按钮规范,交互界面的按钮应该清晰明了,避免使用过小或过大的按钮,确保用户能够轻松点击并完成操作。
6. 表单规范,交互界面的表单应该简洁明了,避免过多的输入项和复杂的排版,确保用户能够快速填写并提交表单。
四、交互设计规范。
1. 导航规范,交互界面的导航应该简单直观,避免过多的层级和复杂的结构,确保用户能够快速找到所需功能。
2. 操作规范,交互界面的操作应该简单易用,避免过多的步骤和复杂的流程,确保用户能够轻松完成操作。
一. 什么是交互说明文档(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. 案例二:iPhoneiPhone作为智能手机中的经典之作,其卓越的用户体验也与其出色的交互设计密切相关。
通过直观的多点触控操作、简洁明了的界面设计以及人性化的交互逻辑,iPhone实现了用户与手机之间的自然互动,提供出色的用户体验。
三、交互设计原则和方法1. 理解用户需求:通过用户研究和行为分析等方法,全面理解用户需求,为用户提供符合其期望和习惯的交互体验。
2. 简洁明了的界面设计:以清晰的界面结构、合理的布局和直观的图形符号为基础,帮助用户快速掌握系统的功能和操作方式。
3. 可用性测试与改进:通过用户测试和反馈,发现潜在的问题和改进的空间,并及时进行交互设计的优化。
四、交互设计影响因素1. 技术发展:交互设计的发展与信息技术的进步密不可分。
新技术的应用,如人工智能、虚拟现实等,为交互设计提供了更多新的可能性。
2. 用户需求变化:随着用户需求的变化,交互设计也需要不断适应。
用户对高效性、个性化、互动性等方面的要求日益提高,交互设计需要加强创新和差异化。
3. 设计思维影响:设计思维作为一种创新方法和价值观,对交互设计产生着深远的影响。
通过用户中心设计、敏捷开发等方法,交互设计更能贴合用户需求,提供优质的用户体验。
五、总结与展望交互设计在现代社会中的重要性不言而喻,它决定了用户与产品的互动方式和用户体验的质量。
交互规范文档交互规范文档主要用于规范和统一人机交互的行为和设计,以确保用户在使用产品时能够获得良好的体验。
下面是一个交互规范文档的示例:1. 页面布局:- 确定顶部导航栏的位置和样式;- 内容区域要与侧边栏保持一定的间距;- 页面底部应该包含版权信息和其他相关链接。
2. 导航菜单:- 导航菜单应该清晰、简洁,并且与产品的功能结构一致; - 用户点击菜单项后应有明显的变化,以提示其当前所在位置;- 导航菜单的子菜单应该以下拉列表或者其他方式展示。
3. 表单设计:- 标签、输入框和按钮应该以清晰的方式进行布局,方便用户输入;- 输入框应该在未输入内容时提供默认提示信息;- 验证错误时需要给出明确的错误提示,并且将错误信息显示在相应的输入框附近。
4. 按钮和链接:- 按钮和链接的样式应该具有明显的点击效果,以便用户区分;- 链接应该有清晰的文字描述,指明目标页面或功能;- 避免在按钮和链接上使用模棱两可的文字或图标,以避免用户困惑。
5. 弹窗和提示信息:- 弹窗的设计应该突出重点信息,避免过多的内容;- 提示信息应该简洁明了,以便用户快速理解;- 错误提示应该清晰明确,避免给用户造成困惑。
6. 用户反馈和确认:- 对于用户的操作需要给出明确的反馈,以确保用户明白其当前状态;- 对于涉及到重要操作的情况,应该进行二次确认,避免误操作。
7. 键盘快捷键:- 对于常用的操作,可以提供相应的键盘快捷键,以提高用户的操作效率;- 快捷键的设计应该与用户的习惯相符,避免与系统快捷键冲突。
这只是一个交互规范文档的简单示例,实际的文档内容可以根据具体产品和需求进行调整和扩展。
文档应该被所有相关人员共同遵守,以确保产品的一致性和用户体验的良好。
交互设计文档范例模板-回复什么是交互设计?交互设计文档又是什么?为什么交互设计文档是重要的?如何为一个产品创建交互设计文档?接下来,我将一步一步回答这些问题,为您详细介绍交互设计文档的范例模板。
1. 什么是交互设计?交互设计是指设计师使用技术、心理学和艺术等多个领域的知识,将人与产品之间的交互进行规划和设计的过程。
通过提供易于理解和使用的界面,交互设计能够提升用户体验,实现用户与产品之间的有效沟通。
2. 交互设计文档是什么?交互设计文档是交互设计师用于记录和传达交互设计方案的文档。
它包含了项目的目标、用户需求、界面设计和功能特性等关键信息。
交互设计文档不仅可以帮助设计师、开发者和其他团队成员对产品的功能和交互进行一致的理解,还能提供对产品设计的参考和评估。
3. 为什么交互设计文档是重要的?交互设计文档的重要性体现在以下几个方面:3.1 明确项目目标和用户需求:通过交互设计文档,设计师能够准确记录项目目标和用户需求,确保设计的准确性和符合用户期望。
3.2 沟通和协作:交互设计文档能够帮助设计师与开发者、产品经理等其他团队成员进行有效的沟通和协作。
文档中的信息能够让各方有共同的理解,减少沟通误差和冲突。
3.3 设计评估和改进:交互设计文档提供了一个便捷的方式,让设计师和团队成员对设计进行评估。
借助文档中的信息,团队可以发现问题和改进设计,以提供更好的用户体验。
4. 如何为一个产品创建交互设计文档?下面是一个常用的交互设计文档的范例模板,包括以下几个关键部分:4.1 项目概述:介绍项目的背景和目标。
描述产品的核心功能和用户群体。
4.2 用户需求:记录用户对产品的需求和期望。
可以使用用户故事、需求列表等方式详细描述。
4.3 界面设计:提供产品的界面设计方案,包括页面布局、颜色、字体等。
可以使用线框图、原型图等工具来展示。
4.4 交互流程:描述用户与产品进行交互的过程。
包括用户进入产品、进行操作和完成任务的流程。
Word交互式文档设计Word交互式文档设计是一种通过利用Word软件的功能和特点实现交互式文档的设计方法。
交互式文档是指读者可以主动参与其中,根据自己的需求进行操作和选择,获取个性化的信息和服务。
在本文中,将介绍如何利用Word软件设计交互式文档,并探讨其在不同领域的应用。
一、交互式文档的概念和特点在传统的文档设计中,读者只能被动地接收信息,而交互式文档打破了这种限制,读者可以通过点击、选择等方式主动参与其中,实现个性化的信息获取。
交互式文档的特点主要包括以下几个方面:1. 多样化的内容展示形式:通过利用Word软件的排版和图形处理功能,可以将文本、图片、表格、图表等多种形式的内容有机地结合起来,使文档更具吸引力和可读性。
2. 灵活的操作方式:Word软件提供了丰富的功能和工具,可以通过设置超链接、目录、书签等方式,实现文档内部的跳转和导航,让读者能够自由选择所需内容。
3. 自动化的反馈与处理:通过设置表单、按钮、宏等功能,可以实现文档内用户输入的自动保存、计算和处理,提升文档的实用性和效率。
二、Word交互式文档的设计方法1. 设定文档结构:在设计交互式文档时,首先需要合理规划文档的结构,包括标题、章节、段落等,利用Word软件的样式功能,可以快速设置并调整文档的格式。
2. 添加交互元素:在文档中添加交互元素是实现交互式效果的关键步骤。
可以通过以下方式来实现:a. 超链接:利用Word软件提供的超链接功能,将相关的内容或页面进行链接,读者可以点击链接跳转到指定位置,以获取更多相关信息。
b. 表单控件:通过在文档中插入表单控件,如文本框、复选框、下拉列表等,读者可以输入或选择相应的信息,从而实现个性化的数据收集和处理。
c. 宏:通过编写宏代码,可以实现更加复杂的交互功能,如计算、数据处理、页面跳转等。
3. 设计样式和布局:为了提升文档的美观性和可读性,需要合理设计样式和布局。
可以选择合适的字体、字号、颜色等,使文档内容清晰易读,并通过合适的排版方式,使页面布局整洁有序。
一. 什么是交互说明文档(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开始高效工作,而不必再思考商业逻辑和需求。
同样,测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试,这也是基于UC和FRD去撰写的。
所以,开发需求分析是个很重要的环节。
那RA是如何来完成需求分析工作的呢?o前期介入,对PD进行开发需求评估支持;o如何写一份交互说明文档参与每次的FRD评审会;o详细审阅FRD文档并不断与PD确认。
对于做这件事情的人来说,足够详尽的FRD是非常重要的。
所以一份FRD虽然是PD产出,但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。
而设计需求的传递,却存在很多问题。
除了线框图,没有“详尽的说明性的文档”告诉他们。
比如:一方面,交互设计师对产品经理说:这块由我们来考虑,你的文档不必包含设计上的说明,这随时会调整的。
另一方面,线框图的评审有时会让RA参与,有时却没有叫他们。
即使叫上了他们,他们也会发现交互设计的需求变化要比FRD变化快。
另外,他们会认为UC不必写太多关于交互设计的需求。
在某个大型项目结束后,作为交互设计师,我进行了一些调研,听听这相关人员是怎么表述问题的:开发部门的需求分析师:o每次变动都很痛苦,设计变了之后,我就要跟着改UC,改截图,有时候UED 改了还忘了通知我们,导致UC有问题……o页面交互的需求容易漏掉,因为UC里面不可能写太多交互方面的东西。
o希望UED能够在提交HTML DEMO给RA时,能同时给出一份页面元素描述文档,需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。
现在RA在这方面花费的时间比较多,经常要和UED去确认这些内容。
产品经理:o前期RA和PD沟通过程中,有很多交互点点不能够明确,比如“默认显示多少属性值”,“标题显示多少字符”等。
在以往的需求和项目中,对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。
既增加了沟通成本又会存在遗漏细节的风险。
PD为了可控性的需求,往往会“越俎代庖”,直接在FRD注明这种需求(对于交互设计师来讲,却又导致没有发挥余地)走访了一些交互设计师后,他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑:交互认为很平常的设计需求,如果不表达出来,还是容易被前端和开发忽略掉。
我经历的一个项目,前端从头到尾更换了三个人,每次我都要重复去讲解下设计需求,讲得口干舌燥。
而且做好后,还需要去验收。
o DRD做为参考手册,一定程度上避免不吻合的问题发生。
o即使有问题发生,也可以作为界面验收时的Checklist。
将“我对A说,我对B 说,A对B说”,转变为“A和B共同参考同一份文档”,减少沟通成本及信息不对称。
o全程影响用户体验(一直到测试,都需要参照设计文档)。
可是以下问题都可以通过一份DRD来解决吗?三. 写什么不写什么?要明确文档的定位,从写什么与不写什么开始,划清DRD以及FRD的边界。
不写视觉规范规格标注这些说明与功能实现没有太大关系,主要是为前端做HTML的时候参考的。
一般视觉设计师会在PSD里标注清楚。
如图:不写功能实现逻辑。
如下图所示,作为DRD,你有必要传达清楚Browse by category区域的设计:链接的可点击性,链接的指向,字符与条目的数量限制等,但是具体二级类目排列是按产品数目排还是按字母排,还是人工运营,是FRD要解决的任务。
那么文档写什么呢?举例子说明下:字符限制提高空间利用率,有时网页上的动态文字需要从数据库里提取部分然后截断处理。
比如下图中的标题和描述。
你的DRD需要传达清楚:1,是否要做限制?2,如果做限制的话,多少字出现截断?截断后是显示为省略号还是不显示?这个汉语设计相对简单,如果英文单词的话,因为是按字符,每个字符的宽度不一致,需要预估,另外还需要注明是整词截断还是词间截断。
链接具体化很多网站都有对搜索结果的筛选设计(refine search),比如aliexpress 搜索结果页左侧。
这块区域的交互事件是非常复杂的。
o类目和属性的不同如何处理o属性以及每条属性显示的属性值的条目是否有显示上的限制?o选中后,被选中的属性值是停留在原地,方便用户记忆,还是放到统一的位置,方便用户统一查看?其他未被选中的属性值是否消失?要确保这些你设想中的复杂的交互逻辑能够被理解被呈现,除了一页页的线框图,你有必要再三让前端工程师和开发工程师了解并达成认知一致。
所以你需要将页面上的关键链接事件标识清楚。
它们有的指向无需刷新页面的交互,有的指向你安排的并非PD安排的某个中间页面(page flow是交互设计师的职责)交互细节说明相信我,我很不愿意写这些东西。
我喜欢在会议室向各位涉众演示我的线框图,我会研究用axure制作各种动态效果,达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时,页面上其他区域也发生相应的变化。
可是,Axure不是全能的。
即使能够表达出来,线框图交付出去,也不能确保其他人都能够一一进行点击尝试。
所以只能在会议室反复讲解,在事后再三检查并敦促修改。
但是当我尝试用下图对这块小小且复杂的区域进行详细说明后,事情变得简单多了。
所以我用节省的时间去写了这份PPT.又如,你可以在这里说明任何你想要的效果。
你的受众也只需要用10分钟时间阅读完毕,标注出与他工作相关的重点,存档并在遇到问题,找不到你人时随时参考。
表单的校验这也是一项不怎么有创意的事情,但是你若不事先想清楚,在项目过程中有点麻烦。
写文档看似枯燥乏味,反过来想也是让你自己再好好思量审核设计本身的关键步骤。
我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏,然后及时优化的。
浏览器的兼容性要求你们的产品兼容所有浏览器简直是梦想,但是有时出于效率的要求,我们必须战略性放弃某些浏览器,比如IE6.:D 。
这个决定谁来做?是前端工程师还是产品经理?还是你——交互设计师?我认为决定权在交互设计师这里,但是他必须和产品经理达成一致,并与前端确认。
你要求兼容的浏览器越多,标准越高,前端的工作量就会越大,测试的工作量甚至也会翻倍。
四. 什么时间交付呢?Heidi的建议:尽可能与你的线框图同时交付,如果你先交付出线框图,在撰写DRD的时候,极大可能会发现问题或产生优化的想法。
但是往往写DRD至少需要1-2天的时间,你不可能让所有下游等着你的工作。
所以:o你可以交付出线框图供视觉先开始。
视觉设计往往会先做风格定位设计,这和交互细节关系不大。
o先交付出已经确定的线框图给前端,然后在1-2天DRD后,若有改动,与前端当面一一确认并一起交付。
五. 如何写DRD?选择最有效率的工具。
我的经验是这个工具最好能够提供清晰的目录导航结构,而且易标注。
word确实是个写文档的好工具,不管你信不信,反正我是信了。
建立固定的目录结构下图仅供参考。
具体里面的细节,就不一一罗嗦了。
六. 重要的原则准备写DRD的朋友,请认识清楚此文档真正要解决的问题是什么?如果是解决沟通偏差、需求遗漏、沟通成本高的问题,你在项目里没有出现过这种问题,各合作方也反馈良好,那么这个文档就无需写。
如果是解决对设计需求进行存档,便于后续人员改版时查看的问题,则又是另外一回事(经验证明,过去的DRD确实能够在改版时起到一定的帮助,在我离开原项目很久后,新的设计师还找我要过相应项目的文档,了解过去的设计逻辑)。
o不是为了写文档而写文档(而是为了解决问题)o适合于项目、合作方(大项目有大文档,小需求有灵巧的解决方案)o工具不是问题(易传播,易标注,成目录即可)o模版不是问题,大家看明白就可o完美的文档无法取代面对面的沟通(评审会和讨论不会因为文档而减少)o需要在实践中不断改进七. 谁来写?我建议由交互设计师发起,但是由前端工程师进行修订,再传递给开发工程师。
有很多需求,交互设计师只要求实现即可,但是他可能并不在乎是前端实现还是后端实现。
前端工程师对DRD进行把关和修订,能够将设计语言转化为工程师能够看懂的语言,且能够划定与开发的实现边界。
八. 与其他产出物的关系项目中交付物对应不同的使用角色,如下图所示:但是有个问题是,虽然DRD的目标受众有开发和测试,但是让开发工程师同时参考那么多文档是不现实的,所以仍然是开发工程师的接口人,也就是事实上的RA需求分析作为需求整合传递的角色,将商业需求和设计需求,传达给具体的执行开发工程师与测试工程师:【总结】对于坚持撰写DRD的我来说,DRD的好处自己当然是明白的——在撰写过程中重新梳理设计逻辑,优化设计;降低沟通成本等等。