0文章
0评论
0获赞

一款APP的交互文档从撰写到交付②

323 0

说起这个主要是和设计朋友们聊天,谈到两个事情:

①有人很焦虑,说中国互联网30多岁后做不下去了,我不否认这残酷现实o(╥﹏╥)o

行业精英只是少数人,我们终其一生也可能就是个普通设计师,把设计当成养家糊口的手艺,离开行业发达的城市甚至都没有可用武之地。但是我们这阶段焦虑也是空有焦虑,没什么用。所以踏实的提升能力吧,到了30多岁的时候再考虑继不继续做下去。

②有人说小企业没有牛人带,想跳槽一没拿的出手的作品,二怕没跳槽的实力;

这种情况存在而且很多,多数中小企业就这样,我们无力改变普遍行情。所以我建议在职期间用尽一切办法提升能力,不论自学或者网课;之后重设计公司的商业项目作为个人作品,年后趁早跳了吧。最后说一句,我工作中遇到过很多设计师,套用现在比较俗套的句子就是:

设计行业,工作年限≠工作能力,天赋决定上限,努力决定下限。

所以不时刻学习提升能力,30多岁的我们也只是干的时间比较久的美工而已。

闲话扯的有点多,下面来看干货部分吧。

Part 1 交互文档的作用

(这是理论性的东西,快速浏览下就可以了,没什么实质内容,但不写还差点意思。ㄟ( ▔, ▔ )ㄏ)

交互文档需要团队人员都知晓,并根据需求反馈,时刻迭代,同步更新到每一个人。

(说白了,这文档必须每个人都熟悉,并且后边更新后每个人手里的都得跟着更新。)

交互文档在每个环节的作用:

  • 把PM抽象的需求,变成具象的、可落地执行的设计方案;
  • 和各级部门讨论设计方案细节和可行性,并最终敲定需求、开始执行;
  • UI根据交互文档设计效果图,页面布局、顺序、页面情感以及交互方式等等;
  • 对开发:严格根据交互文档进行产品功能的设计和开发;
  • 对测试:严格根据交互文档设计测试用例,并Review方案进行反馈。

优秀的交互文档的作用:

  • 让相关人员快速了解设计方案和制定工作计划;
  • 保证每个环节的用户体验一致;
  • 开发完成后、作为产品验收的检验依据。

同时也是体现交互设计师专业能力和个人价值的依据。

对设计师而言,制作原型的思考过程,绝对是最快提升逻辑能力、产品设计能力、分析能力以及提高产品认知度的过程;、

(当然前提是真的要思考着去做,不过脑子光画线框图的就当我没说过吧……)

对团队而言,低保真原型可以有效提升工作效率,规避风险和资源浪费。

无论是大到整个产品的交互文档,还是小到某个功能的交互文档,道理相同。

以上当然是理想状态,但现实总是残酷的。

我经历过无视原型阶段,拿需求文档直接让UI出效果图;需求变更直接改效果图,把UI设计师当牲口使唤;

也经历过因方案没有准确传达到每个人,导致有人对方案误解,开发中出现问题的;

第一种凭设计师个人很难改变公司的现状,所以要么走要么扛;

第二种一定要尽力避免因沟通引起的低级错误。

Part 2 完整的交互文档

不少人认为线框图就是交互文档,但它只算是“介面布局方案”,不算完整的“交互文档”,因为“介面布局方案”PM、UI可以画,甚至市场、运营也可以根据想法画出来,所以这个无法体现交互设计师的工作价值。

下面这份交互文档的书写习惯,来自我第一份工作的设计总监,他教导我的东西一直被我延用至今,受益匪浅。

首先看下交互文档的Pages目录,我会把涉及到模块对应的内容解释给大家:

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

1、目录

目录就是交互文档自身的信息架构,优秀的交互文档需要结构清晰,命名准确的目录。

