【转载】一份上下游都喜欢看的交互设计文档(附源文件和组件库)

前言

       这篇文章讲的是如何制作一份产品、UI、开发、测试都喜欢看的交互设计文档。文章内容主要是自己工作中用到的交互设计规范模板(axure版本),这套规范是自己总结出来的,但是构建的思维方法借鉴很多前辈大神的方法论,特别是淘宝U一点团队所分享的公开课内容。

       抱着他山之石,可以功玉的想法,结合自己公司团队的工作特点,总结了一套交互设计规范。使用中,有些小收获,分享出来,大家多多沟通,共同进步。

        这篇文章的行文思路是,先说明交互设计规范准则是什么、然后举例说明交互设计文档各模块的书写思路及踩过的坑,最后是一份可供下载的模板和组件库。

一、交互设计规范化文档的准则

1.1 为什么要输出一份交互设计规范

        1、“设计有记录、信息可追溯、交流有依据”。这个很重要、重要、要。一个产品的诞生不是你一个人几天的事,它有多部门配合的宽度,也有多版本迭代的长度。一个交互设计师,如果设计不严谨挖了坑,早晚是要填的,交互设计规范或许可以帮你规避一些坑。

       2、“在团队中,信任真的是一切沟通的基准”。交互设计师,工作中除了解析需求,绘制交互稿外,更多的时候需要配合UI完善设计,跟进开发实现效果。如果你绘制的交互稿没有那么的完善,缺东少西,UI和开发就会慢慢对你没有信任感。这个时候,你的其他工作也会很难开展。也不是说一份交互设计规范,就能让开发对你产生信任,但是一份好的规范,能弥补你部分欠缺,提高你设计的正确性,同时一份好的规范文档可以降低沟通和学习成本,展现你的专业化能力。

1.2 交互设计规范要求

       1、符合自己的就是最好的。一定是根据自己公司工作流程,和上下游沟通后来确定自己的文档应该包括哪些内容,哪些内容需要着重写,哪些内容可以少写,书写的方式应该怎样,团队内行业内是否有共同的说法和写法。毕竟规范的作用就是为了提高工作效率的。

       2、扩展和更新。不同类型的项目,所涉及的控件,所使用的规范要求不同,要学着调整和更新自己的模板。

二、交互设计文档各模块的书写思路和踩过的坑

    先来一份交互文档的目录

图2.1 目录

2.1封面

开篇明义,文档的基本信息概述。

版本编号:此文档的最新编号;(一定要记得更新)

设计人员、开发人员、测试人员:表明文件流转的下一级相关人员,方面沟通(如果涉及人员众多,也可单独列举)

图2.2封面

       一份规范的交互稿不仅是对自己负责,也是对其他伙伴负责、对将来负责。

2.2文档说明

        交互文档的目的就是为了上传下达,将需求转化可视化文档,是一个过程性文件。所以,文档的可阅读性是衡量一份文档好坏的一个标准。而文档说明这个模块就是为了给不同的文档阅读者相同的“世界观”。

       2.2.1项目背景与范围

        更完整的项目背景应该出现在产品需求文档中,而交互文档中书写的目的有两个,第一,如果项目小,没有完整的产品需求文档,这里就是向各方人员传达项目背景的地方;第二,加深整个项目组成员对项目的理解,看内容前,先有一个共同知识背景。

 (书写小贴士:书写内容相当于用户体验要素中,战略层、范围层的梗概。)

图2.3项目背景与范围

     

      2.2.2更新日志

       目的也是有两个:第一,面向自己。工作是一个过程,完整的记录更新日志,方便自己将来查询,同时,也方便和开发测试互撕的时候,亮证据;第二,面向开发、测试。整个开发过程漫长,协助方多样,完整记录,可以降低各方不必要的沟通成本。

    (书写小贴士:1、更新日志,可以在交互文档评审通过后,需求锁定后,在开始书写,设计过程中的更改可以不书写进去(个人经验);2、书写的内容要具体(写的不具体,后续会有坑);3、书写中最好增加关联链接,方便相关同事快速找到位置;4、同一个位置多次更改时,要标注最新内容)

图2.4更新日志

      2.2.3设计进度计划

进度计划这种东西一般出现在项目工程表中,或者项目工程排期中(具体的可能根据不同公司,有所不同)。而交互稿中的设计进度排期的作用,和前面两个一样,一方面是给项目组成员一个共同的背景,另一方面,是自己设计过程的记录。

(书写小贴士:1、按照设计过程,可以大致分为需求整理、需求评审、交互设计、交互评审、UI设计、UI评审、开发、测试,根据自己情况进行划分;2、个人经验,此处的进度计划不是整个项目很严谨的工程计划,此处的只是设计师与相关同事沟通协商工作的一个梗概,以及自己的记录,自己看的明白就行)

图2.5设计进度

      2.2.4评审记录

         区别于更新日志,评审记录主要书写于设计阶段。评审记录主要分为内部评审(设计师(项目内交互和视觉)、UED负责人、UED相关设计师)和外部评审(设计师(项目内交互和视觉)、UED负责人、UED相关设计师、业务负责人(产品和需求方)、技术负责人、技术相关人、市场运营人员)

(书写小贴士:1、一般都伴随着会议记录出现,我一般会书写好以后,直接剪切当会议记录)

图2.6评审记录

