以下几点关于交互说明你千万别忘记

尽管我做交互工作已经有几年了,但还是时常会犯一些常见的错误,相信这也是其他设计人员在工作中会出现的:比如交互说明写的不够清楚详细,导致和前端、开发人员的沟通成本增高、返工增多、工作效率下降等。为了解决这些问题,一方面需要加强沟通,另一方面还需要多站在前端、开发的角度考虑交互说明的表达形式,使大家的配合更默契。

  关于交互说明的文章,网上也有不少,这篇文章不会讲什么是交互说明文档,也不会讲应该怎样写交互说明文档,仅聚焦于工作中容易忽略的几点问题以及个人的一些经验总结,希望对大家有所帮助。

  一、尽量使用真实、符合逻辑的数据内容

  以前我做交互时,更多的是考虑极端情况的展示(比如每个数据项里都写尽量大一点的数值),而不注重数据之间的逻辑对应关系,殊不知这样会给开发人员带来很多困扰。比如下面这个图,开发就会产生很多问题:网易价、优惠金额、积分、小计之间是什么关系?优惠金额和什么有关?而这些问题又和后台算法紧密相关。

  我之前还帮朋友做了一个票务产品的页面设计,当时为了省事,界面上的文案都是随便写的,仅作示意用。虽然自己觉得很正常,但是对方看着心里很别扭:没有这个票的名称啊,这里是什么内容呢?看不太明白……所以为了减少沟通成本,还是尽量使用真实、符合逻辑的数据内容比较好。

  二、不遗漏特殊状态的描述

  在写交互说明的时候,总是更多的考虑正常情况的状态,却经常忽略了一些特殊状态(用户极少用到)。但对于前端和开发来说,各种状态都是不能缺失的,否则会导致工作无法进行。

  比如上图,看似操作逻辑很简单:“勾选上面的人名后,下面会相应的显示对应的信息”。但如果交互说明只写这些,前端或开发就要疯掉了,他们会冒出无数的问题,比如:常用被保险人如何排序?最多显示多少?超出一行怎么办?名字有无字数限制?名字超长(外国人、少数民族)怎么办?勾选了3个人怎么办?重名怎么办?勾选人名后,在下方修改信息后怎么办?…… 而这些,都是交互设计师需要提前考虑到,并写在交互说明里的。交互设计师想的多一些,前端或开发就会省心很多。

  三、避免过长的说明

  还是上面这个例子,后来我们按照前端提的要求把所有交互说明都补充完了,内容很可观,写了一整页的标注,密密麻麻的。但是在评审的时候还是被拍回去了,这是为什么呢?

  我后来总结了一下,大概有以下几点原因:

    1. 需求或设计方案有问题,导致逻辑异常复杂

2. 这个方案开发成本是否很高,有没有这个必要?(有些异常情况出现频率极小,可以适当舍弃,保证体验和开发成本之间的平衡性)

3. 如果需求和设计方案都没问题,是否表述方式有问题?应尽量避免文字堆砌(具体请看下面“避免流水账式的说明”)

四、避免流水账式的说明

A 流程图代替文字说明举个例子,假如现在界面上有个“收藏”的链接,点击它会触发一系列操作,在交互说明上,我们该如何表述?

  有些人可能会这样表述:

  点了“收藏”链接,判断用户是否登录。如果没登录的话,就弹出登录框,如果登录的话,再判断用户是否首次收藏该商品,如果不是的话,弹出一个提示框(旁边配个提示框的样式);如果是的话,再判断用户是否首次收藏商品,如果不是的话,弹出收藏成功的提示,如果是的话……还有些人可能会这样表述:

  很明显后者更清晰,更有条理。当然为了让大家更容易理解,我找了个比较夸张的例子,一般情况下不会这么极端。我只是想说明一件事情:尽量用更有条理,更容易让人理解的方式来展示操作逻辑关系,而不要用流水账式的文字,这样谁看了都会晕的。

  B 表格罗列各种状态除了使用流程图外,还可以用表格的形式把各种状态图罗列出来。

  C 巧妙组织文字说明用“if、else、case”等来组织说明文字也是我喜欢的方式,当然开发更喜欢。比如下面的交互说明:

  D 制作动态效果如果有动画效果的话最好制作出演示效果(axure等软件可制作出很多逼真的动态效果)。

  五、关于重复出现的模块

  为了方便阅读,很多设计师习惯把交互说明直接写在原型上对应的模块旁边。但这样就会遇到一个问题:有些模块会重复出现在多个页面,关于该模块的交互说明如果只写一次,那么开发可能会找不到;如果每个页面都复制一份,开发可能又会疑惑(前后是否有区别?)更要命的是,如果要修改的话,所有页面都要跟着一起修改,工作量就会很大。

  比如下面这个模块,在购物车、个人中心等多个页面都会出现。为了节省时间,提高效率,我把这个模块独立出来,并起名“迷你收藏夹”,然后在其它页面上只留个空位就可以了。

  比如购物车页面下半部分要用到这个模块,那么我就在这里留个空位。这样我省事,开发也省事(很多模块看上去是类似的,给常用模块命名再组合,不容易出错,一目了然)。

  这个例子虽然看上去比较白痴,但是想通过这个告诉大家的是:尽量用模块化的思维方式来处理较复杂的问题,对提高工作效率很有帮助。

  六、如原型有修改,不要口头沟通,而要更新交互说明并告知大家

  以上就是我总结的一些小问题。其实我认为用什么方法不是最重要的,重要的是在合作的过程中,不仅把自己该做的做好,同时站在合作伙伴的角度上考虑问题,给大家提供更多的便利,才能使团队的效率越来越高,大家配合的越来越默契。

