1)打开聊聊,点击下方的,然后点击;(如下图)
2)点击打开要添加备注的好友,然后点击右上角的;(如下图)
3)点击,然后点击右上角的;(如下图)
4)点击,然后点击下方的编辑框输入备注名,最后点击右上角的即可。(如下图)
做交互设计近4年,参与过Web网站和移动App的设计,前者依托于PC的浏览器,后者则是依托于手机/平板电脑。不同的设备/平台均有各自的特点,以至于在设计这两类产品时也有些许差异。
今天就从交互设计的角度,聊一聊Web网站和移动App有哪些不同之处、以及需要考虑的设计要点。
一、用户与界面交互/操作的方式不同
Web网站:以鼠标或触摸板为媒介,多采用左键点击的操作,也支持鼠标滑过、鼠标右键的操作方式。
移动App:直接用手指触控屏幕,除了最通用的点击操作之外,还支持滑动、捏合等各种复杂的手势。
设计要点:
1、相比鼠标,手指触摸范围更大,较难精确控制点击位置,对此iOS人机交互规范中提到手指最合适的触控区域至少需要44 point。所以移动App的点击区域要设置的更大一些,不同点击元素的间隔也不能太近。
2、Web网站支持鼠标滑过的效果,一些tips提示通常采用鼠标滑过展开/收起的交互方式。在移动App则不支持这类效果,通畅需要点击特定的icon来收起/展开提示。
3、移动App支持的丰富的手势操作,比如通过左滑可看到你可能需要的快捷操作取消关注、删除,这类操作方式的特点是快捷高效,但对于初学者来说有一定的学习、获知成本。我们在合理设计这些快捷操作方式的同时,还需要支持最通用的点击方式来完成任务的操作路径。针对手势操作学习成本高的问题,一些App常通过新手引导的方式来教用户。
4、移动App以单手操作为主,界面上重要元素需要在用户单手点击范围内,或者提供快捷的手势操作。
二、设备尺寸不同
Web网站:不同PC的分辨率不同,浏览器窗口最大化的尺寸也不同;浏览器窗口可缩放。
移动App:设备尺寸相对较小;不同设备的分辨率差异化较多,特别是Android;支持横屏、竖屏调转方向。
设计要点:
1、移动App的尺寸较小,一屏展示的内容有限,更需要明确哪些信息更为重要,有效的组织相关联的内容,优先级高的内容突出展示、次要内容适当隐藏。
2、Web网站因浏览器分辨率差异较大、且窗口尺寸可变化,设计时需要确定好不同分辨率的内容展示和布局,也因为这一点加上webapp的浏览需求,近几年来响应式设计更为普遍。
3、因设备分辨率、dpi大小不一,所以移动App在界面布局、图片、文字的显示上,要兼顾不同设备的效果,需要设计师与开发共同配合做好适配工作。
4、因移动设备支持横屏、竖屏展示,所以在设计移动App(比如游戏、视频播放界面)时,需要考虑用户是否有换个方向看看的需求、哪些情况下切换屏幕方向、如何切换等。
三、使用环境不同
Web网站:通常坐在某个室内、使用时间相对较长;
移动App:既可能是长时间在室内使用、也可能是利用碎片化的时间使用,或站或坐或躺着或行走,姿势不一;
设计要点:
1、使用Web网站时,用户更为专注;
2、使用移动App时,用户很容易被周边环境所影响,对界面上展示的内容可能没那么容易留意到;长时间使用时更适合沉寂式浏览,碎片化时间使用时用户可能没有足够的时间、每次浏览内容有限,类似稍候阅读、收藏等功能则比较实用;用户在移动过程中更容易误操作,需要考虑如何防止误操作、如何从错误中恢复。
四、网络环境不同
Web网站:网络相对稳定且基本无需担心流量问题
移动App:因用户使用环境复杂,可能在移动过程中从通畅环境到封闭的信号较差的环境,网络可能从有到无、从快到慢tuLaoShi.com;既可使用无需担心流量的WiFi,也可能使用需要控制流量的3G/4G。
设计要点:
1、移动App,网络异常的情况更普遍,需要更加重视这类场景下的错误提示、以及如何从错误中恢复的方法。
2、移动App,在3G/4G情况下用户对流量比较重视,对于需要耗费较多流量的操作,需要提醒用户,在用户允许的前提下才继续进行。
五、通知方式不同
Web网站:对于浏览器的通知中心,用户使用的不多,很难主动唤起用户
移动App:推送通知给用户的方式很常见。
设计要点:
在移动App可以用通知及时提醒用户一些重要信息,但也需要考虑用户关闭通知提醒的场景下用户仍然能无碍的使用;因为通知功能对用户较为重要,设计师需要思考如何让用户更容易开启通知权限。
六、基于位置服务的精细度不同
Web网站:定位功能一般获取到的是当前城市
移动App:可较为精确的获取用户的当前位置
设计要点:
移动App可合理的利用用户的位置,给用户提供一些服务。比如,地图类可以搜索我的位置到目的地的路线,生活服务类可以查询我的位置附近的美食、商场、电影院等等,这样的方式省去了用户手动输入当前位置的复杂、更加智能化。
对于改稿无数的设计师来说,整理文件是一项不修炼不成活的重要技能,今天阿里的鸿影同学从如何归类与命名/常用组件的整理与沉淀/交互文档的规范等多个方面教大家设计整理的正确姿势,来收!
和很多人一样,我并不喜欢「整理」这件事情,我的桌子总会在一段时间后变得凌乱,电脑桌面也经常布满各种类型的文件图标。在具体的设计工作中,(仗着自己记忆力还行 + 有搜索功能在)也会表现得比较随性,存放设计稿的文件目录乱糟糟,疏于整理沉淀产品的设计规范,交付物的样式经常变来变去等。
(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/shoujiruanjian/)诚然,整理上的工作优先级不算高,经常需要给更重要的事情让路,在项目组人员很长时间都不会发生变化时意义相对也不大(因为大家都足够熟悉现在的工作模式)。但一旦出现项目变动人员交接搭档变化的情况,忽视整理带来的缺陷就会更容易暴露,也会给新的项目成员造成困扰,我还记得很久之前一次临时交接工作中讲解一些设计规范注意事项时的不耐烦心情,而对方的估计也一样头疼。(想起程序员最讨厌的事是自己要写注释和别人的代码没注释这个梗,其实设计师也有类似情况的233)
文件夹的归类与命名
(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/shoujiruanjian/)我在前一家公司实习的时候,大家的设计稿一般存放在Server上,并且有些比较约定速成的归类与命名方式(目前记得的有按版本分成V1V2ArchieveLatest,或者按时间分成201X-XX,一组高保真设计稿按交互流程前缀上0123),当时的老板会在组会上当场Review大家的设计文件存放方式是否规范(比如.psd和.png要放在不同的文件夹,不能混在一起),否则挨罚。不过我有一点一直做得不太佳,就是会慢慢把文件目录搞得过细过深而疏于重新整理归类(懒),结果反tuLaoShi.com而影响了查找东西的效率。
这样的好处是别人(上级、项目组伙伴、其他设计师)看你的设计成果时能一目了然,迅速找到想要的东西,而不是迷失在混乱的版本管理与各种类型的文件海洋中,也相对不容易出现拿旧的设计稿开发完才发现不对的情况;你也可以更方便地浏览别人的设计稿、寻求思路借鉴。作为用户体验设计师,在公司内部和他人合作时,也要注意怎么带给别人更好的体验。
常用组件的整理沉淀
大公司的大型成熟产品线通常都有一份完整的设计规范,沉淀了各种常用的组件与使用原则,这样的规范可以帮助新人设计师迅速熟悉和接手工作,将更多精力聚焦到对业务和用户的理解与思考中去,而非纠结已经很成熟的组件设计上的细节。
但如果是做从0到1、偏偏还比较复杂不是一两个内嵌页面了事的产品设计,有必要时就需要自己动手丰衣足食了。起初做这样的产品时,我对组件与规范的沉淀不以为意,也磕磕绊绊完成了第一期的上线,后来不断增加新页面新模块的设计时,都是凭借自己的记忆从旧设计稿中找到可以复用的组件,但随着时间推移记忆负荷与查找成本也有所上升。后来趁一个比较空闲的工作周里做了一下网站组件的统一梳理沉淀,并参考其他部门一些成熟的设计规范,写了相应的使用场景与原则,进一步加深了自己对组件在交互设计中如何运用的理解,也希望让自己之后设计工作里查询复用、甚至项目变动需要交接给他人时变得更加方便。
交付物的规范化与实用性
刚来现公司实习不久时,写过一篇设计文档相关的文章:如何写好一份设计文档。随着时间推移,我发现自己的设计交付物虽然整体框架上还好,但细节上是有各种问题的,所以也在不断地迭代优化。后来偶然接手了一个之前由天猫设计师负责的小项目,进而又通过内网发现天猫的设计师们有一套相对成熟的交互交付物规范,包括任务流程、用户路径、信息架构等,都有比较完整的模板,比自己摸索出来的交付物要成熟不少,注释细节之类的信息很完整清晰。
但在实际工作中我发现,交付的规范、严谨、说明全面的交互文档可能并不一定能起到很好的效果。比如前端未必有耐心去阅读你那大段的文字,一个简单的交互动效,用Axure直接模拟出一个可以交互的高保真效果演示给他人,比口干舌燥地描述上一大段效果要好得多;又比如常见的「左侧标记数字,右侧空白写说明」的布局模式,在PC端的产品设计稿中(APP端应该还好)右侧经常会被人忽视(意识不到页面还能横向滚动一下),也提高了反复沟通确认的成本,所以我更倾向直接在设计稿上控件的旁边直接标注,虽然会对美观性产生一定影响。
《交互设计沉思录》一书中就批评了UX经理把时间花在华而不实的文档管理工作上的现象,指出文档的时间维度体验表现力偏弱,而可用原型会是一个更好的替代方案。在规范化交付物提升专业度的同时,也要注意观察搜集他人实际的反馈效果,并进行调整改进,不要忽视了实用性。
欢迎关注作者微信公众号: