Saga

Wx: saga_jeanne
欢迎互联网同好加weixin

需要注意的交互细节——no.24

关于模态窗口的使用:

不得不承认,在交互设计的时候,模态窗口还是很好用的(特别是在web端设计的时候),因为他可以让用户不用打开新页面就去完成一些复杂的任务。

但是,在使用的时候,还是觉得要谨慎一些,不要想当然地去用模态窗口(说真的自己有时候也会偷懒,想想直接开个模态窗口就好了)

举个例子:


上面的图片是一个简单的地址填写。当确定后,会变成下面的样子:


因为用户可能出现填写错误,要修改的情况,所以这里需要进入一个重新填写的状态,可能不假思索的就觉得,那用个模态窗口就好了:


但是仔细想想,点击修改直接回到图1的状态不也可以解决问题么?而且从代码的简洁性和体验的一致性来说也会更好些...

2016-03-12

需要注意的交互细节——no.23

未读数字的消除:

是这样的,很多集合都会有未读提醒。 比如新的喜欢,新的评论什么的。这里的做法还是有蛮多讲究的。

本人觉得有个体验是蛮不好的,那就是!慢!

所以说说数字消失的问题吧。最好的体验,当然是读完内容出来,未读计数就要消失。不过,有时候因为开发会做成服务器同步,因此数字消失会出现一些延迟,让用户觉得很难受...(好吧...真的应该要盯开发盯的紧一些)

所以很多时候,不仅仅是设计那么简单,用户体验更要同步给开发,让开发去思考体验的重要性。

凡事都需要一个过程,但是我们一定要不停进步。

2016-01-26

需要注意的交互细节——no.22

创建和编辑的差别:

只是今天突然又看了下钉钉的创建/管理团队流程。所以突然想写点东西了。

很多内容在被创建的那一刻就是注定要被编辑的~比如一个团队的信息,比如一些长长的文章。感觉创建和编辑还是蛮不一样的两个场景。创建的时候,用户会期望能简单地操作,快速看到创建完的结果。而每次编辑,则会更用心,希望编辑是有效的,因为这时候已经了解了会创建的东西是什么。

所以创建的时候,除了基本信息,或许不要让用户操作太多~比如第一次创建团队,先不用处理组织架构什么的,让用户先看到团队就好。添加人的时候,也是一个批量选择,而不用自己填写太多内容。

而编辑的时候,添加成员就会多出很多部门什么的选项。

其实...

2016-01-17

需要注意的交互细节——no.21

webview的加载问题:

webview的加载还是不要用模态加载了。

其实很多时候加载的内容已经出来了,用户已经可以先查看内容了(往往确一些大图),而模态加载会锁住整个页面,不能滚动,体验会很不好。

所以在app内做webview的时候,最好还是用类似微信的顶栏下方进度条更好,那样不会锁住下面的页面,即使加载一半,也可以让心急的用户先开始浏览内容。

ps:如果直接判断到加载失败,别忘了直接在页面做个点击刷新哦,会很方便的。不用去右上角的...里找刷新了。

——————

最近有些低产,因为要处理的事情有些多,还要准备交互设计的微专业。

本来还想做quartz composer的教...

2016-01-05

需要注意的交互细节——no.20

关于进入评论页面:

好久没更新...今天感觉也是个酱油更新。

只是今天正好碰到这个问题,就写一句吧~

很多app会做评论页面,然后进入评论往往有很多入口,比如评论的icon,或者是放在外面的评论内容。其实点了以后都是进入页面,但是还是有些细节要定义下哦:

1. 键盘要不要弹出:用户进入评论页面无非两种心态:要么想自己写,要么想看。需要去分析下用户点按钮的场景,来确认要不要弹出键盘。

2. 要不要进入回复状态:还是一个道理,要考虑下,点击某条评论是不是想回复哦。当然如果进入回复状态,需要做一些定位(最好是把输入框定位到评论下方)和键盘弹出的处理。

————

感觉...

2015-12-28

需要注意的交互细节——no.19

让用户感觉快速地看到新消息:

一直感觉微信朋友圈的新消息提醒做的很不错,每次看到tab上数字提醒到进去看到真正的消息的过程,都感觉没有任何等待,可以很快完成。

要做到这样,真的需要用心去处理服务器和客户端的交互机制。比如数字提醒要和消息内容同时下发给客户端,而且要直接保存掉这些新信息,然后第一次只显示新的通知,让用户不需要花很多心思去区分哪些是新的,哪些是旧的。

