1. 首页
  2. 怎么写?
  3. / 正文

如何写一份出色的交互设计文档,给程序员以美的享受?

交互设计文档分为两个版本:一个是界面元素标注版,另一个是附带交互逻辑版。那么,具体的写法和要求如何呢?

为什么要写这篇文章?

写这篇文章之前,遇到过很多朋友问道:『交互设计的输出物是什么?』『交互设计师怎么与程序员协作?』、『交互设计师还需要出文档?』等等一些问题。

更多的人在寻找一个交互设计文档的写法教程,每一个人的回答都不相同,但是很多入门的交互设计师遇到这个问题时觉得很棘手,因为不清楚自己应该如何写一份符合自己产品业务逻辑或产品规范的设计说明文档。

这篇文章就是给这些有很多疑问的同学写的,可以解开一些疑问,但是指望这篇文章就写出高质量的文档显然不可行,所以看完这篇文章后可以从中提取一些思路,自己整理一个属于自己的设计文档规范写法的模板,长期积累下来,就可以形成自己的设计风格和规范。

什么是交互设计文档?

我们先来统一一下概念以及名词,以免后续因为说法不够一统造成误解。

交互设计文档一般是指:交互设计说明文档(交互设计师产出的规范文档),又称DRD(Design Requirements Document),工作中一般称之为”交互设计文档”。

为什么要写交互设计文档?

如果问不写交互设计文档可以吗?

答案是:可以不写,那么写与不写的区别究竟在哪里? 我们从两个方面分析一下。

1.可以不写交互设计文档的情况

下列情况是目前很多公司存在的情况,既没有专职交互设计师,也不出文档,但他们也在做产品,这些情况有可能不需要写交互设计文档。

产品没有交互设计环节

团队没有交互设计师角色

交互设计没有系统化和规范化

开发边界不需要控制

产品没有动效或交互细节

有经验丰富的产品经理

产品没有复杂的人机交互逻辑

产品只有一个产品经理或负责任的角色主要负责

2.要写交互设计文档的情况

下列条件具备后写交互设计文档更具意义:

产品有清晰的交互设计流程

产品团队中有专职的交互设计师

团队已有系统化和规范化的作业流程

开发实现交互设计时需要定义边界(验收标准)

产品有比较复杂的、丰富的动效

产品有较为复杂的人机交互逻辑

产品有多个产品经理或部门协作

写交互设计文档的作用就很清楚了,如果要写这样一份文档最大的好处是,可以非常清楚地帮助程序员认知做出的产品是什么样子的。

看个小例子:

V1.0 没有交互说明文档的版本(可能由产品经理PRD代替)

产品需求的描述是这样的

需求说明:在封面图片上点击图片之后翻转一圈。

(文字描述交互与需求)

开发人员根据这句话脑补怎么翻转?360°?从左边还是从右边?转速怎么样?这些都需要找PM问清楚,如果遇见专业的PM还可以能讲清楚,但如果遇到经验不足的PM,就会说让开发人员你看着做一个就行……。

V2.0 没有交互说明,但是有UI设计的版本

UI设计出图是这样的

image001

对于需求和期望达到的效果,静态可视化的说明要比纯文字更容易理解,需要给开发人员一个具象化的目标,否则程序员做出来的东西很容易与期望目标偏离,即想要的A而开发给的却是B。

V3.0 交互原型加演示DEMO

动态demo:

image002

输出HTML文件预览

image003

小结:编写交互文档是为了将更丰富的人机交互动作、事件准确地传达给开发人员,确保实现边界。

若只是语言或静态图片交付给开发、测试人员,那么他们很难构建一个产品形态,不好把控开发方向,另一方面,交互文档也是给参与项目的其他人快速了解项目的背景,不用到处询问设计细节。

其实写作交互设计文档最大的好处在企业管理层面上,产品的交互设计文档作为产品资料入档,后续人员变动后,新来的人可以快速掌握整个产品的核心设计。减少人员无谓的沟通,不过有一点,这个文档要及时更新,有变动要发出更新日志,不然还是少不了同事之间的语言沟通。

交互设计文档由谁来写?
网站地图