优质交互说明文档范例word范文 11页.docx

优质交互说明文档范例word范文 11页.docx

《优质交互说明文档范例word范文 11页.docx》由会员分享，可在线阅读，更多相关《优质交互说明文档范例word范文 11页.docx（9页珍藏版）》请在冰豆网上搜索。

优质交互说明文档范例word范文11页

本文部分内容来自网络整理，本司不为其真实性负责，如有异议或侵权请及时联系，本司将立即删除！

==本文为word格式，下载后可方便编辑和修改！

==

交互说明文档范例

篇一：

详细设计说明书模板范例

福建电信科学技术研究院有限公司

号码百事通

综合查询台详细设计说明书

智能网技术支援中心版本号：

V1.0

文档类型：

?

需求文档?

计划文档?

设计文档?

测试文档?

用户文档?

工程文档?

维护文档

密级：

?

公开资料?

内部资料?

保密资料?

机密资料状态：

?

初稿?

讨论稿?

发布

版权声明

福建电信科学技术研究院有限公司版权所有，保留一切权利。

未经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档的部分或全部，并以任何形式传播。

产品支持服务

我们将不断改进我们的产品和用户手册，使其更完善、更便于使用，您的意见和建议对我们的工作非常重要，您可以用您喜欢的任何方式与我们联系。

我们的联系地址和电话是：

公司地址：

福建省福州市五一中路57号7层邮编：

350005

电话：

+86-591-3329115转101/120分机+86-591-3329117转101/120分机传真：

+86-591-3329116网址：

.cnE-Mail:

文档修改/审批记录

福建电信科学技术研究院-1-

目录11.11.21.31.422.12.1.12.1.22.1.32.1.42.1.52.1.62.1.72.1.82.22.2.12.2.22.2.32.2.42.2.52.2.62.2.72.2.8

简介错误！

未定义书签。

目的9范围9参考资料9术语定义及说明模块详细设计10客户信息显示区模块

109

功能概述10界面概述11类设计

12

14

关键逻辑与算法说明

访问的表或其他数据库实体14调用外部接口说明14提供调用接口说明14

模块内部使用的公用函数/包等的说明14

公告显示区模块

14

功能概述14界面概述14类设计

14

14

关键逻辑与算法说明

访问的表或其他数据库实体14调用外部接口说明15提供调用接口说明15

模块内部使用的公用函数/包等的说明15

福建电信科学技术研究院-2-

2.32.3.12.3.22.3.32.3.42.3.52.3.62.3.72.3.82.42.4.12.4.22.4.32.4.42.4.52.4.62.4.72.4.82.52.5.12.5.22.5.32.5.42.5.52.5.62.5.7

信息查询显示区模块

15

功能概述15界面概述16类设计

16

17

关键逻辑与算法说明

访问的表或其他数据库实体17调用外部接口说明17提供调用接口说明17

模块内部使用的公用函数/包等的说明17

号码反查显示区模块

18

功能概述18界面概述19类设计

20

20

关键逻辑与算法说明

访问的表或其他数据库实体20调用外部接口说明20提供调用接口说明20

模块内部使用的公用函数/包等的说明20

以旧查新显示区模块

20

功能概述20界面概述21类设计

21

21

关键逻辑与算法说明

访问的表或其他数据库实体21调用外部接口说明21提供调用接口说明21

福建电信科学技术研究院-3-

篇二：

如何写一份交互说明文档

转载请注明来处，关注我，请点击：

离开交互圈已经有段时间了。

但由于博客还在，还是能够偶尔收到一些邮件，上周有位同学问我：

我在求职，我看到很多招聘说明上需要交互设计师编写界面交互设计文档，请问界面交互设计文档是什么文档？

怎么编写呢

这让我想起来201X年自己在项目里也大力推行过交互说明文档（在下文中，简称为DRD），格式倒没什么限制，交互设计师自己写到界面上也行，单独文档成文也行，总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来，降低项目里的沟通成本和风险。

今天整理电脑，翻出以前的PPT，分享之。

这将涉及到几个问题：

一.什么是交互说明文档（DRD）？

所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。

在项目中，交互设计师的主要产出物可能依次是：

sitemap，pageflow，wireframes。

有的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD产出的市场需求文档不一样的是，URD更多侧重于对目标用户的需求分析）。

DRD则很少有人专门撰写。

如果需要对交互设计进行说明，聪明的交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。

二.为什么要写？

DRD非项目必需环节，一般情况下也不会为交互设计师专门留出相应的时间预估。

没有这份文档，项目也会继续，

但是可能项目会为此承担不必要的沟通成本和时间成本。

严重的话，项目的质量也会受到影响。

所以写与不写，交互设计师需要做把握，时间被统一包含在“线框图”环节内——如果你要写，请在评估时预留1-2天的时间。

那么，结合我过去的经历，谈一下此文档的必要性。

下图是一个产品开发项目基本的流程。

敏捷开发意味着很多不同角色的流程需要并行操作。

如果等到产品经理的FRD已经全部敲定，交互设计师再开始去画线框图，固然会减少沟通成本和返工风险，但是同时意味着交互设计师的很多想法不被采纳。

如果产品经理再强一些，他甚至会在FRD里连原始的DEMO也一并绘制出来了，功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在FRD里直接要求每页条目40条，超过40条即分页。