2.3、解析过程

       解析过程是我认为最重要的一部分,是产生信任和思维可视化的地方。在进行交互设计原型绘制之前,一定要以目标为导向拆分自己的思维,并将“虚拟”的目标转化为各种设计元素。

      说简单的点,这块就是设计维度的需求分析。不同人可能有不同的分析方法和展现形式,不管怎样的方式,只要能梳理自己思维帮助自己设计并且清晰的向自己伙伴传达信息即可。

       以个人经验,根据不同类别的项目,不同大小的产品,需求分析的维度和角度都有不同。此处我就简单说一下,我常用的一种需求分析方法。

以人为核心,以目标为导向的思维解析法

     我们做设计,大到一个产品,小到一个页面,在设计的时候都是有目的,也有需要达到的目标。目的可能来自于公司战略,来自于市场需求,或者来自于money,不管来自哪里,商业社会里,我们做产品肯定是有所图。同时,我们产品服务的用户,他们的特点有很多、所使用产品的环境有很多、用产品时的想法感觉也有很多、他们也有自己的对产品的追求和要求。而我们是设计师,不是艺术家,我们需要在有限的条件下,利用我们的才能设计最贴合用户需求,最能产生商业价值的产品。这个过程就是下面这个需求分析推导的完整思路。具体内容,我就不再这里展开解释了,可以仔细看下图。我针对各个具体环节做了一些简单说明。将来如果有合适的、可对外分享的案例了,我可以详细说明下。

(书写小贴士:1、书写形式可以多样,只要能帮助自己理解需求、方便设计即可;2、需求分析可以有更详细的文档,交互文档里写,还是那个目的,让上下游看到,能达成共识;3、我文档中列举的其他几种方法,只是一个例子,可根据具体情况使用)

图2.7需求分析推导

2.4、页面交互方案

        页面交互方案,也就是我们常说的那种交互原型文档。具体如何写,在这里就不多说,具体业务具体讨论。这里只说下,在日常工作中,常见的几种交互文档书写的思路方法,已经书写的范围和注意事项。

    2.4.1流程图

       重要性就不多说了,很重要。另外,一定要在设计前梳理好流程图(可以不完整),一定不要后续为了展示补流程图,那样,流程图就不能起到它本身的作用了。如果你原来不是这样做的,可以调整下思路。

(书写小贴士:1、流程简单可以绘制一个流程图,如果流程多,建议拆分成各个子流程绘制;2、除了绘制功能流程图外,建议可以绘制业务流程图;3、绘制软件多样,可以axure,也可以使用第三方软件。)

图2.8流程图

     2.4.2信息架构图

        重要性也不说了,很重要。绘制信息架构图,只是一个展现结果,如何绘制才是核心,方法就不在这里展开。

(书写小贴士:1、信息架构图可以从功能--页面--模块--元素这样的维度书写;2、共通模块可以并联使用;)

图2.9信息架构图

     2.4.3交互页面

         交互页面主要有两部分构成,一部分是页面,一部分交互说明。

        一个Axure页面表达一个事效果最好,最受同事喜欢。什么叫做表达一个事呢?一个事既可以指一个流程,也可以指一个页面。

      一个axure页面表达一个页面。

(书写小贴士:针对核心页面具体说明,至于页面所关联的子页面和流程就在其他页面表达。)

图2.10一个Axure页面表达一个页面

         一个Axure页面表达一个页面的多种状态:

图2.11 一个Axure页面表达一个页面的多钟状态

         一个axure页面表达一个流程

          一个流程是指最小的一个子流程,子流程与母流程之间可以通过Axure文档的树结构表达

图2.12 一个Axure页面表达一个流程

2.4.4交互说明文档

一份合格的交互说明文档应该包括但不限于

页面内容说明(数据来源,数据特点,内容类型,范围,极值,排序规则等);

交互反馈,状态;

交互动效、视觉要求。

      下面这个案例中,对页面元素做了详细说明,包括数据特点、计算规则、更新极值、特殊情况说明、状态说明,视觉样式说明等。

图2.13 一份交互说明文档

写到这里基本就算完了,其他内容就是针对不同产品的个性化需求,做不同具体设计说明。

三、神助攻

就像文中开头所说的交互设计规范的目的是提高工作效率,降低沟通成本,提高设计质量;至于这“两个提高一个降低”能否实现,除了规范外,我这儿还有两件“法宝”。

 一、定制化的组件库。结合自己的工作特点,定制一个符合自己业务范畴,和工作习惯的组件库,效率肯定会事半功倍。组件库不是一蹴而就,而是自己根据业务特点和设计习惯,慢慢调试的。附件是我自己定制的一套符合自己设计特点的组件库,大家可以在此基础上修正调整。

二、团队。团队之间的默契,配合与协同,才是提高工作效率、降低沟通成本,提高设计质量的制胜法宝。

        看我啰嗦了这么多,我也有点不好意思,就奉上一份交互规范源文件和一份设计组件库。供大家参考。多多沟通,多多交流。

交互规范源文件:链接:https://pan.baidu.com/s/1PnRZpir8JJDmCNVLfEi0vQ 密码:pew7

组件库:链接:https://pan.baidu.com/s/1lS4DpO5mU0VtrMh-K3XFCw 密码:r4rp

(ps:组件库是在蚂蚁金服开源的组件库基础上调整更新的)

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,290评论 6 491
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,107评论 2 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,872评论 0 347
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,415评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,453评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,784评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,927评论 3 406
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,691评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,137评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,472评论 2 326
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,622评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,289评论 4 329
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,887评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,741评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,977评论 1 265
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,316评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,490评论 2 348

推荐阅读更多精彩内容