如何制作美观的设计文档交互设计
【简介】感谢网友“南柯孟”参与投稿，下面是小编为大家整理的如何制作美观的设计文档交互设计(共7篇），仅供大家参考借鉴，希望大家喜欢，并能积极分享!
篇1：如何制作美观的设计文档交互设计
前言：最近准备做一个设计文档的分享，但是一直没有时间整理好keynote，这里先分享一个设计文档模版，以及模版中每个元素的使用理由与方法，之后的设计文档分享中，会加入更多的设计文档案例来分析讨论。
Here we go.
作为一个交互设计师，我们要全局掌握产品的背景，逻辑，用户体验。但是，我们不能忽略设计过程中一个很关键的步骤，设计输出。
如果我们用email或者其他大海报的方式来输出设计文档，有没有产品经理会抱怨说看不懂？有没有开发抱怨使用过程中效率低？在我之前的工作经验中，我一直保持用一种方式来输出设计文档，InDesign + PDF，在之前的产品同事与开发同事得到的反馈是好的，这里也希望分享并讨论这个方式是不是适合我们腾讯的产品开发节奏。
用InDesign输出PDF设计文档的好处有不少，我这里先列举几点：
1，设计文档规整，阅读效率提高。
2，设计文档适合打印，在很多评审场合阅读纸张更有效。（同时请注意环保）
3，一个部分讲一个故事，清晰明确，而不是把所有场景都集中在一页上。
4，InDesign可以设置文字，图片格式，通过style来管理，大大提高修改设计文档的效率。
5，设计文档简洁美观，让阅读者轻松愉快。
6，笔记，交互形式，配合设计图的方式，全面，内容集中，不需要额外注解。
7，可以配合视觉设计进行文档输出，作为一个完整的reference。
8，有助于知识保存，知识传播。
9，设计师创建并维护设计文档贯穿整个产品设计过程，主人感，成就感强。
最后强调一下，这里指的设计文档是唯一输出，贯穿设计师所有工作过程中，而不是产品设计完成后的总结沉淀。
这个设计文档模版也是多变的，设计师可以根据自己产品的需求灵活变动，请不要拘泥于模版。
Now let’s start digging.
这是第一页：文档封面，文档封面是每一个文档的第一个展示，我们应该清晰的传达这个设计文档的基本信息。在InDesign中，这页的顶部可以设立为主模版，支持整个文档。
A.文档生产方logo，展示设计文档来自哪个团队。
B. 团队或者项目名称，再次展示文档信息。
C. 主标题，这个标题是产品的名称，应该贯穿整个文档。
D. 版本号很关键，设计文档需要有严格的版本控制；修改时间可以告诉读者，这个文档的最近更新情况；当然，这里还可以根据需要加入设计师名称，ID，Email信息等。
E. 页码需要在一个显眼的位置，特别是在远程会议的时候，页码会是一个重要的定位信息。
F. 第一页不要太多信息了，要让读者集中注意力，只放一个标题是好主意，有时F与C会是一样的。
这是第二页：修改记录，修改记录对于持续更新的产品设计文档是不可或缺的，开发，产品经理，与设计师能根据修改记录快速了解每个版本修改的内容。例如例子中，7月12日修改了6个点，如果没有修改记录，开发可能需要1个小时看完100页的文档才能了解哪些地方被修改过，
A.修改记录应该为文档的第二页，关键，价值大。
B.内容区重点为修改日期，与简短的修改内容，修改内容应该首先点明版本号，然后把修改的部分与页码写出方便读者查阅。
这是第三页：内容目录。
A. 内容目录是整个设计文档的索引，放在第三页的重要位置。
B. 在用InDesign生成PDF后，请使用PDF把这页的每个索引编辑为链接，这样读者就可以方便在这页直接跳转到需要阅读的页面。
这是第四页：分段。在完整展开设计文档前，要构思好每个段落应该讲一个什么故事。无论多么复杂的产品，都可以根据功能，场景，用户群体等因素划分为数个故事。在每个设计文档中，我们都应该思考怎样划分故事情节给到我们的产品经理，开发，设计师，管理者，以及适应用户群体，理想状态，故事的划分是通用应对所有人群的。
A. 就像模版中所说一样，一次只说一个故事。
这是第五页，内容。内容区展示的内容丰富多样。这里我只给出了款式，分析了款式后，再补充一些可以在文档中加入的内容。
A. 副标题，也是故事名称。例如一个面向用户的产品的总标题为QQ美好生活，副标题会是一个清晰的故事子集，例如美好生活之夏日健康饮品。
B. 每个设计图需要配标题，在远程会议中，这个标题配合数字的方式可以极大提高交流效率。
C. 在InDesign中，我主要使用两种设计图方式，一种是在InDesign中直接生成设计图，一种是把PSD源图直接放入InDesign。第一种的好处是，所有设计图在InDesign中，可以统一设定风格，统一修改。第二种的好处是，PSD可以输出更清晰的交互，视觉图，而且InDesign可以记录路径，以后的修改中，可以直接修改源PSD，然后刷新InDesign文档就可以刷新所有文档内PSD图。
D. 笔记区适应在每个需要笔记的页面，非常重要，可以极大减少产品经理，开发，设计师持续互相问问题的时间。
E. 笔记中也可以录入对产品经理，或者开发的问题。在每次评审的时候，我会在文档中直接标记需要注意的点，这样会后设计方的修改记录就直接产出。例如：“这6个图需要在2秒内拉出来，需要与开发确定”。
Wrap up – - – - – - -
今天只给出了基本的模版和InDesign设计经验。设计文档还有很多功能。例如，可以和视觉设计师配合，在一个文档内同时记录交互和视觉设计。甚至可以在一个文档内同时记录交互，视觉，前端开发code做整体文档。
生成PDF后，可以放入iPad等移动设备，可以帮助你在5分钟内，与老板散步中描述几个好点子。
设计文档的难点是开始建立所需的细致时间较多，但是文档架构一旦搭好，维护的精力小于预期，以后的每次输出，制作的设计师以及阅读的产品经理和开发，都应该是心情愉悦的。：）
Wrap up – - – - – - -
以下是以前我工作中产出的设计文档案例，请参阅 ：）
谢谢阅读 ：）
篇2：关于“交互设计”交互设计
记录刚才和HEXIAO闲聊中，说到的一席话，
1、以前的”人机交互”更偏向于”机器”。
更多的是考虑”机器”能提供什么给”人”，如何提供。如，戴国忠老师一直在致力研究的”手写输入“。
2、最近两三年我们很欣喜的看到了很好的变化，我们的”人机交互”慢慢更偏向于”人”了。
“人”需要什么，”人”需要”机器”做什么变得越来越重要。因为真正的瓶颈已经不在于”机器”的技术问题了。
3、其实，一直以来在人机交互领域其实都是这么两个流派。
计算机相关学术的人比较偏向于”机器”，心理学相关的都比较偏向于”人”。
我个人相对比较主张：基于人的交互研究可以相对快速的推动社会的发展，也可以更好的推动”机器”的进步。
4、其实我们现在都在解决的问题是”如何让机器更加聪明起来，如何让机器有更多的’思考’能力”。
实际上，我认为”如何更好的让人互动起来，如何更好的提炼人与人的互动信息”反倒比这一切更加的重要。
5、对于”交互设计”，现在有三种层次的认识。
第一种：视觉交互
“有一个提示窗口要弹出来，是从左边弹出来好呢，还是从右边弹出来好? 还是下边？”
我一直认为这应该是视觉设计的范畴，而非”交互设计”的主要工作。
6、第二种：流程设计
现在有”打电话”这个任务，设计一种什么样的流程和互动方式让”打电话”这个任务可以更加方便快捷并符合用户习惯的完成。包括某个按钮要放在什么地方，用按钮还是用链接。
我个人认为：这部分工作是”交互设计”的具体”执行”阶段。
7、第三种：机器应用
“有什么样的处理方式可以使机器与人的交互更加的顺畅和快捷”。
如，ajax就是一个极其有价值的人机交互创新。包括Flash, Java, VC..
8、我认为还有一种：人与人的交互
“如何更好的促进人与人的交互，有什么更多的应用方式”。
比如，设计Digg这种信息的交互方式。
9、实际上现在的搜索引擎都是很初级的很笨的搜索引擎。
我们可以有什么更多的人与人的交互方式、人与机器的交互方式可以创新呢？
…
我们现在很多的”交互设计师”在做着”某个窗口是从下面弹出还是从右边弹出”、”某个功能是用按钮还是用链接”的工作；也有很多”交互设计师”在做着”某个流程先让用户做什么再让用户做什么”；很少有”交互设计师”在思考着”除了ajax以后还有什么更多的技术应用呢？”。
谁在思考”如何在人与人的交互上做更多的创新……”？
做到什么程度”交互设计师”才可能像”产品设计师”一样颠覆一个产业呢？
值得所有”交互设计师”思考…
PS –
HEXIAO语：
交互设计师的关注点是什么?
决定一个Button放在页面的什么位置? 决定哪个流程的设计更合理? 还有更多吗?
事实上在应用层面的思考决定交互设计师同样可以关注架构(Architecture)和产品形态(Ecosystem), 在这个方面也可以展开.
网友评论(17)
子狼手记- 07/05/17 8:53 PM
开阔了眼界，展示了更广阔的前景。
交互设计师任重道远。
青椒土豆丝- 07/05/17 11:13 PM
有启发，三种层次。
为什么我老感觉“交互设计师”做着“产品设计”的东西呢？
yellow- 07/05/18 12:52 AM
感觉自己要学的东西太多太多
GOVO: links for -05-17- 07/05/18 6:23 AM
[…] 白鸦 » 关于“交互设计” 谁在思考”如何在人与人的交互上做更多的创新……”？ 做到什么程度”交互设计师”才可能像”产品设计师”一样颠覆一个产业呢？ (tags: reading) […]
dte- 07/05/18 9:36 AM
上周五在北邮听了戴国忠老师的演讲了呢 确实是围绕他那些个手写输入设备来说的
工业设计出生的确实适合做交互设计…挺赞同人与人交互这点的，是个需要突破创新的点
myspace- 07/05/18 11:18 AM
与青椒土豆丝有同感
范畴的大小，领域促就了职位名称不同
Amy- 07/05/18 11:23 AM
交互是什么，你看我一眼，然后我也看你一眼，这样就交互了，
呵呵，听一个朋友说的，感觉很有意思。
awflasher- 07/05/18 12:22 PM
对了老白，告诉你一个好消息。
你的blog是我见过为数不多的拥有Compete Rank的中文个人blog。
www.awflasher.com/blog/archives/888
Compete Rank here ^_^
千鸟- 07/05/18 1:20 PM
有点不同意见
1. “视觉交互”也应该属于交互设计师的职责，页面内的交互技术含量不比流程低，尤其是现在的ajax技术应用，“视觉设计”不应该涉及行为设计。
2. “交互设计师”从定义上就决定了不可能颠覆一个产业，如果具有了这种实力，并且能够实施，那么他做的事情一定不局限于“交互设计”。
xiaoxiao- 07/05/18 3:38 PM
同意千鸟的第一点，视觉考虑的是更好的呈现产品
第二点是我觉得是一个老总考虑的事了，呵呵。
jaryxie- 07/05/18 7:24 PM
我觉得这都是产品设计里面的角色分工问题,没必要整天在划界线和职责,合作应该是无间和高密度的,不是相互分割的关系,视觉图形设计在产品设计中承担界面的最终呈现,是相当重要和易感知的.是对交互的提炼和理解继承的过程,不是单纯的你管那,我管这,最后凑成一个产品的概念.
交互和信息呈现有很必然的联系,非要以职位来划分,是很可怜的事情.
jaryxie- 07/05/18 7:32 PM
交互设计更多处理交互对象间的关系和逻辑,以及交互的方法,是产品设计中一部分,任何一个角色和职位在产品设计中都不具备颠覆一个产品或者产业,如果非要那样认为,那只能自以为是.
noway- 07/05/18 10:40 PM
“我认为还有一种：人与人的交互
“如何更好的促进人与人的交互，有什么更多的应用方式”。
比如，设计Digg这种信息的交互方式。”
在流程里面，很自然的地，包含人与人之间的信息交流，交互设计中，在设计流程时，本身就很自然需要考虑到人与人之间的交互。
人为进行这种划分，没有什么意义，除了制造一些“错误”的分类。
hexiao- 07/05/21 10:31 AM
建议白老师把交互设计和交互设计师稍做区分…
mihu- 07/06/16 8:04 PM
前段时间，学校有个心理系的去cmu学习交互设计，
当我们谈到交互设计时，国外更多的计算机和心理的在做，
他们不太认同设计作的是交互设计，可能还是归在界面设计师！
现在也不清晰交互设计的定义。
来自：uicom.net/blog/?p=614
篇3：方便和交互设计
很多设计师都会遇到这样的问题，一个产品会有很多种方式去包装，其中包括很多功能和很多体验。功能越多会被认为越实用，体验越好会被认为越方便。
方便和实用之间到底是什么关系，设计师应该关注的是什么？有两点，一点是技术体验，一种是交互体验。作为一个交互设计师，要去考虑的更多是体验的问题，而并非功能的问题。
举个例子，在一个移动媒体上需要安放日历的插件，设计师会去考虑在基础的日历功能上要不要加上农历，这个对于中国人来讲很实用，然而农历这个功能涉及到了技术的开发，算是一种技术瓶颈。当你发现技术无法完成你的要求时（当然农历这玩意儿对于中国山寨机来讲算是小菜一碟），你的日历插件依然是一个平庸的产品，这说明你没有关注技术体验。但是你换个角度来看，如果把日历上以星期一开头还是以星期天开头作为你设计研究方向的话，你会发现，中国人更习惯于星期一开头，这个在体验上给用户带来更多的价值，而且也不算是一个技术瓶颈，你也满足了技术体验和交互体验的结合，
说到这里，大家应该明白方便比实用更体现设计的价值。
刚才说的山寨机就是把一大堆功能都罗列在里面，虽然很实用但是每个都不好用，种种问题还是让很多人选择了高端的品牌，高端的体验，这就是设计的力量。
作为一个设计师，不要一直依赖自己无法掌控的功能去实现自己的设计，老是天花乱坠的想着各式各样的功能去满足用户，从商业成本和用户满足感去讲都不是一个好的设计。越来越多的交互设计师感觉到自己没有什么作品，那是因为你依赖太多不是自己开发的功能，往往产品中只有你一点想法的影子，产品并没有被你的设计情感化。
实用并非等于方便，但方便一定是实用的。
文章自“折折熊de交互论”（www.jojobox.cn）
篇4：帮助是什么交互设计
耶和华说：“看哪，他们成为一样的人民，都是一样的言语，如今既作起这事来，以后他们所作的事就没有不成就的了，我们下去，在那里变乱他们的口音，使他们的言语彼此不通”——创世纪 11:6-7
我觉得有时候把概念扩大化对问题的理解并没有益处。比如说帮助，从广义的去讲，很有可能我们会把导航也说成是帮助，把整个网站都说成是帮助你也不能说它错。于是讨论导航的时候，会说：瞧，其实整个网站就是一个导航。（比如我之前写的“导航设计与信息架构”好像是陷入了这个怪圈）
所以我在写本文的时候，想搞清楚帮助到底是什么。如果连帮助是什么都不知道，那还谈什么设计有效的帮助呢？
因为在书友会之前我写了一篇关于帮助的文章，里面提到了编程语言的帮助手册。自然而然的去思考为何编程语言需要学习并且需要帮助手册呢？因为计算机的“语言”和人是不一样的，同时设计这个编程语言的人，和你的语言也不一样。所以就让我想到了文章开头的巴别塔的故事。
语言的差异，文字的差异，再延伸到文化、环境的差异。最后归结到对于设计影响最大的因素：心智模型。
忽然想到这个问题：如果你为自己设计一个产品，是否需帮助？不需要，因为你设计的就是你想的。
这个问题的答案让我震惊和兴奋。似乎终于抓住了什么。
我脑海中不断涌现出日常设计过程中用户提的问题：“为什么会这样…”、“为什么不是这样…”、“为什么不可以…”，我听到自己的声音默默地回答：“因为…”、“因为…”、“因为…”。
为什么我不写这个用户常问的问题：“怎样…”，因为他心里其实在问“为什么不可以…”。
原来帮助就是我告诉他们为什么。而这个为什么的存在，就是因为心智差异。
于是我得出了这样的结论：帮助是由于设计师与用户的心智差异而存在的一种沟通，因为心智差异不可避免，所以必然会有这样一种沟通。这种沟通，可以说是告诉用户，我是怎样以及为什么要这么设计。
我们不是要设计有效的帮助吗？因为帮助是一种沟通，所以设计有效的帮助等于进行有效的沟通。
余世维写过一本书叫做《有效沟通》，在里面可以学到很多东西。举一个例子：沟通的双向性。
在Google的帮助中心里面，每一项Q&A，最后都会有一句“以上信息对您有帮助吗？”用于统计和改进帮助的内容。这就是沟通的双向性。
融会贯通，一通百通。
文档、情景、演示，都是一种沟通形式。我还曾提到关于帮助的渠道问题，不就正是沟通的渠道吗？
有效的沟通，就是有效的帮助。
来自：ucdchina.com/blog/?p=419
评论(14)
Angela(1楼) - 08/04/07 10:46
非常同意。很多问题都是出在沟通上，也就是心智模型的不同。
阿卡(2楼) - 08/04/07 10:51
ms 耶和华不咋厚道。。。
在Google的帮助中心里面，每一项Q&A，最后都会有一句“以上信息对您有帮助吗？”用于统计和改进帮助的内容，
这就是沟通的双向性。————啥人会用主动沟通这个？这样的沟通得到的也只是特定人群的答案吧~
JunChen(3楼) - 08/04/07 16:08
@阿卡 那只是一个双向性的例子。不是那种指令、指示型的沟通方式。而沟通的渠道有很多种。
zaku(4楼) - 08/04/08 8:58
哎~沟通简直是太重要了！
snail(5楼) - 08/04/08 19:35
对这句话
|为什么我不写这个用户常问的问题：“怎样…”，因为他心里其实在问“为什么不可以…”。|
感触很深。
用户很多时候不了解功能，所以会给自己一个想象的空间，认为某物会怎样（意思上大概就是“心智差异”，不太了解这个词，所以就这么理解了）。如果不是，这个时候才会有“想知道”的需求。
恩，沟通也是这样，大家都明白的部分是不需要沟通的，需要沟通的是不明白的部分。
tonyzhu(6楼) - 08/04/09 14:23
我认为帮助的沟通对象不是设计师和用户，是产品本身和用户。帮助是为了解决用户使用产品遇到的问题。用户使用产品遇到的问题不一定是设计师与用户心智不一致所产生的，在很多情况下，一个产品的用户是众多的，且每个用户的心智都不一样。我想好的帮助应该是让用户理解产品，并不断引导用户对产品建立新的心智模型。在整个过程中，沟通是双向的，但多数情况下，双向的沟通是设计师预先设计反馈用户的信息。从这个角度讲，我认为实际上在用户使用产品时，他们是在与产品进行沟通。帮助是其中的重要环节，它是设计师总结与用户沟通后的心智模型，并可以不断进行修正。
IanLiu(7楼) - 08/04/10 2:35
我以前遇过这样一道问题，什么样的帮助文档才是最好的？ 答案有点无厘头：就是不需要帮助文档。
无论是沟通还是心智模式的分析，要做到真正“有效”还是挺不容易的，都需要学习和积累 ，像心理学学生要变成心理学专家该需要经历多少案例分析呢？
则名(8楼) - 08/04/10 23:55
勤于思考，乐于助人。
八个字送给UCDChina的成员，哈哈
jerry(9楼) - 08/04/11 0:17
我参加了上海这边的书友会，会后我也写了点关于“帮助”的笔记，见我博客地址：
www.novastudio.cn/blog/post/30.html
xw(10楼) - 08/04/11 9:31
产品的界面本身就是设计师与用户的沟通，如果沟通出现了一些问题或者不能很简单的说清楚，那么就需要帮助来解围了。
行走天涯(11楼) - 08/04/11 12:41
整个产品“走”一遍 把每个过程有序地精简一下 就是帮助
行走天涯(12楼) - 08/04/11 12:42
帮助 的目的 就是让大家会用
JunChen(14楼) - 08/04/11 13:20
@jerry 我对“用户在人机交互过程中的任何一个提示，一个说明都属于帮助的范畴。” 感到十分烦躁。但我并不反对这样的论点。
@xw @tonyzhu 我同意这样的观点
篇5：归属感交互设计
本文想讲述的是一些让用户觉得是属于自己的产品及由此产生的设计诉求，
引子
经过了很多轮的产品PK，很多轮的设计PK，很多次的版本检查，然后很欣慰的将一个产品呈现在用户面前，让用户去试用。
“界面很漂亮”，视觉设计师很高兴。
“这个功能我很喜欢，很体贴哈！”，产品经理很欣慰。
“恩，这里应该就是这样！”或者没有什么评价，交互设计师会感到宽慰。
……
“但是，我不觉的这是属于我的。恩，不太好说，感觉不是我自己的软件。”用户的这一句评价虽然并不会影响这个产品最后发布、获得一个好的市场份额或者最后的经济效益，但是，却让我一直揪心。
IPod
犹豫了很久，终于买了IPod classic。毕竟对我而言，价格还是很贵的。但，实在是爱不释手。
当经过一段时间后，我的IPod中装满了我喜爱的歌曲，还有我精心维护的专辑封面。我去哪里都会带着它！很多人喜欢它是因为它有漂亮的外观，人性化的设计。但如果别人送给我的IPod，并不会让我如此的喜爱它，有部分原因是：
1、不是我花的钱，没有了那段买与不买的死去活来的内心挣扎与纠结
2、没有我仔细挑选过的歌，没有我精心维护的专辑封面
Nokia
它确实是一个即帅气又好用的手机。
当其中装载着你的朋友的电话号码时，当其中存满了BF或GF给你发送的甜言蜜语时，你会感觉到这是你的手机，而不是其他任何人，也不会愿意轻易丢掉。
场景一：在大学校园中，我们只有在上公开课的时候才能见一面。但我很关注你，希望知道你平时都在做什么，是否能交流一下，是否能见一面……可是班级名单上只有你的姓名和邮箱，
facebook让我找到了你，于是每天我都去那里看你。
场景二：开始自己的face book空空如也，但慢慢了有了自己的好友圈子，有了好友的动态，有了自己和好友发表的文章、照片。和好友一段时间才见一面，但却天天在facebook上互通信息，见面后也更加亲近。
当然facebook远远不是那么简单。
大概的想法
一个产品通过合适的行销手段或者强大的平台，让用户有了第一次试用（Trial）的理由；当用户再次来使用的时候（Repeat），往往因为它确实满足用户的需求，比其他同类的更加好用、漂亮等。
这样的产品应该已经算是很好的产品了，但是却没有让用户形成忠诚（Royal）。
朱成先生在其《产品经理手册》一书中认为，Trial 、Repeat、 Royal是行销中品牌奠基经典的三个阶段。而用户拥有归属感是形成忠诚的一种表现形式。最近也看到有关“成瘾性消费”的一些观点，按照李光斗先生（中央电视台品牌顾问、著名品牌战略专家、品牌竞争力学派创始人）的解释，归属感是“成瘾性消费”的“秘密之一”。这些都是可以借鉴的宝贵经验，但叙述的角度更加偏重于行销上。
Donald Norman在其著作《情感化设计》一书中提到三种水平的设计。这本书大概是4年前看的，但现在我能记得的还是我当时最感兴趣的那三个水壶。Norman提到第三个水壶，不能用，但很有趣，让他印象深刻。而对我而言，一个水壶的复杂操作让我花费了很多时间去理解，另一个水壶完全不能用引发了我的好奇，这也说明当我投入感情了以后，这些东西给我印象要远远大于其他的。
思考一个巧妙的方式，使用户在产品上投放自己的感情，甚至可能有些是挫折的，会让用户印象深刻，这有利于产生归属感。
网页或软件，不会像可买卖的商品，它让用户产生归属感的难度更大一些。以前yahoo和AOL曾经让用户自己去定制网站的首页，用户花费的心思和感情，但是依然不可能产生归属感，因为用户只是选择了的收取信息的数量和类别，这是单向的。facebook的首页不仅可以选择接受信息的种类，而且这些信息是可以和用户本身互动的。它不是八竿子打不着的人的信息，而是和我拥有共同爱好和共同朋友的人的信息（当然如果是朋友的朋友的朋友的信息，可能就没那么好的效果了），并且提供了及时互动的操作，例如“回复”、“回送”等。这是双向的，并且是用户自己去维护的。
所以，一个属于用户自己的产品需要特别留意的设计诉求是：
1、挖掘用户目的需求，并思考合适的方式，让用户对产品能投放自己的感情。
2、提供互动的方式或平台，帮助用户自己去维护核心的需求。
来自：cdc.tencent.com/?p=939
篇6：邮箱交互设计
如今，互联网上免费邮箱已经成为用户必备的一个工具之一，每个用户都有一到两款钟爱的免费邮箱。同时作为邮箱的产品设计师，他们也会根据自己用户的习惯给出不同的交互方式。
本次我们的交互吱吱会，就是来探讨免费邮箱，不同邮箱的用户不同，设计师会采取什么样的方法来处理用户体验和产品利益需求的平衡。
一.什么是传统邮箱?电子邮箱?免费电子邮箱?邮箱的概念设计?电子邮箱有哪些特点?
传统邮箱泛指邮政机关设置于路旁及公共场所接受公众投寄邮件的收信设备，尤其指公用邮筒。
电子邮箱是通过网络电子邮局为网络客户提供的网络交流的电子信息空间。收费纬度分两类：免费邮箱，收费邮箱。
免费电子邮箱是电子邮箱的一种。免费。
邮箱的概念设计：能将指定信息在指定的时间发送给指定人的工具。
电子邮箱有哪些特点?快速，安全，完善，经济
▲《龙纹身的女孩》中电子邮件给破案提供能很多方便
▲免费邮箱的用户需求
二.有哪些电子邮箱?用户为什么要用他们?
国内使用量大的免费邮箱是163邮箱，126邮箱，QQ邮箱，雅虎邮箱，新浪邮箱，Gmail邮箱，yeah邮箱，等等。用户在选择免费邮箱时会考虑五大因素：1.容量和附件 2.安全性 3.速度 4.界面和功能 5.历史
1.容量和附件
用户的需求不仅限于只发送文字，图片和office文件会让他们的工作更加有效率，所以容量的需求一直存在，但是互联网早期由于带宽等因素，邮箱允许的发送空间都是很小的。这时，那个邮箱容量大，附件大，用户就会选择哪个。163，126等就是典型。QQ邮箱也出现了超大附件。
2.安全性
我的邮件会不会被人看到了，我的信息会不会被盗用呢?这些都是用户担心的。在线下，被非指定人未经允许的情况下看信件是要承担法律责任的。但是线上的法律显然没有这么完善。所以用户会更加的喜欢用大牌互联网公司的产品。
3.速度
是不是我发送完邮件之后对方什么时候才能收到?一分一秒都是宝贵的，那个邮箱快速就用那个邮箱。
4.界面和功能
随着互联网用户现在的个性化需求的不断增加，邮箱界面是不是喜欢也成了他们选择的一个因素。同时能和手机绑定，第一时间收到邮件，等很多个性化的需求也在不断的影响用户的选择。
5.历史
用户不愿意经常更换自己的主要邮箱。因为里面有很多自己的邮件历史，同时用户不喜欢花时间去学习另一款邮箱的使用方法。
三.邮箱的用户体验设计
我们选择了
outlook
163邮箱
新浪邮箱
Gmail
qq邮箱
豆邮
这6种邮箱给大家一一挖他们的体验设计
1.OUTLOOK
概述：最注明的收费电子邮箱，office软件，所有的邮箱的鼻祖，所有的免费邮件的邮件功能都是在它的基础上做减法。
用户：公司员工
特点：邮件功能最齐全，功能强大，安全，但是安装繁琐，界面复杂，不方便学习
设计：为了安全考虑公司会强制员工使用该邮箱，所有视觉设计感不是很强，设计时着重考虑功能 使用方面的体验，以及类目的规划是否方便查找到。
▲强大的功能是其他免费邮箱无法做到的
2.163邮箱
概述：国内最老牌使用量最大的免费邮箱，是该公司的起家产品，
用户：年龄层偏大，用户大多30岁以上，都是早期的互联网使用者。已经对邮箱产生了很深的交互习惯，不方便改动
特点：国内使用量最大的免费网站,容量初始2G，安全，快速，
设计：界面体验很简洁，用户使用习惯早已形成，不方便更改，对于滑动显示的效果不敏感，所有的滑动都没有直接显示操作。页面内操作总是出现。默认14号字，对大龄的用户很适用。
▲网易邮箱没有划过显示操作的地方，即使是有向下箭头，也要点击之后才会展示内容，而不是年轻人想到了划过就显示。
3.新浪邮箱
概述：国内老牌使用量大的免费邮箱。
用户：早期互联网使用者，年龄层30以上居多。
特点：界面信息量多，但有很好的区分。
设计：考虑商业价值和用户体验的融合，使用户不会疑惑，能自动加标签。和outlook保持了界面的一致，list和邮件详情在同一个页面。
▲三屏的效果和outlook一致，同时有自动标签，方便用户辨认
4.QQ邮箱
概述：腾讯近来最成功的产品之一，由于他有天然的入口优势，和能留得住用户的体验，很快拥有了大批用户。
用户：绝大多数为QQ用户，用户把QQ邮箱当娱乐或消遣，年轻用户居多。
特点：面功能简洁， 其他功能比重增加，漂流瓶，微信，贺卡。使得用户来邮箱不是来写邮件，而是玩，写日志等
设计：QQ用户很多，风格可以靠换肤实现。由于这个产品有太多的非邮件价值，一定要设计好邮件功能的比重，做好清晰的导航。
▲清晰的导航的存在，是用户在众多产品的干扰下能够第一时间知道自己要干什么。
5.Gmail邮箱
概述：google自己研发的免费邮箱，吸引了很多谷粉，技术，IT使用
用户：白领等办公室人群，该邮箱尤其吸引了很多技术人群，因为他们多为google的狂热fans
特点：界面功能简洁，交互方式更加新颖，出现很多划过显示的操作，很难适应。UI不方便理解
↑ 五角星知道什么意思吗?标签呢? ↓ 感叹号知道什么意思吗?
▲打勾之后很多批量操作才会出现。用户在不够勾的情况下不知道能做什么。
6.豆邮
概述：豆邮是豆瓣自己的一个类似邮件的工具，能给指定人发送指定信息。仅此功能。
用户：豆瓣用户，小众，文艺青年。
特点：豆瓣用户用于互相信息传达的工具，风格和豆瓣保持一致。功能极少，不能群发，转发，抄送。
设计：邮件基本功能能够实现，页面风格统一。
网页设计教程
四. 未来
随着无限端产品使用，用户对无限端翻阅邮件的需求也在不断的增加，有人说邮件一次，有人说邮件还是片蓝海。但对于我们来说，设计无止境。
只要对用户有足够深刻的了解和细分，产品保持一致性，界面风格控制好就足够了。
最后引用一句话来结束这篇文章
“我们不缺进来的用户，通过优秀的体验留住用户，才是我们的重点。口碑是可以通过优秀的产品体验积累起来的。”——马化腾内部讲话
该文章有张科编写，内容由此次交互吱吱会成员吕俊，金晶，张科提供
篇7：如何写一份交互说明文档交互设计
离开交互圈已经有段时间了，但由于博客还在，还是能够偶尔收到一些邮件，上周有位同学问我：我在求职，我看到很多招聘说明上需要交互设计师编写界面交互设计文档，请问界面交互设计文档是什么文档？怎么编写呢
这让我想起来2009年自己在项目里也大力推行过交互说明文档（在下文中，简称为DRD），格式倒没什么限制，交互设计师自己写到界面上也行，单独文档成文也行，总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来，降低项目里的沟通成本和风险。今天整理电脑，翻出以前的PPT，分享之。
这将涉及到几个问题：
一. 什么是交互说明文档（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是如何来完成需求分析工作的呢？
前期介入，对PD进行开发需求评估支持；
参与每次的FRD评审会；
详细审阅FRD文档并不断与PD确认。
对于做这件事情的人来说，足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出，但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递，却存在很多问题。除了线框图，没有“详尽的说明性的文档”告诉他们。比如：
一方面，交互设计师对产品经理说：这块由我们来考虑，你的文档不必包含设计上的说明，这随时会调整的。
另一方面，线框图的评审有时会让RA参与，有时却没有叫他们。即使叫上了他们，他们也会发现交互设计的需求变化要比FRD变化快。另外，他们会认为UC不必写太多关于交互设计的需求。
在某个大型项目结束后，作为交互设计师，我进行了一些调研，听听这相关人员是怎么表述问题的：
开发部门的需求分析师：
每次变动都很痛苦，设计变了之后，我就要跟着改UC，改截图，有时候UED改了还忘了通知我们，导致UC有问题……
页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。
希望UED能够在提交HTML DEMO给RA时，能同时给出一份页面元素描述文档，需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。
产品经理：
前期RA和PD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，“标题显示多少字符”等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求，往往会“越俎代庖”，直接在FRD注明这种需求（对于交互设计师来讲，却又导致没有发挥余地）
走访了一些交互设计师后，他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑：
交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。而且做好后，还需要去验收。
DRD做为参考手册，一定程度上避免不吻合的问题发生。
即使有问题发生，也可以作为界面验收时的Checklist。将“我对A说，我对B说，A对B说”，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。
全程影响用户体验（一直到测试，都需要参照设计文档）。
可是以下问题都可以通过一份DRD来解决吗？
三. 写什么不写什么？
要明确文档的定位，从写什么与不写什么开始，划清DRD以及FRD的边界。
1. 不写视觉规范规格标注
这些说明与功能实现没有太大关系，主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图：
2. 不写功能实现逻辑。
如下图所示，作为DRD，你有必要传达清楚Browse by category区域的设计：链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务，
电脑资料
那么文档写什么呢？
举例子说明下：
1. 字符限制
提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚：1，是否要做限制？2，如果做限制的话，多少字出现截断？截断后是显示为省略号还是不显示？这个汉语设计相对简单，如果英文单词的话，因为是按字符，每个字符的宽度不一致，需要预估，另外还需要注明是整词截断还是词间截断。
2. 链接具体化
很多网站都有对搜索结果的筛选设计（refine search），比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。
类目和属性的不同如何处理
属性以及每条属性显示的属性值的条目是否有显示上的限制？
选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看？其他未被选中的属性值是否消失？
要确保这些你设想中的复杂的交互逻辑能够被理解被呈现，除了一页页的线框图，你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互，有的指向你安排的并非PD安排的某个中间页面（page flow是交互设计师的职责）
3. 交互细节说明
相信我，我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图，我会研究用axure制作各种动态效果，达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时，页面上其他区域也发生相应的变化。可是，Axure不是全能的。即使能够表达出来，线框图交付出去，也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解，在事后再三检查并敦促修改。
但是当我尝试用下图对这块小小且复杂的区域进行详细说明后，事情变得简单多了。所以我用节省的时间去写了这份PPT.
又如，你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕，标注出与他工作相关的重点，存档并在遇到问题，找不到你人时随时参考。
5. 表单的校验
这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏，然后及时优化的。
6. 浏览器的兼容性要求
你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6.:D 。 这个决定谁来做？是前端工程师还是产品经理？还是你——交互设计师？我认为决定权在交互设计师这里，但是他必须和产品经理达成一致，并与前端确认。你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。
四. 什么时间交付呢？
Heidi的建议：尽可能与你的线框图同时交付，如果你先交付出线框图，在撰写DRD的时候，极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间，你不可能让所有下游等着你的工作。所以：
你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计，这和交互细节关系不大。
先交付出已经确定的线框图给前端，然后在1-2天DRD后，若有改动，与前端当面一一确认并一起交付。
五. 如何写DRD?
1. 选择最有效率的工具。
我的经验是这个工具最好能够提供清晰的目录导航结构，而且易标注。word确实是个写文档的好工具，不管你信不信，反正我是信了。
2. 建立固定的目录结构
下图仅供参考。
具体里面的细节，就不一一罗嗦了。
六. 重要的原则
准备写DRD的朋友，请认识清楚此文档真正要解决的问题是什么？如果是解决沟通偏差、需求遗漏、沟通成本高的问题，你在项目里没有出现过这种问题，各合作方也反馈良好，那么这个文档就无需写。如果是解决对设计需求进行存档，便于后续人员改版时查看的问题，则又是另外一回事（经验证明，过去的DRD确实能够在改版时起到一定的帮助，在我离开原项目很久后，新的设计师还找我要过相应项目的文档，了解过去的设计逻辑）。
不是为了写文档而写文档（而是为了解决问题）
适合于项目、合作方（大项目有大文档，小需求有灵巧的解决方案）
工具不是问题（易传播，易标注，成目录即可）
模版不是问题，大家看明白就可
完美的文档无法取代面对面的沟通（评审会和讨论不会因为文档而减少）
需要在实践中不断改进
七. 谁来写？
我建议由交互设计师发起，但是由前端工程师进行修订，再传递给开发工程师。
有很多需求，交互设计师只要求实现即可，但是他可能并不在乎是前端实现还是后端实现。前端工程师对DRD进行把关和修订，能够将设计语言转化为工程师能够看懂的语言，且能够划定与开发的实现边界。
八. 与其他产出物的关系
项目中交付物对应不同的使用角色，如下图所示：
但是有个问题是，虽然DRD的目标受众有开发和测试，但是让开发工程师同时参考那么多文档是不现实的，所以仍然是开发工程师的接口人，也就是事实上的RA需求分析作为需求整合传递的角色，将商业需求和设计需求，传达给具体的执行开发工程师与测试工程师：