而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和……所以，我们希望是和产品经理同时开始工作，在术业有专攻的时候相互补充。

同样，开发工程师也希望及早介入需求，在FRD并未确认的时候就了解需求，进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单（这个清单，大部分叫做UC，即USECASE）,当这份清单由工程师需求分析师——在过去，这个角色被叫简称为RA，但是目前已经取消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将做这件事情的人称为RA——交付给具体的执行工程师后，执行工程师基本上可以当作一条条的checklist开始高效工作，而不必再思考商业逻辑和需求。

同样，

测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试，这也是基于UC和FRD去撰写的。

所以，开发需求分析是个很重要的环节。

那RA是如何来完成需求分析工作的呢？

?

?

?

前期介入，对PD进行开发需求评估支持；参与每次的FRD评审会；详细审阅FRD文档并不断与PD确认。

对于做这件事情的人来说，足够详尽的FRD是非常重要的。

所以一份FRD虽然是PD产出，但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。

而设计需求的传递，却存在很多问题。

除了线框图，没有

“详尽的说明性的文档”告诉他们。

比如：

一方面，交互设计师对产品经理说：

这块由我们来考虑，你的文档不必包含设计上的说明，这随时会调整的。

另一方面，线框图的评审有时会让RA参与，有时却没有叫他们。

即使叫上了他们，他们也会发现交互设计的需求变化要比FRD变化快。

另外，他们会认为UC不必写太多关于交互设计的需求。

在某个大型项目结束后，作为交互设计师，我进行了一些调研，听听这相关人员是怎么表述问题的：

开发部门的需求分析师：

?

?

?

每次变动都很痛苦，设计变了之后，我就要跟着改UC，改截图，有时候UED改了还忘了通知我们，导致UC有问题……页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。

希望UED能够在提交HTMLDEMO给RA时，能同时给出一份页面元素描述文档，

需要介绍htmldemo中的文案、链接以及相关的图片尺寸或显示字符个数。

现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。

产品经理：

?

前期RA和PD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性

值”，“标题显示多少字符”等。

在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。

既增加了沟通成本又会存在遗漏细节的风险。

PD为了可控性的需求，往往会“越俎代庖”，直接在FRD注明这种需求（对于交互设计师来讲，却又导致没有发挥余地）

走访了一些交互设计师后，他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑：

交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。

我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。

而且做好后，还需要去验收。

?

?

?

DRD做为参考手册，一定程度上避免不吻合的问题发生。

即使有问题发生，也可以作为界面验收时的Checklist。

将“我对A说，我对B说，A对B说

”，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。

全程影响用户体验（一直到测试，都需要参照设计文档）。

可是以下问题都可以通过一份DRD来解决吗？

三.写什么不写什么？

要明确文档的定位，从写什么与不写什么开始，划清DRD以及FRD

的边界。

1.不写视觉规范规格标注

这些说明与功能实现没有太大关系，主要是为前端做HTML的时候参考的。

一般视觉设计师会在PSD里标注清楚。

如图：

2.不写功能实现逻辑。

如下图所示，作为DRD，你有必要传达清楚Browsebycategory区域的设计：

链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务。

那么文档写什么呢？

篇三：

201X118513127陈玺舟媒体交互艺术作品说明书

Arduino作品设计说明书

不知不觉到Arduino结课的时候了，回想起刚开始拿到Arduino初学者基础套件的好奇和激动，到学它时的少许无奈，感觉挺难的！

随着时间的推移，，对各个零件的认识，从arduinouno电路板、LED灯、各种电阻到LCD液晶显示屏，已经能成功理解里面的电路；少许的代码也会合理利用，根据代码接线，做出想要的效果也不是太难了！

又好奇变喜爱！

我们做过让LED灯像生命一样呼吸，也做过在8*8点阵上用灯的熄和亮来表达我们想说的话和画?

?

，它带给过我们很多快乐，每次接好线，导入程序后，看到自己想要的效果出来后，那种成功的喜悦在每节课上都会出现！

互动电子设计、制作的乐趣吸引着我们每一个人！

逃课的也不在逃课了?

?

，在快乐中走到了结课，特此我们做了一个作品叫《送给母亲的蛋糕》！

制作前的构思

这次教结课作业恰逢母亲节，我们就想做一个感恩装置！

经过小组的讨论，采用模型和灯光、声音、图画，也就是利用LED灯、蜂鸣器加上8*8点阵来做！

模型就是蜡烛和蛋糕结合的产物，代表着母亲节送给母亲一个蛋糕，利用灯光把蛋糕上的蜡烛点亮，8*8*点阵用来表达我们想说的话！

声音就是传达出欢快的气氛，表示我们为母亲节的到来而高兴！

制作过程

首先我们就是搭建模型！

做一个象征着蜡烛和蛋糕的模型，我们找到了滚筒，利用滚筒搭建三层！

8个滚筒在第一层，5个滚筒在第二层，第三册一个滚筒！

为了美化滚筒，又把每个滚筒涂上颜料，

并在滚筒中心画上心！

这样搭建好了以后，就开始布线！

在每个滚筒上加上透明泡沫，把小灯泡插在泡沫上，由于我们的LED灯的颜色有限，我们本想全用红色的，