很多人阐述交互方案时,其他人看到的目录是“New Page01、新页面03、功能02……”,结构和命名都很混乱,团队成员凭什么认同你的专业能力?

结构清晰,命名准确本身就是体现交互设计师专业能力的内容之一。

2、交互文档内容之一:产品封面

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

封面的内容:

  • 项目或需求:项目名称或者本次需求的名称;
  • 版本号:项目或需求隶属的版本,用来进行版本归档,项目跟进、排期;
  • 人员列表:项目相关人员都会位列其中,便于工作安排和交接。

产品封面显示了项目的基本概况,是很好的介绍入口。

3、交互文档内容之一:修订更新记录

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

修订更新记录的作用:

  • 让UI、开发和测试等快速知晓项目需求以及更新内容,并迅速定位到对应位置;
  • 作为需求的凭证,当有人对需求有异议时,拿出白纸黑字的记录;
  • 培养交互设计师时刻记录的习惯,记录的越详细越好,以后会有很大帮助。

修订更新记录的书写规则:

  • 以天为单位倒序书写,从项目立项开始记录, 持续更新迭代;
  • 每个需求点单独列为一条记录,不要一条记录填写多个功能点;
  • 每条记录添加链接到交互方案的对应页面,便于其他人快速定位到相应位置。

这文章虽然叫“交互文档的撰写和交付”,但是交付之后交互设计师的工作可远远没有结束。

交互设计师的工作就是不停的跟进需求变更和反馈,持续迭代优化交互文档,而且无论何种更新,都要具体提现在我们的交互文档中。

4、交互文档内容之一:需求分析 & 业务逻辑图

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

这里其实是来自于PM的需求文档和业务逻辑图,不是交互设计师的工作范围。

这个模块工作主要是PM来做的,放到这里的原因有两个:

a.为了保持文档的完整性;

b.让开发和测试能够在同一份文档里解熟悉业务需求和业务逻辑,方便他们工作,而不需要好几个文档来回查看了。

5、交互文档内容之一:信息架构图

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

信息架构图是根据PM的需求文档、功能树状图和业务逻辑图提炼的产品功能模块,这里已经可以区分出产品功能的层级关系了。

信息架构图的结构和产品交互方案的结构两者是对应的。

从产品交互方案上就可以看出一个交互设计师的信息架构梳理能力是不是专业。

6、交互文档内容之一:流程设计图

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

程设计有多重要我就不赘述了,凡是做交互设计的都避不开的工作。

流程设计图中的每一环节,是和我们交互方案中的页面一一对应的。

把它放到文档里来:

一是避免在制作交互方案的过程中,忽略遗漏掉某些页面;

二是让开发和测试快速理解产品每个任务的具体流程,来安排工作

这里注意一点:

有多个任务流程的时候,应该针对每一个任务单独绘制该任务的流程设计图。

7、交互文档内容之一:交互方案

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

交互方案就是我们整份交互文档的重点:产品最终的可执行设计方案。

它会包含页面逻辑关系、页面布局、交互说明、迭代标示、动效说明、页面情感说明等诸多要点;

它和前面提到过的信息架构图,流程设计图是相呼应的,设计它应该根据信息架构和流程设计来制作。

(交互方案会在下一期详细拓展,这里仅作为本章示例来使用,不再过多展开。交互方案的注意事项非常多,这里展开的话会导致本章的内容过长了,而且我个人不喜欢看太长的文本。)

8、交互文档内容之一:公用控件库

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

公用控件库的作用有两个:

一是我们制作交互文档的时候可以快速提取对应控件,提高工作效率;

(目前线上平台已经提供了大量的可用控件,但因为我们这里使用的是本地化的制作工具,这个模块还是要有的。)

二是团队成员共同协作的时候,保持交互文档的一致性;

每个团队的公用控件库都不相同,需要各自的团队根据自身产品特性去共同完善它,

这里只放了一些示例模板,大家需要注意一下。

我们来总结下都有什么:

1、目录