之前在易信也想做成和微信一样,但是体验起来总是觉得从入口到消息列表还是有一丝卡顿...看来微信在这些体验细节上真的很用心。

不得不说,很多设计是做在看不到的地方的,特别是交互。从前总是追求一些表面上很酷的设计,但是做的越多,越...

2015-12-24

需要注意的交互细节——no.18

移动端的评论设计:

说真的,觉得评论设计还蛮麻烦的,存在各种各样的冲突。

首先我们来说说考虑顺序,一般来说先要确认下正序(微信那种),倒序(为了更方便看新评论,比如网易新闻,微博),根据你产品的评论数量,用户的阅读习惯来定喽~。

然后要考虑一下,评论是单独给一个评论页面呢,还是和内容结合在一个页面。如果你要选择结合在一个页面,那么注意,因为上面要放内容,所以你的加载一定是在底部加载更多评论啦。

当然,下一个问题就是你准备怎么设计评论框和评论结束的反馈啦。(不过个人觉得这个反而最次要)一种做法是微信那种很nice的评论完了直接让你看到那条评论。不过微信很nb的就是没有加载评论的过程,而是...

2015-12-19

需要注意的交互细节——no.17

让用户完成操作以后可以找的到&新手引导放哪里:

今天的用研测试,研究员告诉我新用户订阅了标签以后,不知道订阅在哪里...

仔细一想的确有这个问题,因为按现在设定的新用户操作路径,新用户在进入标签页面前,可能根本没看到过订阅那个tab。

所以这边就应该有个新手引导了对不对!

其实很多引导放在一些不经意,但是用户真的需要的地方(比如完成了某个操作)会更贴心,当然,这需要一个交互设计师对于场景有非常深入的思考哦!

ps:确保用户的每个操作都是能明白的也很重要哦(订阅后要知道在哪里可以找到订阅)~如果真的出现了这个问题,在第一次的操作后一个简单引导会蛮有用的~

 @本本 ...

2015-12-09

需要注意的交互细节——no.16

关于响应式动效的一些话:

其实现在动效还是蛮流行的,dribbble上好多大神用AE做出酷酷的效果,BUT...做到app上的其实蛮少的。

其实AE上实现的真的做到app里还是有蛮大距离的。

有段时间自己对响应式的动效很感兴趣,这里就分享一些关于那个的经验吧。

响应式动效是指把用户输入的一些参数(一般是手指在某个轴的位移)映射到一个界面元素的动效(比如当年微信还有下拉小视频的时候,慢慢下拉会出现的那个眼睛)... 一般简单的就是映射到元素的位置,大小,透明度什么的,而且常见的映射方式也都是线性。

