写交互说明容易忽略的几件事

6 评论 12844 浏览 57 收藏 10 分钟

上一篇文章写了画线框图需要注意的一些问题,本篇想说说关于写交互说明容易忽略的一些问题,供大家参考。

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

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

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

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

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

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

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

ux2

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

三、避免过长的说明

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

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

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

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

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

四、避免流水账式的说明

A 流程图代替文字说明

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

有些人可能会这样表述:

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

还有些人可能会这样表述:

ux3

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

B 表格罗列各种状态

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

ux4

C 巧妙组织文字说明

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

ux10

D 制作动态效果

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

五、关于重复出现的模块

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

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

ux5

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

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

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

看了下面这个图,相信大家就都明白了:

ux7

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

来源:PMTOO

 

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 你是《破茧成蝶》的作者?

    来自北京 回复
  2. 好文,学习了!

    来自浙江 回复
  3. 来自上海 回复