2、文档封面

3、修订更新记录

4、需求分析 & 业务逻辑图(来自PM)

5、信息架构图

6、流程设计图

7、交互方案

8、公用控件库

以上是一份完整的可以称之为“交互文档”而不是“介面布局方案”的文档该有的内容,

除了第④项可能受限于PM的职业水平和素养,不能保证确确实实获取到。

其他的内容都应该是作为交互设计师体现在交互文档中的工作内容。

后记

这一期我们谈了一份完整的交互文档应该包含的内容模块;

其实也可以理解为使用本地化制作工具书写交互文档时,要体现哪些信息。

下一期会详细的谈谈交互方案,会从整体流程设计注意要点、页面布局注意事项、交互说明如何向开发和UI呈现等方面来谈。

看过我以前文章的人也熟悉,我的文章大部分都是工作的方法,模式;很少涉及设计能力,理论体系之类的内容。

这么写的初衷是因为:

这类工作方法,不需要时间消化,看过之后立刻就可以根据自己的实际工作情况进行调整和套用,立刻就可以达到上手应用的程度。

而设计能力,理论体系这类抽象的东西,根据我个人的学习经历,短时间内很难通过阅读几篇文章就得到质的提升,必须通过大量的实际工作经验慢慢积累。

【上期内容:】

附件

本章使用的Axure交互文档模板,有需要的可以下载。

(ps:模板只是说明内容模块有哪些,各位根据实际情况参考使用吧。)

一款APP的交互文档从撰写到交付②
一款APP的交互文档从撰写到交付②

提取码: 2h2b

原文地址:UI中国

作者:精分青年卤大湿

评论 (0)
请登录以参与评论。
立即登录

一款APP的交互文档从撰写到交付③

960 0

做设计是不可能做设计的,这辈子不可能做设计。

搬砖又不会做,就是靠P图抠素材这种东西,才能维持得了生活这样子。

进公司感觉像回家一样,在公司里的感觉比家里感觉好多了!

里面个个都是大佬,说话又好听,谁说话我都得听,我超喜欢里面的!

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

直接上干货吧~


表述合理、内容全面的交互方案可以快速帮助下游部门完成工作:

对UI:根据交互方案进行视觉介面设计,介面布局、介面状态、动效等等;

对开发:根据交互方案进行产品功能和介面的开发,逻辑规则等等;

对测试:能根据交互方案进行测试用例的设计安排。

在此之前,先统一下本文文档的内部叫法,免得下面提到的页面介面分不清楚。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

这里我们从介面布局样式、页面流程设计、介面交互说明三个方面来诠释交互方案。

Part 1 关于交互方案的介面样式和布局

① Axure里的介面尺寸

通常IOS的视觉稿常用的设计尺寸是:750*1334

那Axure里每个介面使用375*667的尺寸即可,也就是设计尺寸的50%。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

② 介面布局要规范合理,准确传达出介面的设计理念

交互方案虽然是线框图,不要求达到视觉稿那么高的像素精度,但规范合理的布局能有效的将介面设计理念传达给ui设计师。

以前画速写和素描的时候,老师说速写持续细化到最后就是素描的级别。

对交互稿和视觉稿来说,交互稿就相当于速写,视觉稿就是细化之后的交互稿。

所以制作交互方案时,交互设计师要考虑绘制的每个控件的大小、位置、比例、层级等等,相对于于实际视觉介面是否合理。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

左侧的错误在由PM输出交互文档的公司里问题比较常见,当然PM也并不考虑介面布局的精细问题,他们只是想把需求传达出来。

③ 介面色调尽量黑白灰,控件尽量不要使用具象图形,避免过多干扰视觉设计师

做为UI设计师接到下图左侧的原型文档,真的要原地爆炸了……

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

部分PM以及新手,出于某些初衷,在文档里会使用很多色块来区分功能;

也会从网上扒一些对应的功能图标直接用在交互文档里面,甚至还有的直接手机截图粘贴到交互文档里面。