但是,如果要做的好玩,可以映射到贝塞尔曲线的参数(比如qq那个拖动红字提醒消失...

2015-12-09

需要注意的交互细节——no.15

某些按钮,需要fix到屏幕底部:

今天看到一个同学做的活动页面交互稿,页面里面有长长的介绍,感觉还蛮吸引人的。然后,在页面的最后给出了一个领取优惠券的按钮。

不过考虑一下自己是用户的话,好像并不会真的把十几张图看完才会想要优惠券,估计看几张图就想要了吧~ 所以这种按钮还是一直固定到页面底部比较好。

关于长页面里,什么按钮要fix在底下呢?两种吧,1是用户一来就会找的东西,2是你希望每个进入用户都去操作的。

特别是你希望用户去操作的那个按钮,有些活动/推广页面,你不知道用户会因为哪一句话而萌生购买的意愿,所以把购买一直放在底部,还是挺好的^  ^

貌似很简...

2015-12-05

需要注意的交互细节——no.14

移动端h5页面的列表——详情页面进入问题:

手机刷h5页面其实还蛮痛苦的,由于本人一直处于网络不那么好的环境里,所以h5页面的刷新一直让我很头痛地要处理的问题。

在交互范式中,列表——详情页的跳转非常常见(简直每个app都有了呢...比如什么商品列表到商品详情页)。

所以这里就需要强调一个问题:如果说用户进入详情页面后,返回列表,去完整刷新列表,那会导致用户丢失浏览位置,体验很不好...如果不刷新,那可能导致用户在详情页面的一些修改无法体现到列表页上,体验也不是太好(让用户疑惑是否操作成功)

所以一般来说提醒开发按照一种交互规范来做比较好:1. 保留用户在列表的阅读位置,保留...

2015-12-03

需要注意的交互细节——no.13

关于一些多tab刷新的处理细节

看了几个app对tab切换和刷新的处理:
1.云阅读和易信会取缓存,下拉不刷新,或只刷当前页;但是切tab时会有突兀地跳跃感,感受不太好;
2.in不取缓存,每次切tab都刷新,且回到顶部,逻辑简单,但是感觉太耗流量没必要
3.微博和贴吧的做法比较稳妥,切tab时tab位置保持固定,取缓存(除了贴吧每次切tab是会刷新日志时间信息,其他内容不刷新);刷新只刷新当前页;切tab时如果是新加载则在页面中间转圈,不存在回到顶部刷新的问题
结论:微博和贴吧的比较好,建议采用

2015-12-02

需要注意的交互细节——no.12

关于报错的一些细节:

其实一般报错也就是三种形式,toast/alert/输入框类的在输入框下方直接给出错误原因。

toast的话,一般都是显示2秒,用户提示一些网络错误等内容(用来提示一些和用户操作无关,仅仅是客观原因导致的问题较好),特点呢就是文案比较短。不过在具体样式方面,着实觉得原生的不大好看,所以感觉还是自定义优化一些比较好(比如ins的样式还蛮不错的)。ps:在屏幕中间出现的toast会禁掉操作,这个有时候也会让用户有些不舒服。

alert,就是会出现一个“确定”按钮,需要用户点击才消失。这一类用来提示用户行为导致的错误比较好,因为需要用户很明确为何出错,所以才要用户点一下确...

2015-12-01

需要注意的交互细节——no.11

顶部多tab页面的刷新放哪里:

最近正好被这个问题给坑了一把,所以就来记录一下吧。

其实现在很多时候会去设计顶部多tab页面,而tab下面放上动态流,所以也就是会有刷新操作。对于刷新的位置,希望遵从一下以下原则:

1. 如果tab上面没有其他内容,或者上部内容较少,最大高度可以计算。则可以把刷新放在tab下方,这样的体验感觉会更顺。

2. 但是!如果tab上面有其他内容(比如很多个人页面会这样),内容较多或干脆无法计算出最大高度(因为包含用户填写内容)。那么请把刷新的位置放在整个页面的最顶部,而不要放在tab下面,因为那样会导致给用户的刷新位置不够,而根本没法刷新....

2015-11-28

需要注意的交互细节——no.10

活动规则太长怎么办:

以前做运营活动页面,总是会碰到一个情况,就是会有很长很长的活动说明,还有不少是为了免责写的(比如,最终解释权归xxxx)。这些文案不放出来吧,用户会迷茫,放出来吧,又容易把操作按钮弄的看不到。

所以,慢慢就养成了一个习惯:先会提取说明中最能吸引人的部分(比如送奖品那部分)做成大字报或者是流程图之类的东西。然后,把剩下的那些其实不太想让人看的,放到一个小入口(查看详细规则>)里面。

很好用的方法,推荐哦

2015-11-28

需要注意的交互细节——no.9

关于状态切换开关的细节:

iOS上到处可见状态切换的按钮,有些状态切换会和服务器进行交互,不过这里为了体验,最好让客户端记住开关状态哦,然后默默地把状态传给服务器。不然可能会出现在用户刚进入页面时获取到的默认状态和用户心里预期不符的情况,这样会让用户觉得很奇怪。

如果是web上做这类开关会麻烦些...所以比较建议web的切换开关补一个loading的状态吧,其实iOS系统那个过度动画停留一下的效果还蛮好的。

很简单的小细节,不过还是注意下为好哦~

2015-11-27

需要注意的交互细节——no.8

关于iOS的推送权限获取:

基本上所有app都会需要获取iOS的推送权限。然而iOS系统的权限获取弹窗只被允许出现一次,还不让改文案,这个会导致很多用户第一次就取消了,之后因为没有push,而你的app的留存也就下跌很厉害。

因此这里说几个比较常见也亲测好用的方式:

1. 在一开始先告知用户为什么要获取权限再获取。很多用户是因为不了解你的app而取消的,比如一个相机类app问我要推送权限,我就会取消,因为觉得你不应该问我要。所以明白告知用户你会推送什么给他,会增加打开权限几率。具体操作就是先自己做一个提醒,让用户选择开启/不开启,不开启就不要弹系统的了,把机会留下来。

2. ...

2015-11-25

需要注意的交互细节——no.7

关于0状态:

很多时候我们的设计都会去设计有,比如我们会设计有100个赞的时候怎么显示。但是往往最容易忘记的确实无。

所以,每一个页面中的每一个细节,都必须去考虑,如果某些用户产生的内容不存在要如何处理(比如一篇文章没有被点赞,没有评论,或者某个页面没有文章)。这里一定要是被设计的。

一个比较好的做法是在空白状态下给予用户一些操作引导,比如没有内容引导用户发布内容,没有赞引导用户点赞。

但是!一定要注意这样的引导的出现频率,如果太多了...或者为了做引导而做则会有些让用户反感了。

总之:一定要用心设计每个0状态,但是不要过度设计,引导往往是锦上添花的,而不是不得不有的。

2015-11-24

需要注意的交互细节——no.6

关于某些没有边框的按钮:

很简单...如果你的视觉设计师设计了一些没有边框的按钮,比如微信的那个+号...一定一定要提醒开发:把点击区域做大一些!做大一些!做大一些!

<经常点不中按钮的指端肥大患者的内心OS>

2015-11-23

需要注意的交互细节——no.5

关于语音播放:

在做语音外放的时候注意要增加一个小细节哦,就是如果放到耳朵边的时候要把外放切换到听筒。

这个其实很多app都会做的,不过还要记得提醒开发再补充一个细节:检测到距离近的时候,要锁住屏幕哦,不然像我这种脸太大...经常会用脸碰到屏幕...然后语音就停止了...这个会让用户很沮丧的!不仅仅是因为要再听一遍,也因为你证明了用户“脸大”...

2015-11-23

需要注意的交互细节——no.4

关于消息页面的处理:

现在不少的消息页面都喜欢分tab,这也很好理解,因为随着app的发展,我们需要提醒用户的越来越多...而也的确有分类的必要。

那么有一个小细节就请一定要补充到你的交互中哦!如果有新的push消息来,用户点击消息tab的时候,务必定位到那个有新消息的tab,让用户省掉这一次点击感觉会挺好的。(如果多个tab有,给个优先级就好了)

很简单的处理,但是会很贴心哦,所以千万别忘了哦!

2015-11-22

需要注意的交互细节——no.3

关于无限堆叠页面:

其实像LOFTER这样的产品,在不停探索浏览的时候,很容易进入一种循坏:文章——个人主页——文章——个人主页——...然后,你的栈里面会有一大堆页面堆叠着。(其实微信也会,只是几率不大,你可以开始一个名片——相册——名片——相册的无限循环)

讲真的,这个还真没什么好的处理办法,所以讲一个以前用过的方法吧。其实挺粗暴的...为了防止无限堆栈导致很难返回,所以以前做过最多只留5个页面的处理。不过最近有个新的想法了(感谢Song大师提供创意),最近会考虑做到LOFTER里

2015-11-21

需要注意的交互细节-no.2

今天要写什么呢...讲下关于iOS7开始加入的原生返回手势吧。

从屏幕外划入返回的手势其实和滑动切换tab是不冲突的,苹果是会判断成两个手势的。不过有些app会自定义滑动返回的手势,那就很有可能会有冲突问题了。(想说现在的LOFTER也有这个问题,可惜没空改...555)所以还是强烈建议用系统原生的返回手势,好像是某个viewcontroller自带的。

ps:曾经这个手势有个和透明顶栏的冲突问题,所以现在易信的朋友圈个人页面还不支持这个返回手势,不过看到qq已经修复了,应该是苹果已经修复了吧>  <

再ps:android就不要加这个返回手势了,很不android...

2015-11-21

好久没更新交互文了

最近也发现了很多交互的问题,准备写个交互设计师设计细节注意手册了,估计会是蛮长的东西要慢慢更新,先发个前奏看看有没有人需要吧。

例如——

需要注意的细节1:

当你做分享流程的时候,一定要记得分享到微信好友/微信朋友圈/微博的样式是有区别的哦!所以不要忘了分别给文案!另外,如果需要回调分享成功的话...记得如果微信被home掉就回调不了了...所以还是有坑的哦!

还有好多这样的东西...感觉应该总结下。

2015-11-20

© Saga | Powered by LOFTER