时间: 2024-09-20 18:40:25

以下几点关于交互说明你千万别忘记的相关文章

PL/SQL和SQLPLUS查询结果不一样——千万别忘记commit !

同样的sql语句,在PLSQL和SQLPLUS中的查询结果不一样,您见过吗? 今天在PLSQL的SQL Window中执行了一个查询select * from t_user;  查询到6条记录: 后来为了方便测试其他的数据,打开了sqlplus,执行了相同的查询语句,意外发生了: 只查询到一条记录,你没看错,同样的用户,同样的sql语句,同样的时间,在PL/SQL和SQLPLUS中的查询结果不一样.于是不甘心啊,又开了n个sqlplus窗口,执行结果都是只查询到一条记录.又在PS/SQL中另外开

移动应用交互设计中合理使用动态

一个优秀的交互师可以轻松地解释每一个动作逻辑背后的设计概念,包括信息框架,页面内容的继承,每一个点击动作对于页面跳转的影响等. 不久的将来,动效将被广泛的引入到原型的概念设计当中,然而随之带来的是交互设计方案的确定与分析变得越来越复杂.影响这些决定的原因当中,诸如“这样看起来很 炫”,“这样看酷”等等,将会让动效设计失去了它本来的目的.接下来,我们将试着站在用户体验的角度来定义动效设计,以及解释引入动效设计的目的. 什么是功能性的动效? 功能性的动效就是被我们引入到交互设计当中的微动效(moti

麦子学院android开发之Android应用开发视图优化步骤

1)View优化 i.   减少不必要的View以及View的嵌套层次. 比如实现一个listview中常用的layout,可以使用RelativeLayout减少嵌套,要知道每个View的对象会耗费1~2k内存,嵌套层次过多会引起频繁的gc,造成ANR. ii.   通过HierarchyViewer查看布局结构 利用HierarchyViewer来查看View的结构:~/tools/hierarchyviewer,能很清楚地看到RelativeLayout下面的扁平结构,这样能加快dom的渲

Android开发规范

一.Android编码规范1.java代码中不出现中文,最多注释中可以出现中文2.局部变量命名.静态成员变量命名只能包含字母,单词首字母出第一个外,都为大写,其他字母都为小写3.常量命名只能包含字母和_,字母全部大写,单词之间用_隔开4.layout中的id命名命名模式为:view缩写_模块名称_view的逻辑名称view的缩写详情如下LayoutView:lvRelativeView:rvTextView:tvImageView:ivImageButton:imButton:btn5.acti

产品UI设计排版的四个基本原则

相信很多初学UI设计的设计师,或者一些刚一边从事UI设计岗位,一边学习UI的,刚开始的时候都会遇到UI设计的规范,下面介绍四个基础的UI设计原则. 一.轴 轴在UI设计中是最基本.最常见的概念,也是用来组织界面结构的重要核心.简单说来,轴是在设计的时候组织一系列元素的假象线,在下面的设计图中,轴以虚线的方式被标注出来. 1.对齐 轴最常见于对称元素的使用,当元素被布置成轴对称的布局的时候,会给人有序感.就像生活中绝大多数的事情一样,我们更倾向于享受有序的的东西,它们令人感觉平稳.舒适.平易近人.

Android编程规范与常用技巧

一.Android编码规范 1.java代码中不出现中文,最多注释中可以出现中文 2.局部变量命名.静态成员变量命名只能包含字母,单词首字母出第一个外,都为大写,其他字母都为小写. 3.常量命名只能包含字母和_,字母全部大写,单词之间用_隔开. 4.layout中的id命名命名模式为: view缩写_模块名称_view的逻辑名称 view的缩写详情如下: LayoutView:lv RelativeView:rv TextView:tv ImageView:iv ImageButton:im B

走进MongoDB(五)---- 分片

本文从以下几个方面对MongoDB进行介绍 一.分片键组件 二.分片键 三.哈希分片 四.范围分片 五.区间 六.分片部署实例 Sharding概述 是分片.或者分区的意思.分片是一个数据库架构,可以通过key 范围拆分数据并且把拆分后的数据分散的存储到两个或多个数据库实例.分片提供了水平扩展的功能. MongoDB使用分片来支持超大数据集和高操作性能的部署要求.我们可以使用两种方法来支持数据量的大量增加和高性能操作要求:垂直扩展和水平扩展 1.垂直扩展: 通常是增加单机容量,例如.使用性能更高

Android 组件之Service解析

原创文章,转载请注明 http://blog.csdn.net/leejizhou/article/details/50866875 李济洲的博客 Service是Android四大组件之中的一个.Service主要作用于后台,能够进行一些后台的操作,它没实用户界面.它跟Activity比較类似,某种意义上能够理解为"Service是没实用户界面的Activity",那么我们什么时候须要使用Service呢?比如:音乐App正在播放音乐我们想切换到阅读App又不想让音乐停止就会用到Se

谈敏捷的好文章

敏捷思想的出现让我们看到了新的曙光--以更低的风险.更高的效率开发出更具质量的软件产品.正因如此,敏捷方法得到了业内足够的重视并使各路团队相拥实践.然而,即便我们对于各种敏捷原则.范式.方法和流程了如指掌,仍会发现其所给组织带来的改善远达不到我们的预期.这究竟是为什么?造成这种困境的根源并非我们学得不精,而是实践不到位. 在我看来,敏捷宣言过于简单(好吧,是宣言总得简单一点!),以至于足以让人对之产生误解.比如:"可以工作的软件胜过面面俱到的文档"容易让人忽视对必要文档的重视:&quo