说实话,新人以及心理素质差些的视觉设计师,潜意识里真的可能受到左侧这种交互文档的干扰。


Part 2 交互方案的流程设计

① 一个页面,表达清楚一个任务流

作交互方案的时候,有不少新人和非专业交互设计经常犯的一个错误就是:

所有的任务流程全部堆到一个页面里,这种方式效率十分低下

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

Axure的一个页面本身就篇幅有限,把所有任务堆在一个页面上:

自己可能都看不清楚了,其他人看了更糊涂,增加理解难度;

在当前基础上,想要继续添加和修改内容,非常困难,牵一发动全身;

合理的交互方案流程设计方式是:一个页面只需要说清一个任务即可。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

这个完整的任务流程包含:任务起点、中间流程、结束状态。

这是我们比较推荐的一种交互方案任务流程制作方式。

② 每个任务要有起点,便于开发和测试清楚知晓任务功能入口在何处。

上面说了一个页面说清一个任务,那每一个任务其实也要有自己清晰的流程。

不要上来就绘制该功能的中间流程,需要把该功能的起始入口添加进来。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

这主要是为了便于开发和测试阅读交互文档的时候,知晓该任务的功能入口在何处,同时也保证了交互方案每一个任务的完整性和条理性。

③ 同一个介面的不同状态,尽量在一个页面内展示完整。

某些介面因为网络、内容、操作等因素会出现很多状态,以及各种极端的介面情况。

很多时候交互设计师在制作交互方案的时候,没考虑到那么多情况,交互文档里面也就没绘制这种情况的介面,那UI做的时候也会漏掉这些介面。

但这影响最大的其实是开发人员,有时会因为页面的缺失,漏写掉一些介面相关状态的判断条件。后期发现了遗漏状态,还要让设计师重新设计介面,并在代码里补全这些状态判断条件,非常浪费时间和精力。

同一个介面的不同状态(包含各类极端情况)尽量做在一个页面内表述清楚

下图是一个设备列表在无设备、网络差、服务器断开连接三种情况下的介面原型,当然这里只是举个列子,各位需要根据自身产品的实际情况考虑出现的介面状态。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

Part 3 介面的交互说明

静态原型本身并不能完全体现出产品功能的深层需求,所以作为交互设计师,需要对静态的原型介面进行必要的标注说明。

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③
上图是一个标注比较全面的原型介面,

来看看介面的交互说明都需要标注哪些方面:

①需求功能的交互规则和逻辑

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

需求的交互规则和逻辑一定要在介面的交互说明写清楚。

交互方案本身是一套完整的产品解决方案,它涉及到流程之中的每个页面以及单个介面中的某个内容的交互逻辑和规则是什么

这里的内容,务必和PM或者相关人员讨论清楚,并注明到交互方案对应的位置。

例子是一个订购设备的介面,标注2显示了订购数量的规则以及逻辑:

订购数量的限制规则;

输入错误信息时的提示反馈;

操作此处时介面的交互反馈(弹起键盘);

和服务器之间的数据交换规则和逻辑;

服务器反馈后此处的显示规则和逻辑。

交互文档不仅仅是给视觉设计的介面方案,也是给开发和测试的产品解决方案。

②需求功能的迭代标示

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③

有些功能可能会因为规则的变动产生新的迭代,这时候就需要在原有的交互说明位置添加新的迭代标示。

标注3显示了订购数量原来的规则,以及之后迭代更新过的交互规则。

这样便于开发和测试及时更新该功能在代码和测试层面的使用规则。

③操作的交互反馈和状态

一款APP的交互文档从撰写到交付③
一款APP的交互文档从撰写到交付③
标注6显示了按钮相关的交互规则和效果:

默认状态,未激活,不可点击;

填写错误,未激活,不可点击;

填写数据,激活,可点击;

点击后,跳转至相关功能。

它表明了按钮在规则和操作上的状态变化,以及点击之后的跳转以及加载过程等等。

这样UI设计师可以根据状态标注,去设计控件或介面的各种对应状态;

开发和测试也可以根据反馈标注,去实现各种对应状态的判断条件和介面开发。

④介面的动效说明

我个人不建议用Axure制作动效,也不要在介面上添加各种跳转(演示的时候点来点去,跳转到对应介面的那种跳转),本身Axure动效仿真度就低,而且制作效率低下。

我们上文说:一个页面说清一个任务。你的任务有多少介面,绘制在同一个页面里就可以了。

而且这份交互文档,你会交到开发和测试手里。很多时候,他们不会像在演示的时候那样点来点去,他们需要的是快速预览到整个产品,整个功能的情况。

有人说动效不是UI或者动效设计师的工作吗,关交互设计师什么事情?

对UI和动效设计师来说,他们做的其实是后期的工作,理论上产出的动效也应该是根据原型文档描述的内容产出的高保真DEMO。

在原型阶段,对介面动效的说明就是交互设计师的工作范畴,它可能是页面如何跳转的动效,也可能是关于何时放置一个loading的说明。

有些非专业交互人员或者PM,并没有在合适位置,提供介面的动效说明;

往往到了开发阶段,“这里需要个loading,做一个”,“这要个翻页动画,你弄一个”,

然后让UI自由发挥搞一个出来。

但其实在何处应该有动效,以及需要什么的动效应该包含在交互方案里面。

那交互文档里的动效使用什么方式来说明呢?目前我们团队的方式是:

交互设计师使用一些小图片,作为动效的分镜头说明;

同时配合文案描述,对UI或者交互讲解动效需求;

也可以让视觉设计师提供对应的动态效果图。

这里就不上图了,我估计这一条很少会有朋友去做的……

⑤需要特别注意的地方

还有一些比较特殊的地方,需要在交互方案里特别注明一下的。

有些地方不需要出视觉稿,只是个提示弹窗而已,这里给UI标注下就可以;

而一些空白介面状态,要搭配一些插画占图,那插画要反应出什么样的情感:

落寞,开心,悲伤,无奈,中性……,

理论上最好给UI同学写明一下:此处搭配的插画要体现XX感觉。


我们来总结下这期说了交互方案的哪些注意事项:

一、关于交互方案的介面样式和布局

  • ① Axure里的介面尺寸:375*667
  • ② 介面布局要规范合理,准确传达出介面的设计理念
  • ③ 介面色调尽量黑白灰,控件尽量不要使用具象图形,避免过多干扰视觉设计师

二、交互方案的流程设计

  • ① 一个页面,表达清楚一个任务流程
  • ② 每个任务要有起点,便于开发和测试清楚知晓任务功能入口在何处。
  • ③ 同一个介面的不同状态,尽量在一个页面内展示完整。

三、介面的交互说明需要标注哪些

  • ①需求功能的交互规则和逻辑
  • ②需求功能的迭代标示
  • ③操作的交互反馈和状态
  • ④介面的动效说明
  • ⑤需要特别注意的地方

结合前两期的内容,“一款APP的交互文档从撰写到交付”的主要内容已经完结。

这三期提到的交互文档撰写方式,是可以投入实际工作应用的方式,也是我目前所在公司在使用Axure时,正在使用的交互文档格式。

如果你有这方面的需求,可以尝试使用这种方式规范自己目前的工作流程和形式。

当然,无论是我以前写的UI设计还是交互设计系列,文章仅仅达到基础入门的程度。

其中的每一项内容都可以持续深入下去,不过那应该是我以后写的东西了。

这系列下期会把我目前使用过的交互设计工具来写写,其实工具用什么无所谓,目的都是为了便捷高效的完成工作任务而已。

那这期就到这里了,下期见喽~

原文地址:UI中国

作者:卤大湿

评论 (0)
请登录以参与评论。
立即登录