首页

电视语音助手设计总结-一套完整的用户体验优化流程

雪涛

语言交流是人类的本能,近几年语音交互的迅速崛起让产品更加人性化了。然而即使不考虑技术限制,人与机器的互动也不是只有听或说单一模态的,因为这不符合我们的自然交流。目前,在居家场景中,用户与电视的交互依然是对众多信息-图像、语音、触感-的同时处理,它们分别对应着观看、听说和必要的遥控器操作。对UX设计师而言,如何让电视端同时承载这样多的感知设计是值得思考的。


语音体验设计是一个很大的系统,从用研、功能、内容到交互、技术实现等等,而GUI的展示只是一种辅助模态。今天我想探讨的是如何结合GUI与VUI展开界面设计。


文章分两个部分:电视端VUI的搭建和一次改版迭代。



目录


1. VUI的构成

2. 改版需求

3. 界面改版

4. 设计验证



1. VUI的构成


“Voice User Interface (or VUI) is an interaction model where a human interacts with a machine and performs a set of tasks at least in part by using voice.”

 <Voice User Interface Design>


1.1 定义

VUI:是一种交互模态,让人能够或多或少通过语音交互与机器共同完成一系列任务;

领域:是将用户想要完成的任务分为一些大的类型,比如视频领域、音乐领域、百科领域等;

意图:指某领域下的具体任务,比如视频领域下的“我想看某部电影”,即为影视搜索意图。


1.2 场景示例

小明:“给我推荐点美剧”;

电视:“看看这些有没有你喜欢的”,并推送一些热门美剧;

小明:考虑了一会儿....说“风骚律师吧”;

电视:起播《风骚律师》。


在这个故事中,除了众所周知的VUI应具备的基础功能-听和说-以外,我们还需要定义更完整的体验流程:

1. 小明如何开启与电视的对话?因为电视机不能一直处于聆听状态,那样很可能会识别用户无意图的语言,从而误响应。
2. 电视端应该以什么方式推荐美剧?如果只一个个播报片名,小明会记不住。

3. 推荐几部合适?隔空喊话的情况下(远场语音,下图解释),最好不需要再用遥控器翻页。

4. 如果小明问的是其他领域问题,比如天气、歌曲、球赛等,对应的媒体资源会涉及到多样化的信息类型,如图形、音频等。不仅要统一设计风格,还要为未来可能支持的新领域/新意图预留承载框架。

5. 如果小明的询问得到了错误答复,或者一直未被答复,除了技术上提高识别率和语义理解程度,该怎么缓解用户的茫然和愤怒情绪?

6. 当小明问了一个问题,不被理解,但换个问法却成功理解。如何教会小明尽可能一次就做出能被识别的表达?

7. 我们能支持几十个领域、几百种意图,怎样能让小明知道一共有哪些? 

8. 如何结束对话,以免电视一直聆听造成误识别?

9. ......


为了回答以上问题,我们经过大量的模拟对话、竞品分析和demo体验,从而定义了电视端VUI的交互流程和组成模块:


1.3 交互流程

唤起、聆听、思考、反馈、退出:


电视端的语音有三种对话状态:

1. 单轮对话:每说一句话都需要唤起一次语音;

2. 多轮对话:一次唤起,多轮对话,但轮数受限于领域范围;

3. 全双工模式:一次唤起,多轮对话,轮数不限。

图源网络


1.4 GUI模块

这是本文重点描述的部分,电视端的GUI包括:

1. 状态指示动画:告知用户当前状态;

2. 提示词条:提示用户有哪些说法;

3. 用户指令:用户说法的文字识别结果,它让人知道自己说的话是否被正确识别,若出了错,用户就知道原来是错在这一环节;

4. 电视答复:文字+音频;

5. 内容展示:所有媒资内容的呈现,如果没有,则不展示。比如,天气需要展示图像,而交通限行用一句话回答即可。


旧版设计方案概览:

undefined


语音GUI分为两块:语音基础界面(必须)和内容展示区(可选),基础界面包括上图中的1234内容。



2. 改版需求


上图效果是从17年逐渐搭建起来的框架,随着需求增多、不同设计师的参与,设计越来越碎片。从易用性、视觉、开发维护难度和新功能兼容上,都存在很多问题:



2.1 设计目标


1. 布局调整

由于电视用户使用最多、最重要的功能是观看影视,所以优先考虑视频领域。因此布局调整的优先顺序是:基础界面>视频领域>其他领域。


2. 建立视觉规范

建立原子化设计规范:配色方案、文字、间距、圆角、图标,以及可复用和拓展的组件、模版。


3. 统一状态动效

将上文的5种基础状态结合全双工状态统一设计,并为未来可能开发的主动提示等状态,预留一席之地。



3. 界面改版


3.1 语音基础界面

经过竞品分析,穷举了7种可能的布局方式:


这么多的优缺点该如何取舍?我们将痛点归类,并根据通用的交互原则排列了优先级:

undefined

最后决定用B1-底部长矩形,但设计UI时需要借鉴B2那样增加一点渐变过渡。而针对B1的痛点,需要重新设计小面积状态指示动画,并定义好低栏左侧的识别文字与右侧的提示词条之间间距,从技术上,我们能做到跟进用户说话和播报内容,说一句、展示一句。



3.2 内容展示区-视频领域

电视端就像是一块自由发挥的大画布。视频海报的摆放,得从几个方面考虑:

1. 背景占比:半屏、全屏、半屏至全屏;

2. 导航方式:宫格(我们的海报尺寸是可以统一的,所以不考虑瀑布流,此阶段也没有专题分类,无需考虑tab栏和泳道栏);

3. 海报方向:横幅、竖幅;

4. 展示数量:是否超过一页、海报尺寸。


市面上的竞品就有这几种方案:


行为数据显示,我们用户的视频意图分两种:明确自己想看什么-“播放陈情令”,和不明确目标、向电视寻求推荐-“推荐点古装剧”。我们分别称为普通推荐和个性化推荐。由于前者在大多数情况下内容较少,所以用半屏,后者则用全屏。由于视频会单独设计一个APP,故最后定的普推和个推的坑位都是十张:



3.3 内容展示区-其他领域

上面确定了视频领域,而其他几十个领域的信息,同所有平面设计的信息一样,都是文字、图片、图标的排列组合,可以把它们按照原子化设计系统,从分子到模版逐步搭建:


这样的结构,能确保20多个带内容的领域都能从中找到对应的排列方式,模版如下表。这里看起来可能比较抽象,可以先看后面的UI效果图再回来看这里。

undefined


3.4 内容展示区-背景

实际界面中,内容可能会以前面的任何一种排列形式出现,给较少的内容使用大背景是浪费,反过来则拥挤杂乱,故不同内容需要不同的背景。依然还是穷举了5种背景待选择:


1. 卡片 

2. 悬空半透明容器

3. 半屏羽化背景

4. 半屏实心背景

5. 全屏背景


按照痛点的优先级打分:

undefined


可见方案d-半屏实心背景最佳,但它最适合内容量级为中等的情况。所以我们考虑了是否也采用卡片和全屏来适应内容过少和过多的情况。最后结论是:只采用方案d和e,舍弃a,因为d的背景高度可以随内容的多寡而变化。这样以来,设计就不会很碎片化了。



3.5 设计规范与效果图

到这里,已经确定了语音基础界面(低栏)、各领域信息排列方式和背景。接下来就像搭积木把它们组合起来,这一步重点考虑的是内容是否上焦点和翻页,这需要根据具体领域的资源参数和使用场景甄别。


正好在做这个项目时,我们电视端的视觉规范也在完善中,所以焦点色、文字、栅格等规范是直接从规范库搬过来的。


实际效果:(抱歉GIF原图太大了,只好展示一小截。手机拍摄有一点色差,实际的色彩还原度是很高的。)



4. 设计验证


我们找来40名用户体验新旧版本语音,进行了偏好测试和用户反馈收集,部分反馈如下:


40名用户中,有80%认为新版更好,分别有12.5%和7.5%的人认为两者差不多和旧版更好。这次的改版中,UI&交互、动效、颜色&背景三者,体验感分别提升了12%、2%和7%。


当时大家对新版评价最高的是:简洁易看、空间利用率高、布局更好。

吐槽最多的问题是:背景色太深、配色单一,动画不够好看、不够明显。我们随即对背景色做了优化,上图看到的是优化后的效果。


后续兼容性验证:新版结构能较好适应节假日换肤、半屏小程序、第三方App适配等多种需求。



小结


文章复盘了电视端语音的基础界面、视频领域、其他领域和背景的重构过程。主要用到的方法有原子化设计理论、竞品分析、痛点云图(表格形式)和用户偏好测试。对界面布局有较好的优化效果。最大的收获是掌握了从最底层元素展开剖析的方法,这种细致的方法用来搭建界面设计会很稳固、全面,并且拓展性强。


经验和不足:

1. 大屏经常强调沉浸式体验,因而电视端叠加功能很多,但必须要注意分个主次。一是叠加内容不能太多,要么就不叠加、全屏展示。二是一定要考虑背景播的不确定因素,避免花乱;

2. 上面只是分析了二维平面,还有次级页面、时序等三、四维的规则还未深入学习研究。这样的研究会对所有App设计都有更好的指引。

3. 我们虽然已有了简单的导航、栅格等布局规范,但内容展示区依然是毫无章法的自定义排列,智能电视产品还没有像手机、PC一样较成熟的设计框架,我觉得苹果的tvOS模版规范做的比较稳定,我们也应该借鉴,形成自己的风格。



文章来源:优设  作者:lady珠珠

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


没有用研团队,如何快速展开用户调研?

雪涛

每一个在公司勤勤恳恳埋头耕耘的设计师小朋友,都常常会在脑海中不禁闪过各种问号:

  • 这功能做了到底谁在用呀(黑人问号脸)?
  • 新上的这个功能简直绝了,做了真的好(neng)用吗?
  • 产品经理你加这么多东西想过用户怎么看吗(鼻孔张大)。

但是苦于只有极少的团队会匹配用研资源,这些疑问往往是石沉大海。更有甚者,等到用户流失才心急火燎的改版。

在日常工作中,由于 UI 设计师在业务的中上游,很难直面用户,不能获得直观的第一手资料,很难获得用户体验的话语权,经常被产品和运营牵着鼻子走。长此以往,设计部门的存在感也也会大打折扣。

那么我们怎样在势单力薄的情况下在用户体验上做一些工作呢?笔者结合这些年的摸索经历,谈谈怎么一步一步从小到大的探索用户体验的调研。

快速的展开初期调研

在初创业务或公司中,人手和资金往往都比较紧张,很难系统的对用户进行调研。这就需要设计师本人用最小的成本推动用户调研和用户体验的提升。这个阶段调研的内容应主要集中在产品的可用性方面,以定性调研为主,输出的结果也不求高大全。

我们可以通过以下几个手段进行初期信息积累:

1. 后台用户投诉或反馈

用户常常是懒惰的,当用户在系统中投诉时,一般都是遇见一些令他无法忍受的严重问题。设计师可以把后台的反馈内容都搜集起来,内容加以分类甄别。一般会有可用性问题、业务问题、情绪表达等内容。这些不是我们都能处理的,我们应优先从可用性问题下入手,解决一些功能上的阻碍,这就足以解决许多关键环节的体验问题。而情绪表达类的留言也要留心总结,里面能够折射出用户的消费心理和需求的痛点痒点,为未来的设计提供指引。

2. 粉丝用户群

运营和客服同学都会组建一些深度用户为主的粉丝群,在这里你能看到各式各样的吐槽。设计师同学潜伏其中,不但能聆听用户心声,也可以发出问题,主动收集反馈。这里的粉丝也很乐于沟通,并接受轻松的访谈。但是粉丝一般是中高级用户,所以初级问题容易被忽略,这需要更加广泛的调研来补充。

3. 内部招募体验

这是一种非常直观且有意义的调研,在项目初期阶段就可以检验出产品中存在的问题。

方法如下:邀请公司内部的同学现场使用产品,在操作时汇报自己的所观所想。设计同学可以在一旁观察和引导,并在用户进行不下去的时候给予必要的帮助。招募 3-8 个初中级用户,往往就足以发现产品操作流程中存在的绝大多数的问题。在此情境下的用户一般都更加有耐心,所以足以使它们停顿、困惑甚至放弃操作的问题对外部用户影响更甚。最好全程录像,更有利于事后分析对比。

4. 内部专家访问

在一线的客服、运营、销售等同学往往对用户都有着更加深刻的认知。由于他们的工作目标不一样,所以他们的精力不全在改善用户体验上。但对于用户的痛点他们有更强认知,也有自己的调研积累,这是我们极佳的信息来源。与他们进行访谈会听到很多真知灼见,他们也很愿意配合一些调研活动,如投放问卷、联络访谈用户等,这是我们不可或缺的助力。

5. 数据挖掘

技术同学对于用户信息会有一套基础的统计,通过他们的帮助,我们能了解用户的使用机型、使用时间、活跃时长、分布城市等,从而确定主要的使用场景和人群。用户是否有跨平台的操作习惯也能在这里展现。埋点和 A/B 测也是后期极为重要的工具。

没有用研团队,如何快速展开用户调研?

△多渠道搜集用户反馈

从用户着手进行深入调研

当业务有一定规模时,设计的目标就不仅仅限于可用性问题的研究了,我们需要对用户和业务有更深入的了解。用户群体不同,需求也会有差异。我们调研时,如果不清晰的划分用户群体,就会造成数据失真。这样的调研结果,对设计的指引将大打折扣。比如相机这种通用功能,也会为高级用户做出个性化设置。它没有假定色温调节是多数人都需要的,而给它一个外露的位置。但也没有主观臆断此功能无人使用,而把它删去。

这时就需要我们去系统调研用户了。

1. 划分目标用户

系统调研的第一步就是划分调研的目标用户。

很多时候设计师都希望输出一份全面的用户画像,显得高大上而富有意义。但是精准的用户画像成本很高,往往在建立后又不知道如何使用。其实建立用户画像是个细分后并不断修正的过程。

用户一般可以分为以下几类:

  • 核心用户是指符合主要业务指标的活跃用户群体。
  • 普通用户是已注册,有一定活跃但贡献较少的用户。
  • 边缘用户、潜在用户和沉默用户则是较难发掘的调研对象

业务足够成熟的时候,他们会成为非常重要的增长点,具体的划分方法可以根据业务类型和产品需求来定。

2. 梳理调研维度

在确定目标用户后就要关注调研的维度了。销售和产品往往也有自己用户画像,我们可以有所借鉴,但它和设计师所追求的并不完全一致。

设计师的用户画像可以分以下几个维度。

  • 统计维度:性别、年龄、地域、职业、家庭成员、家庭收入等
  • 操作维度:使用时间、活跃时长、使用频率、使用机型等
  • 认知维度:使用动机、自我认知、生活习惯、产品预期等
  • 消费维度:价格敏感、品牌忠诚、消费周期、代替产品、了解途径等

不同的业务类型,用户调研的侧重会有不同。

例如企业级产品往往与使用者消费习惯无关,但和认知能力关系较大,使用者与付费者也分离。而 K12 类产品的消费周期、使用习惯与电商类也有很大区别。

没有用研团队,如何快速展开用户调研?

△ 用户画像维度划分

结语

只有充分的前期准备,才能使我们顺利的展开深入调研。系统的调研方法笔者将在后续文章中阐述,在这段时间,设计师们赶紧挥舞起勤劳的小手吧,期待下次我们相会。

文章来源:站酷  作者:58UXD

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

如何设计B端地图?收下这份超详细总结!

雪涛

B 端的一些业务场景中常会使用地图元素来展示信息,但是 B 端的页面情况较为复杂多变,与 C 端的百度地图等使用场景以及业务具有一定的差异性。在工作中,我们对于地图页面的布局、交互统一性上的研究还是较少,所以我进行了业务场景下的列表与地图的关系的设计沉淀。

常规地图样式

地图作为一种将地理信息以二维的手段展示的图像。日常纸质地图常常会分为两个模块:地图信息、列表信息。对于现 web 端的产品,地图也保留两者的信息区域并进行不同的布局排布,如百度地图等。针对 web 端的产品,因为有交互形式的出现,所以在地图上会存在更多的信息展示。

地图信息:

  • 地理信息: 以可视化手段、数理的方式将地理信息处理后的信息。
  • 打点地址:打点在地图上的位置分布,其可看作一个基于地理信息的可视化方式。
  • 在图上显示点位的信息。

列表信息:

  • 打点列表主要信息:运用列表的形式展示打点的初步信息。
  • 打点的详情信息:针对打点有再次下钻的能力,来显示单个打点的详情信息。

如何设计B端地图?收下这份超详细总结!

现业务中常见地图设计

针对现在工作、学习过程中遇到过的具有地图元素的业务,我进行了整理并总结出了一些不同场景下存在情况以及现业务阶段存在的问题。

首先我总结了列表的信息与地图信息的关系,一共为三种不同的情况。

  • 一对一:列表与点位一对一的映射
  • 点位内容范围大于列表内容
  • 列表内容范围大于点位内容

如何设计B端地图?收下这份超详细总结!

随后,我针对打点详情信息的复杂度进行了三种程度的区分:简单;复杂;极复杂(较少)

如何设计B端地图?收下这份超详细总结!

最后,我走查线上业务版本发现了一些现地图元素的一些问题。

1. 排版不统一

针对地图的两种布局,使用较为随意,并没有规定其合适的场景使用不同的排版形式。

如何设计B端地图?收下这份超详细总结!

2. 功能入口的交互不统一

针对于地图上的列表,常有功能有定位、查看详情,以及一些特殊场景下的特殊功能入口。然而,这些功能其入口常常不统一,点击列表,有时承载的是查看详情,有时是地图定位、甚者点击卡片不承载任何功能入口。

如何设计B端地图?收下这份超详细总结!

3. 地图打点与列表的对应混乱

有时地图上会存在多个列表的情况下,从而导致列表信息与地图上打点信息对应的混乱,这样会让用户感到信息的不明确。

如何设计B端地图?收下这份超详细总结!

根据以上存在的问题以及情况,我们总结了两点设计原则,针对地图模块进行了修改与推进。

  • 清晰简洁:保证整体页面层级的清晰;地图信息的简洁,确保地图信息最大限度的展示。
  • 对应明确:明确点位信息与列表信息的对应关系。

如何设计B端地图?收下这份超详细总结!

地图中排版以及交互逻辑

地图中常包含了四类元素:列表:主要信息、地图、地图打点、打点的详情信息。

针对以上问题,我们从三个点进行了整理分析:列表的交互形式、地图与列表的整体布局、地图打点的详情信息。

如何设计B端地图?收下这份超详细总结!

列表交互:针对地图列表,点击列表的主要交互操作分为三种

  • 地图定位
  • 查看详情
  • 定位+详情

如何设计B端地图?收下这份超详细总结!

地图布局:为了清晰整体的地图层级,我们将列表与地图分为了两种不同的形式

  • 以地图为底的列表浮层结构
  • 列表与地图的左右结构

并且,根据整体的布局结构,我们将这两种布局形式中包含的隐形的逻辑从而进行了区分,将地图与列表进行了主从关系的分配。针对于第一种形式,地图为底,列表作为具有阴影的第二层结构,其包含了隐形的地图为主、列表为从的逻辑形式;

而针对列表与地图的左右排布结构而言,因为两者处于同其级别的元素,更具左右、上下的阅读习惯,其包含了列表为主、地图为从的逻辑形式。

如何设计B端地图?收下这份超详细总结!

如何设计B端地图?收下这份超详细总结!

而后,根据整体布局的逻辑形式,我们将上文总结的三种不同业务场景进行了分配,并提出了使用建议。

针对于地图(主)/列表(从)的布局情况:

  • 使用场景:适用于地图点位内容范围大于列表内容。
  • 列表交互:推荐点击单个列表首要交互为定位功能。

针对列表(主)/地图(从)的布局情况:

  • 使用场景:适用于列表内容范围大于地图点位内容。
  • 列表交互:推荐点击单个列表首要交互为 详情功能。

打点的详情信息:上文我们根据打点的详情信息分成了三类:

  • 简单
  • 复杂
  • 极复杂

针对这三种情况,我们提出了三种情况下使用的交互形式。

对于简单的信息来说,可以推荐使用气泡弹窗的形式;针对复杂的信息展示尝试用右侧抽屉的形式以及替换当前列表;针对极复杂的场景如需要展示画布或者列表的话可以考虑底部抽屉的展示形式。

如何设计B端地图?收下这份超详细总结!

针对气泡弹窗以及右侧抽屉,我们也提出简单的使用建议。

气泡弹窗:

  • 用于信息复杂度较低的场景,以简洁地图信息,保证完善展示。
  • 不应该在小气泡中承载过多的信息,以滚动、切换等呈现。

如何设计B端地图?收下这份超详细总结!

右侧抽屉:

  • 用于信息复杂度较高的场景。
  • 建议在 列表(主)/地图(从)的布局中使用
  • 不建议在地图(主)/列表(从)的布局中使用:此布局下需要保证图中仅有一个与地图所对应的列表(利用 icon 区分等形式),并且此布局下地图点位数据会较多,若两个层级的点位同时显示会造成干扰。
  • 若需要进行对于详情信息的编辑,建议使用蒙层;若需要使用地图,建议隐藏主列表,以保证复杂表单的输入过程保持专注。

如何设计B端地图?收下这份超详细总结!

小结

最后,根据上述总结的内容,我绘制了一张表格简单的流程图供大家快速的参考。以上结论,仅仅是一个初步的总结,对于更加的细节的点还需要继续进行研究迭代,例如简单于复杂的界限等。

如何设计B端地图?收下这份超详细总结!

文章来源:优设  作者:土拨鼠

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


如何撰写高效的交互说明?

分享达人

定义:

交互说明是针对原型图内容元素的补充解释文字(包含交互逻辑描述、反馈状态描述等) 

交互设计说明书由交互设计师完成编辑、修订、发布的 
主要阅读对象:产品人员、设计人员、研发人员、测试人员等,他们都是交互设计文档的使用主角。 




不同角色的关注点:

产品经理
主要关注:交互逻辑、功能架构、交互事件、界面页面流转与内容布局等。这里的产品经理代表产品经理及以上管理层。 
注意要点: 为项目梳理清楚逻辑关系,文档按照逻辑关系和功能架构分支等设置目录讲清楚项目、功能、组件、页面流转关系。

UI设计师
主要关注:说明文档的具体页面数量,因为这决定 UI 设计师出多少效果图。另外,要看你的原型设计给 UI 设计师留了多少发挥空间,不要过于高保真。以及页面元素是否统一规范便于提炼出典型页面和设计规范。 
注意要点: 清晰合理的页面功能布局,注意交互组件复用,页面不同状态描述清晰。

研发人员
主要关注:非常关心细节实现,关心有多 少个功能、多少个功能新特性、多少个页面元素组件、多少个交互动效等, 但他不关心方案里一个输入框里是用彩色还是黑白,因为他是具体功能的实现者。 
注意要点: 明确表示出关于功能设计、页面逻辑、组件交互等信息的细节,例如:一个页面刷新,要分为触发刷新事件、刷新加载中、刷新成功提示、刷新失败提示。其中失败提示又要分多种情况:网络不佳、程序异常等。如果你没有提出明确需求,责任就会在需求方,而不是研发部门。

测试人员
主要关注:测试是依靠需求说明书和交互设计说明书,进行测试用例与测试脚本的编写,在交互设计说明文档里需要说明白每一个功能的交互动作与事件,测试是抓细节的,所以需要配一些说明性文字解释交互设计的思路与实现路径,这样测试人员就可根据设计思路设计出测试用例。当然,测试用例分多种类型,这里指的是功能测试与逻辑测试,一些性能测试等需要依靠程序使用的软件、数据库等技术性的接口文档来定。 
注意要点: 功能点、业务逻辑、界面元素、交互过程分解步骤。

上面解释了各角色使用交互设计说明文档的场景及他们期待的真实需求,我们需要清楚地了解这些内容,才能有针对性地撰写交互设计说明。 
在交互设计过程中,上述四个角色会不断有所交集。所以,一旦编辑文档,就需要对这几个角色有针对性地解释和阅读优化。 




清晰准确的交互说明,可以起到哪些作用:

1.减少交互设计师与产品上下游人员的沟通成本 
2.提升协作效率 
3.避免项目返工延期 




交互说明撰写准则:

只写最重要的: 

只针对有逻辑规则、异常状态、特殊交互、分支流程、关键节点等进行说明。 
对于一些常识性、无异常点的地方不用堆积文字描述... 
交互说明毕竟是要给人看的,堆积的文字谁看得下去??只会带来额外的阅读压力和极高的理解成本,交互设计师修改起来也麻烦。 


按模块来展示说明: 

01.设计内容组件:对于重复性强、出现频率高的内容,设置一个模板内容及说明即可。 
对于重复出现的地方,直接代替过去就行,可大幅度减少交互设计师的工作量,开发也方便理解。 

02.分页面/位置来展示:当整体交互原型页面较多时,不要全都铺在同一个页面进行展示说明,会显得页面臃肿、浏览费力。可尝试:单独展示某个模块、分支流程、场景等下的交互稿。小而聚集,内容更精简、理解更方便。 

03.若各模块/分支流程/场景中的交互稿存在一定的关联性,可以先做一张总体性的「概览图」,再去单独展示。让开发知道整体方案之间的关系、又能了解各个细分方案里的交互说明。 


复杂说明单独展示: 

交互稿里总会有一些比较复杂、难以文字来说明的想法,像是一些动效、状态等。 
对于这一些比较复杂的说明,可抽离出来进行对比、详细描述,针对局部进行状态效果描述,不必重复复制全量页面。 
像一些按钮或功能存在多种状态时,也可用“表格/列表”的方式进行展示。 


交互说明的排版布局要有助于阅读:

针对不同体量及复杂度的项目,交互说明一定存在多种排版布局方式。但要注意以下几点: 
01.就近原则:交互说明尽量靠近所描述的原型图(或具体功能点)采用数字标号对应描述。特殊情况下交互说明离页面数字标注点较远时,可用虚线连接引导阅读动线。 

02.纵向展示:同页面不同状态/模块及交互说明尽量纵向延伸展示,这样更便于鼠标滚动查看。不要横向平铺太长。 

03.减少重复:对于相同的页面框架/功能菜单仅部分模块/状态不同,可画一张全要素主页面示意,其余针对不同模块/状态拆解后,单独对比展示,并补充交互说明。突出差异点,减少重复性元素的干扰。 

04.主次分明:交互说明样式整体需要区别于原型图页面元素,可一眼区分。同时,对于交互说明也需要区分主要解释和次要描述,让不同查看者抓住重点。 

不同的排版布局方式各有利弊,所以具体采用哪种布局方式要根据所做项目的情况,以及开发人员的阅读习惯而定。 


交互说明组件化: 

类似于设计的控件库,我们在项目中写交互说明写多了就会发现,既然元素可以调用控件库快捷使用,那么该元素的交互说明也可以归类入库,在需要的时候直接拿出来根据具体情况调整使用。这样做的目的:使用时快捷调用,修改时快捷修改。 


有更改及时告知: 

若交互原型做了调整(包含交互说明),一定要告知团队成员!!并写明修改位置(在哪个页面)。 
否则产品、前端、后台、测试等同事的相关想法、工作会停留在上个交互稿里。不要因为信息没对齐而造成了不良影响。就算改了一处小东西,也尽量和同步一下。 




交互说明的三种样式:

1.同一页面内不同模块描述

当同一页面内存在多种状态时,可画一张全要素主页面示意,其余针对不同模块/状态拆解后,单独对比展示并补充交互说明 



2.页面功能点逻辑规则描述
对于页面中的元素和功能点描述可采用数字标号对应的形式,若面功能点较多且存在关联时,可分组标号做统一说明 




3.页面内细节简短标注描述
用于描述页面内功能点及元素的简短说明(20个字内)大段说明文字不建议用此方式(易干扰页面)… 

文章来源:站酷  作者:体验为王UX

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

「玻璃拟物化」你知多少?

分享达人

去年大家看到更多的设计和文章都在围绕“新拟物化”展开行动,随着各种硬件的提升,代码的优化,更多的风格和效果一一出现在我们的生活中,而今天呢,我们一起探索一下生活中最常见的,你可能没有注意到的设计风格——“玻璃拟物化”风格,英文“Glassmorphism”,这也可能会成为新的设计趋势。 




什么是玻璃拟物化呢? 


在生活中的摄影,通过玻璃的层次感,给人以朦胧的美感,那什么是玻璃拟物化呢?



显而易见,Glassmorphism 这个词是 Glass(玻璃)和 Skeumorphism(拟物化)的结合,我们姑且将其称之为「玻璃拟物化设计」。 




油管一管主Malewicz 小哥对于这种风格特征归结为4点:


  • 透明:使用带有模糊磨砂质感背景的透明效果

  • 悬浮:带有明显悬浮感的多个层级

  • 鲜明:使用鲜艳色彩作为强调色并且从半透明层中透出

  • 微妙:使用轻薄微妙的边框来强化物理质感



简单的来说,「玻璃拟物化」在某些方面和「新拟物化」是一脉相承的,但是它有着相对更加具体的视觉隐喻,也就是我们日常接触的「玻璃」。  



玻璃拟物化的优点有哪些? 


1.愉悦感 

玻璃拟物化的应用,让扁平的UI界面不那么单调,打破了人们的视觉疲劳,增添欢快、愉悦的设呈现效果。 

2.层次感 


通过玻璃透明,加周围颜色环境的烘托,页面的层次能更容易的呈现出来。 
















3.呈现语境 

你在哪,从哪里来,玻璃拟物化就很明白的告诉你了。通过透明的玻璃材质,能告诉你所覆盖的层级。



4.微妙高级感 


例如,以往的电商产品设计界面,更多的体现材质或者简约风体现产品本身,但玻璃拟物化会让产品在呈现中更显高级。  







玻璃拟物化的设计风格从哪里来呢?

追根溯源。其实还是要追更到苹果头上。  



苹果的合计将玻璃拟物化的风格运用的惟妙惟肖,无论是mac,iPhone还是iPad,设计风格都保持着相对一致的玻璃拟物化风格。 


重点来了,

玻璃拟物化如何用Sketch来设计一个玻璃面呢? 

首先:我们打开sketch,建立一个画板,随便找张图片作为背景,画一个白色矩形 



接下来:调整矩形的属性,再填充色中设置透明度为50%,边框可以吸取一个30%透明的白色,2px,再添加一个环境色的10%阴影,做出层次感,最后就是调整玻璃模糊的效果了,玻璃拟物的关键就在于sketch自带的背景模糊功能,我们常常以为这里只有一个高斯模糊,但却忽略隐藏在里面的其他模糊效果。设置背景模糊值为10%,不用太大,太大的话模糊效果就没有那么真实了,具体调整还是要看效果。我们看效果: 



单层的效果不是很明显,我们复制两个调好的玻璃效果,调整他们的透明度,底部的透明度为70%、中间的为50%,最上层的为30%,看效果:


在界面设计中,就可以通过不同层级,调整对应的参数,达到更好的层级效果。 


那深色模式怎么办呢?


很简单,我们复制这三个矩形,填充色设为黑色,可以不是纯黑色,根据设计规范来定,看效果:  



在图标中怎么用玻璃拟物化设计呢?


玻璃是属于透明物体,所以我们就了解到,通过玻璃看物体,层次感就出来了。 
所以图标这这里设计的关键就在于 玻璃面和层次感,下面我们来看几个图标设计的案例 






看得出来,玻璃拟物化的设计很出效果。 
下面根据我说的我们来分析如何运用玻璃拟物化设计图标 



我们以这个照片的图标为例来拆解分析,通过运用刚才绘制的玻璃面的方法,与图标色块组合起来,在组合的时候,调整好层级,一个轻巧且富有玻璃质感的图标就绘制出来了,很简单、很容易上手对不对?一起来快来试试吧 



注意的细节:


1.在纯白色背景中,一定要给玻璃面添加底部色块的颜色,不然就不会出现看不见玻璃层的尴尬画面; 
2.背景模糊值也是需要根据具体的需要来调整。  



玻璃拟物化在界面中的应用越来越多,所以大家也要根据自己的业务有选择性尝试的去使用,不要盲目的跟随设计趋势设计而设计。  


就到这里儿吧,大家有空多去收藏一些类似的设计,多去吸取灵感,设计出更好用好看的产品!  


最后,让我们再来总结一下

一玻璃拟物化的特点:


  • 透明:使用带有模糊磨砂质感背景的透明效果

  • 悬浮:带有明显悬浮感的多个层级

  • 鲜明:使用鲜艳色彩作为强调色并且从半透明层中透出

  • 微妙:使用轻薄微妙的边框来强化物理质感


玻璃拟物化的优点有哪些?

JavaScript操作符in:由一个问题引发的探究

前端达人

事情是这样的:大家都知道“内存泄露”这回事吧。它有几个常见的场景:

  1. 闭包使用不当引起内存泄漏
  2. (未声明的)全局变量
  3. 分离的DOM节点
  4. (随意的)控制台的打印
  5. 遗忘的定时器
  6. 循环引用

内存泄漏需要重视,它是如此严重甚至会导致页面卡顿,影响用户体验!

其中第 3 点引起了我的注意 —— 我当然清楚地知道它说的是比如:“假设你手动移除了某个dom节点,本应释放该dom节点所占用的内存,但却因为疏忽导致某处代码仍对该被移除节点有引用,最终导致该节点所占内存无法被释放”的情况

<div id="root"> <div class="child">我是子元素</div> <button>移除</button> </div> <script> let btn = document.querySelector('button') let child = document.querySelector('.child') let root = document.querySelector('#root') btn.addEventListener('click', function() { root.removeChild(child) }) </script> 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

该代码所做的操作就是点击按钮后移除.child的节点,虽然点击后,该节点确实从dom被移除了,但全局变量child仍对该节点有引用,所以导致该节点的内存一直无法被释放。

解决办法:我们可以将对.child节点的引用移动到click事件的回调函数中,那么当移除节点并退出回调函数的执行上文后就会自动清除对该节点的引用,自然也就不会存在内存泄漏的情况了。(这实际上是在事件中实时检测该节点是否存在,如果不存在则浏览器必不会触发remove函数的执行)

<div id="root"> <div class="child">我是子元素</div> <button>移除</button> </div> <script> let btn = document.querySelector('button') btn.addEventListener('click', function() { let child = document.querySelector('.child') let root = document.querySelector('#root') root.removeChild(child) }) </script> 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

这段代码很完美么?不。因为它在每次事件触发后都创建了对child和root节点的引用。消耗了内存(你完全可以想象一些人会狂点按钮的情况…)。
其实还有一种办法:我们在click中去判断当前root节点中是否还存在child子节点,如果存在,则执行remove函数,否则什么也不做!

这就引发了标题中所说的行为。

怎么判断?
遍历?不,太过麻烦!
不知怎的,我突然想到了 for...in 中的 in 操作符,它可以基于原型链遍历对象!

我们来还原一下当时的场景:打开GitHub,随便找一个父节点,并获取它:
mygithub
图中画红框的就是我们要取的父元素,橘红色框的就是要判断是否存在的子元素。

let parent=document.querySelector('.position-relative'); let child=document.querySelector('.progress-pjax-loader'); 
  • 1
  • 2

这里注意,因为获取到的是DOM节点(类数组对象),所以我们在操作前一定要先处理一下:
object

let p_child=[...parent.children]; 
  • 1

array
然后

console.log(child in p_child); 
  • 1

not
!!!
为什么呢?(此时笔者还没有意识到事情的严重性)
我想,是不是哪里出了问题,用es6的includes API验证一下:

console.log(p_child.includes(child)); 
  • 1

yes
没错啊!
再用一般的数组验证一下:
Verification
???
此时,笔者才想起到MDN上查阅一番:
mdn
进而我发现:in操作符单独使用时它检测的是左侧的值(作为索引)对应的值是否在右侧的对象内部(属性 & 原型上)

回到上面的代码中,我们发现:
vertification_2
这验证了我们的结论。
很显然,“子元素”并不等同于“存在于原型链上” —— 这又引出了一个知识点:attribute和property的区别

所以经过一番“折腾”,源代码还是应该直接这样写:

<div id="root"> <div class="child">我是子元素</div> <button>移除</button> </div> <script> let btn = document.querySelector('button') let child = document.querySelector('.child') let root = document.querySelector('#root') let r_child = [...root.children] btn.addEventListener('click', function() { if(r_child.includes(child)){ // 或者你这里直接判断child是否为null也可以...吧 root.removeChild(child) } }) </script> 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17



















转自:csdn论坛   作者:恪愚


蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服



JavaScript逐点突破系列之this是什么?了解完这7点很多疑惑都解决

前端达人

前言

本章将专门介绍与执行上下文创建阶段直接相关的最后一个细节——this是什么?以及它的指向到底是什么。

了解this

也许你在其他面向对象的编程语言曾经看过this,也知道它会指向某个构造器(constructor)所建立的对象。但事实上在JavaScript里面,this所代表的不仅仅是那个被建立的对象。

先来看看ECMAScript 标准规范对this 的定义:

「The this keyword evaluates to the value of the ThisBinding of the current execution context.」
「this 这个关键字代表的值为当前执行上下文的ThisBinding。」

然后再来看看MDN 对this 的定义:

「In most cases, the value of this is determined by how a function is called.」
「在大多数的情况下,this 其值取决于函数的调用方式。」

好,如果上面两行就看得懂的话那么就不用再往下看了,Congratulations!

… 我想应该不会,至少我光看这两行还是不懂。

先来看个例子吧:

var getGender = function() {
    return people1.gender;
};

var people1 = {
    gender: 'female',
    getGender: getGender
};

var people2 = {
    gender: 'male',
    getGender: getGender
};

console.log(people1.getGender());    // female
console.log(people2.getGender());    // female 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

what?怎么people2变性了呢,这不是我想要的结果啊,为什么呢?

因为getGender()返回(return)写死了people1.gender的关系,结果自然是’female’。

那么,如果我们把getGender稍改一下:

var getGender = function() {
    return this.gender;
}; 
  • 1
  • 2
  • 3
  • 4

这个时候,你应该会分别得到femalemale两种结果。

所以回到前面讲的重点,从这个例子可以看出,即便people1people2getGender方法参照的都是同一个getGender function,但由于调用的对象不同,所以执行的结果也会不同

现在我们知道了第一个重点,**this实际上是在函数被调用时发生的绑定,它指向什么完全取决于函数的调用方式。**如何的区分this呢?

this到底是谁

看完上面的例子,还是有点似懂非懂吧?那接下来我们来看看不同的调用方式对 this 值的影响。

情况一:全局对象&调用普通函数

在全局环境中,this 指向全局对象,在浏览器中,它就是 window 对象。下面的示例中,无论是否是在严格模式下,this 都是指向全局对象。

var x = 1

console.log(this.x)               // 1
console.log(this.x === x)         // true
console.log(this === window)      // true 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

如果普通函数是在全局环境中被调用,在非严格模式下,普通函数中 this 也指向全局对象;如果是在严格模式下,this 将会是 undefined。ES5 为了使 JavaScript 运行在更有限制性的环境而添加了严格模式,严格模式为了消除安全隐患,禁止了 this 关键字指向全局对象。

var x = 1

function fn() {
    console.log(this);   // Window 全局对象
    console.log(this.x);  // 1
}

fn(); 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

使用严格模式后:

"use strict"     // 使用严格模式
var x = 1

function fn() {
    console.log(this);   // undefined
    console.log(this.x);  // 报错 "Cannot read property 'x' of undefined",因为此时 this 是 undefined
}

fn(); 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

情况二:作为对象方法的调用

我们知道,在对象里的值如果是原生值(primitive type;例如,字符串、数值、布尔值),我们会把这个新建立的东西称为「属性(property)」;如果对象里面的值是函数(function)的话,我们则会把这个新建立的东西称为「方法(method)」。

如果函数作为对象的一个方法时,并且作为对象的一个方法被调用时,函数中的this指向这个上一级对象

var x = 1
var obj = {
    x: 2,
    fn: function() {
        console.log(this);    
        console.log(this.x);
    }
}

obj.fn()     

// obj.fn()结果打印出;
// Object {x: 2, fn: function}
// 2

var a = obj.fn
a()   

// a()结果打印出:   
// Window 全局对象
// 1 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22

在上面的例子中,直接运行 obj.fn() ,调用该函数的上一级对象是 obj,所以 this 指向 obj,得到 this.x 的值是 2;之后我们将 fn 方法首先赋值给变量 a,a 运行在全局环境中,所以此时 this 指向全局对象Window,得到 this.x 为 1。

我们再来看一个例子,如果函数被多个对象嵌套调用,this 会指向什么。

var x = 1
var obj = {
  x: 2,
  y: {
    x: 3,
    fn: function() {
      console.log(this);   // Object {x: 3, fn: function}
      console.log(this.x);   // 3
    }
  }
}

obj.y.fn(); 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

为什么结果不是 2 呢,因为在这种情况下记住一句话:this 始终会指向直接调用函数的上一级对象,即 y,上面例子实际执行的是下面的代码。

var y = {
  x: 3,
  fn: function() {
    console.log(this);   // Object {x: 3, fn: function}
    console.log(this.x);   // 3
  }
}

var x = 1
var obj = {
  x: 2,
  y: y
}

obj.y.fn(); 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

对象可以嵌套,函数也可以,如果函数嵌套,this 会有变化吗?我们通过下面代码来探讨一下。

var obj = {
    y: function() {
        console.log(this === obj);   // true
        console.log(this);   // Object {y: function}
        fn();

        function fn() {
            console.log(this === obj);   // false
            console.log(this);   // Window 全局对象
        }
    }
}

obj.y(); 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

在函数 y 中,this 指向了调用它的上一级对象 obj,这是没有问题的。但是在嵌套函数 fn 中,this 并不指向 obj。嵌套的函数不会从调用它的函数中继承 this,当嵌套函数作为函数调用时,其 this 值在非严格模式下指向全局对象,在严格模式是 undefined,所以上面例子实际执行的是下面的代码。

function fn() {
    console.log(this === obj);   // false
    console.log(this);   // Window 全局对象
}

var obj = {
    y: function() {
        console.log(this === obj);   // true
        console.log(this);   // Object {y: function}
        fn();
    }
}

obj.y(); 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

情况三:作为构造函数调用

我们可以使用 new 关键字,通过构造函数生成一个实例对象。此时,this 便指向这个新对象

var x = 1;

function Fn() {
   this.x = 2;
    console.log(this);  // Fn {x: 2}
}

var obj = new Fn();   // obj和Fn(..)调用中的this进行绑定
console.log(obj.x)   // 2 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

使用new来调用Fn(..)时,会构造一个新对象并把它(obj)绑定到Fn(..)调用中的this。还有值得一提的是,如果构造函数返回了非引用类型(string,number,boolean,null,undefined),this 仍然指向实例化的新对象。

var x = 1

function Fn() {
  this.x = 2

  return {
    x: 3
  }
}

var a = new Fn()

console.log(a.x)      // 3 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

因为Fn()返回(return)的是一个对象(引用类型),this 会指向这个return的对象。如果return的是一个非引用类型的值呢?

var x = 1

function Fn() {
  this.x = 2

  return 3
}

var a = new Fn()

console.log(a.x)      // 2 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

情况四:call 和 apply 方法调用

如果你想改变 this 的指向,可以使用 call 或 apply 方法。它们的第一个参数都是指定函数运行时其中的this指向。如果第一个参数不传(参数为空)或者传 null 、undefined,默认 this 指向全局对象(非严格模式)或 undefined(严格模式)。

var x = 1;

var obj = {
  x: 2
}

function fn() {
    console.log(this);
    console.log(this.x);
}

fn.call(obj)
// Object {x: 2}
// 2

fn.apply(obj)     
// Object {x: 2}
// 2

fn.call()         
// Window 全局对象
// 1

fn.apply(null)    
// Window 全局对象
// 1

fn.call(undefined)    
// Window 全局对象
// 1 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

使用 call 和 apply 时,如果给 this 传的不是对象,JavaScript 会使用相关构造函数将其转化为对象,比如传 number 类型,会进行new Number()操作,如传 string 类型,会进行new String()操作,如传 boolean 类型,会进行new Boolean()操作。

function fn() {
  console.log(Object.prototype.toString.call(this))
}

fn.call('love')      // [object String]
fn.apply(1)          // [object Number]
fn.call(true)          // [object Boolean] 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

call 和 apply 的区别在于,call 的第二个及后续参数是一个参数列表,apply 的第二个参数是数组。参数列表和参数数组都将作为函数的参数进行执行。

var x = 1

var obj = {
  x: 2
}

function Sum(y, z) {
  console.log(this.x + y + z)
}

Sum.call(obj, 3, 4)       // 9
Sum.apply(obj, [3, 4])    // 9 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

情况五:bind 方法调用

调用 f.bind(someObject) 会创建一个与 f 具有相同函数体和作用域的函数,但是在这个新函数中,新函数的 this 会永久的指向 bind 传入的第一个参数,无论这个函数是如何被调用的。

var x = 1

var obj1 = {
    x: 2
};
var obj2 = {
    x: 3
};

function fn() {
    console.log(this);
    console.log(this.x);
};

var a = fn.bind(obj1);
var b = a.bind(obj2);

fn();
// Window 全局对象
// 1

a();
// Object {x: 2}
// 2

b();
// Object {x: 2}
// 2

a.call(obj2);
// Object {x: 2}
// 2 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33

在上面的例子中,虽然我们尝试给函数 a 重新指定 this 的指向,但是它依旧指向第一次 bind 传入的对象,即使是使用 call 或 apply 方法也不能改变这一事实,即永久的指向 bind 传入的第一次参数。

情况六:箭头函数中this指向

值得一提的是,从ES6 开始新增了箭头函数,先来看看MDN 上对箭头函数的说明

An arrow function expression has a shorter syntax than a function expression and does notbind its ownthis,arguments,super, ornew.target. Arrow functions are always anonymous. These function expressions are best suited for non-method functions, and they cannot be used as constructors.

这里已经清楚了说明了,箭头函数没有自己的this绑定。箭头函数中使用的this,其实是直接包含它的那个函数或函数表达式中的this。在前面情况二中函数嵌套函数的例子中,被嵌套的函数不会继承上层函数的 this,如果使用箭头函数,会发生什么变化呢?

var obj = {
  y: function() {
        console.log(this === obj);   // true
        console.log(this);           // Object {y: function}

      var fn = () => {
          console.log(this === obj);   // true
          console.log(this);           // Object {y: function}
      }
      fn();
  }
}

obj.y() 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

和普通函数不一样,箭头函数中的 this 指向了 obj,这是因为它从上一层的函数中继承了 this,你可以理解为箭头函数修正了 this 的指向。所以箭头函数的this不是调用的时候决定的,而是在定义的时候处在的对象就是它的this

换句话说,箭头函数的this看外层的是否有函数,如果有,外层函数的this就是内部箭头函数的this,如果没有,则this是window

var obj = {
  y: () => {
        console.log(this === obj);   // false
        console.log(this);           // Window 全局对象 

      var fn = () => {
          console.log(this === obj);   // false
          console.log(this);           // Window 全局对象 
      }
      fn();
  }
}

obj.y() 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

上例中,虽然存在两个箭头函数,其实this取决于最外层的箭头函数,由于obj是个对象而非函数,所以this指向为Window全局对象。

同 bind 一样,箭头函数也很“顽固”,我们无法通过 call 和 apply 来改变 this 的指向,即传入的第一个参数被忽略

var x = 1
var obj = {
    x: 2
}

var a = () => {
    console.log(this.x)
    console.log(this)
}

a.call(obj)       
// 1
// Window 全局对象

a.apply(obj)      
// 1
// Window 全局对象 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

上面的文字描述过多可能有点干涩,那么就看以下的这张流程图吧,我觉得这个图总结的很好,图中的流程只针对于单个规则。

小结

本篇文章介绍了 this 指向的几种情况,不同的运行环境和调用方式都会对 this 产生影响。总的来说,函数 this 的指向取决于当前调用该函数的对象,也就是执行时的对象。在这一节中,你需要掌握:

  • this 指向全局对象的情况;
  • 严格模式和非严格模式下 this 的区别;
  • 函数作为对象的方法调用时 this 指向的几种情况;
  • 作为构造函数时 this 的指向,以及是否 return 的区别;
  • 使用 call 和 apply 改变调用函数的对象;
  • bind 创建的函数中 this 的指向;

  • 箭头函数中的 this 指向。
  • 转自:csdn 论坛  作者:蛋黄酥要不要来一口阿

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服

想做SEO但又不知道从何下手的朋友可以看看!

seo达人

在网站上线之前,我们要对网站做出合理的规划,并做出完美的SEO优化计划,并按照这个SEO计划逐步实施,使网站稳定发展,是我们制定SEO规划的重要作用。制定完美的SEO计划,不仅能使你的网站有明确的发展方向,还能提高网站的关键词排名基本情况。那么,我们应该要如何制定一份完美的SEO计划呢?下面,陈老师就给大家详细的讲解一下。




一、分析SEO关键词


网站搭建前期,我们先要分析SEO关键词。我们提议逐一详细列出要做的SEO关键词,然后分析每个SEO关键词,筛选出用户比较搜索的SEO关键词,淘汰比较不受欢迎的SEO关键词。然而,在此建议适当制作无指数词汇。然而,未来可能有一定程度的发展。最后,要了解站点中每个列页面的SEO需求,也就是说,要确定站点中每个列应该做什么,然后将关键词放在该列中以进一步匹配。




1、分析用户搜索的需求


分析用户的搜索需求是最重要和最基本的。应如何分析用户的搜索需求呢?这里我就给大家讲一下吧,我们可以使用百度搜索下拉框,搜索结果在页面显示,相关的搜索结果显示内容分析,当然也可以使用百度索引进行分析。这里我们就不讲百度指数了,主要讲前面三个方法:


我们利用百度下拉框,分析哪些关键词对用户感兴趣,即用户在搜索,百度根据搜索频率从高到低排列,根据搜索结果页面的内容,哪些关键词的排名状况好,结果,这些单词是用户感兴趣还是最后得出了相关检索结果的结论,这是分析用户检索需求的辅助板块,通过分析百度相关检索结果,可以得出检索该关键词的用户对什么样的关键词感兴趣的结论。




2、尽量不要设置过多的关键词


在分析了用户的搜索需求之后,接下来是设置关键词。当我们设置网站主关键词时,如果你的关键词设置索引很高,而你的网站仍然是一个新的站点,那么,建议你不要设置太多的关键词,因为,这更有利于你的网站的高索引关键词排名,如果设置了大量的关键词,会导致关键词匹配度分散,从而影响你的高索引关键词排名,因此,在满意度的关键词是高索引和你的网站是一个新的站点,如果你的网站想得到一个好的排名,最好不要设置太多的关键词。




3、注意关键词的搜索热度


在完成了上面两点之后,接下来就是注意事项了,我们在设置关键词的时候,一定要注意关键词的搜索热度,也就是关键词的指数了,如果,你所选择的关键词搜索热度过高的话,那么,这样的关键词是比较难优化上首页的,因为,这样高指数的关键词一般竞争程度都很大,甚至有的都是投放百度竞价的,所以,我们尽量拓展这类高指数关键词的长尾词,或是选择另外一个同义词了,当然,我们也不能选择一些没有什么搜索热度的词,也就是没有指数的关键词了,因为,这类词既然没有搜索热度,也就是比较没有用户搜索的,并且是相对比较冷门的关键词,如果设置了这样的关键词的话,就会导致你网站没有什么自然用户点击浏览量了,所以,我们在设置关键词的时候,一定要注意分析关键词的整体搜索热度。




4、注意关键词和网站的相关性


在分析关键词的整体搜索热的基础上,关键词和站点的相关性是什么意思呢?所谓的关键词和网站的相关性我们只能理解关键词和网站的相关性,例如:你的网站是SEO等网站,然后,你设置关键词必须与SEO相关的关键词,如SEO优化、SEO技术,不能设置一些与SEO相关的关键词,如:装饰、婚礼等。当然,这里只是给你一个更夸张的例子,在正常情况下,我们不会用这么大的区别词来做关键词,特定的人可以做比较和分析。




二、网站内容和关键词的策略


分析SEO关键字后,下一个重要因素是网站内容和关键词排列。这就需要重视策略。具体而言,可分为以下几点:




1、分析用户搜索行为


首先,我们需要分析用户的搜索行为,我们可以换位思考,当用户进入我们的网站时,用户一般会搜索站内的关键词,浏览什么样的内容,当然,这里是你想确定站点的用户群的前提,然后,针对主要用户群部署关键词,我们可以增加关键词的用户搜索。




2、重视网页三要素TDK的写作


在配置关键字之后,接着重视网页的3要素TDK的写作,其中,在网页的3要素中T(title)是网页的标题是重要的,现在,由于最直接地影响关键字的排名状况,所以网页标题的关键字然后是网页的三个元素中,d(description)网页的描述和k(keywords)网页的关键字。这两个网页的元素同样重要,因为它们有助于提高关键字的匹配度和关键字的顺序。




3、网站内容和关键词的融合


文章内容和关键词必须融合是什么意思呢?也就是说,我们写文章的时候,要把我们应该做的关键词放在文章里。现在让我们来谈谈技巧。我们一般可以在文章里放三个关键词。这是因为文章的字数不同,1500字能够输入3~4个关键词,2000字以上能够输入5~6个关键词是极限的。我们可以分别在文章的首尾给加入一个关键词,然后,在文章的中间加入2-4个关键词,这样就是可以提高关键词的出现频率,也就是适当提高关键词的密度了。




4、给关键词添加锚文本


我们也可以在关键词中添加锚定文本,但在这里需要说明一些注意事项,即在文章中向关键字中添加锚定文本,锚定关键字与其文章的关联性会增强,并且,关键字锚点文本的数量不能超过三个,锚点的关键字必须是自然的,可以在关键字的开头创建锚点文本,锚点文本可以在文章的开头和结尾各添加一个,当然,具体得看你的关键词出现在哪里了。




三、网站内链的合理建设


合理构建网站的站内链接也非常重要,因为在网站站内链接完成后,可以使网站无形化,有利于搜索引擎蜘蛛爬行,并且为了增加文章的包容性,如果网站的站内链接良好,还可以有效地降低用户网站的建设速度。


四、网站全站地图的制作




在合理建设网站内链后,下一步是制作网站地图了。这里主要介绍两种形式的网站地图制作。具体可以往下看!




1、XML格式的站点地图


XML格式的网站地图一般被称为蜘蛛地图,主要用于搜索引擎的蜘蛛爬行。制作这个XML形式的网站地图的好处是加大搜索引擎蜘蛛蠕动的深度,提高网站内文章的收录状况。




2、HTML格式的站点地图


HTML格式的网站地图通常被称为用户地图,主要是向访问我们网站的用户展示,创建这种HTML格式的网站地图的好处在于,用户可以查看我们网站的所有文章内容,提高了网站的用户体验




五、网站外链的合理建设


完成以上所有操作后,接着合理建设网站外部链接,这个也就是我们常说的发外链了,那么,具体应该要怎么做呢?现在让我告诉大家。网站外链接建设的主要目的是引出蜘蛛和流量。当然,这里有注意事项。在我们提出外联的时候,一定要注意外联的文章质量,还要注意发表的外联与第三方外联平台的关联性很强。例如,因为我们的网站是装修的,所以我们发送的外部链接必须在装修类的论坛和公告栏等平台上发表,不能在婚礼等网站上发表。




这里我给你们一个补充说明,当我们做网站外链的建设时,主要的工作是交换链接和到第三方平台发布外链,你们应该知道,链接也是外链的一部分,是外链的最高质量,而且可控性是外链的一种相对强烈的形式,这里讨论一些需要注意的事项的链接的交换。




当我们交换友情链接时,我们必须注意检查其他网站是否受到搜索引擎的惩罚,我们可以用SITE指令来检查,看看对方的网站主页是否在搜索引擎的第一页,如果不是,受到惩罚;检查对方的网站是否有权重,大家都知道我们交换友情链接就是为了是网站与网站之间互相传递权重;


另外,通过检查对方网站的运行速度,如果对方网站的运行速度慢或不稳定,我们也不要和他交换。因为搜索引擎对运行速度慢的网站和不稳定的网站的印象不好,这样的网站对搜索引擎蜘蛛爬行也不利




还有,检查对方网站友情链接交换的数量,如果对方网站友情链接交换的数量过多,我们也不要和他交换。由于对方网站不怎么交换友谊链接,所以我们和他交换的话,对方网站传递的权重也会减少,另外,友谊链接交换的数量过多的话,搜索引擎会考虑作弊行为,也就是优化过度了。




在文章的最后,让我们总结全文的重点。在网站上制定完美的SEO计划很重要。因为完美的SEO计划不仅能为网站提供明确的发展方向,还能提高网站关键词排名。那么,我们应该要怎么才能给网站制定出一份完美的SEO计划呢?




例如:


1、分析SEO关键词,主要的内容包括:分析用户搜索需求、尽量不要设置太多关键词、注意关键词的整体搜索热度、注意关键词与网站的相关度;


2、网站内容和关键词的部署策略,主要的内容包括:分析用户搜索行为、重视“网页三要素TDK”的写作、文章内容和关键词的融合、给关键词添加锚文本;


3、网站“站内链接”的合理建设;


4、网站全站地图的制作,主要的内容包括:XML格式的网站地图的制作、HTML格式的网站地图的制作;


5、网站“外部链接”的合理建设。

文章来源:淘金网  作者:淘小白

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

 

图标设计如何快速过稿?来看看这篇文章的锦囊妙计

周周


图标设计如何快速过稿?来看腾讯设计师的私藏方法

最近遇到一个同学,说做了很多稿图标的方案最终还是没有确定下来,但眼看着产品马上就要上线了,该怎么办。经过一轮沟通,发现他陷入几个新手设计师在画图标比较容易犯的问题:

  • 面对产品提出的疑问,不知道如何拆解,仅停留在表面的理解,“美”or“丑”
  • 思考的方案呈现不够系统,导致多次修改,也未被采纳
  • 对于图标多方案的设计输出缺乏方法,漫无目的的设计方案
  • 思考不够发散,存在局限性,不敢大胆突破
  • 过度纠结,都在做方案,做出了但方案都不过关

图标设计如何快速过稿?来看腾讯设计师的私藏方法

从以上这几个问题,我们进行深入思考,会发现其实这些只是表面上的问题,实际上是在说什么呢?

  • 美 or 丑:实际上是我们对于图形或图标的设计趋势是否了解,我们设计的图标设计是否符合现在的趋势,我们阐述方案的时候是否足够的自信这个是现在流行的风格?
  • 多次修改:这个实际上是反馈我们呈现方案的功力或者能力,我们做的设计是否足够系统性,多套方案中是否有命中对方想要的点
  • 漫无目的的设计:基于上述第 2 点的框架下,我们在输出图标的时候设计呈现的维度是否足够全面,从表意到图形美观度上是否有足够多的思考
  • 局限性:因为日常看得少,所以在实际案例设计的时候也会受到局限,因此养成日常积累的习惯比临时思考会更好
  • 过度纠结:这种表现是表明你已经陷入到了设计本身,而缺乏跳出来看看更多参考的勇气了,这时应该先停住,找找参考,帮助打开思考壁垒

图标设计如何快速过稿?来看腾讯设计师的私藏方法

基于以上这个案例,分享下我在日常设计中常用的一些方法,希望可以帮助遇到相同问题的小伙伴们进行一些答疑,从而帮助你们打破壁垒,高效成长。

下面发改分成 3 个部分来进行阐述:思考维度的锻炼;图形的设计方法;系统化方案呈现

思考维度的锻炼

当我们要设计一个图标的时候最容易入手的就是图标的表意,从表意延伸到图形的设计,然后再加以不同的设计手法(线、面、线面等等)。

1. 图标的表意

图标的表意方式,大概可以拆分为以下几种:具有普识性的图标、可进行表意延伸的图标、通过组合的图标、抽象的需要关联的图标。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

2. 普识型图标

即我们在现实生活中常见且具有常识性性的图标,例如:删除、添加、放大、搜索、笔记本、手机、眼睛、礼物等等。这类的图标重点在于形体的打磨上需要多花一些时间,从不同的角度进行尝试,比如以删除为例子,同样的造型但可以有不同的设计表现。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

3. 表意延伸的图标

即一个事物可以被延伸为一个或者多个图形表现的图标,例如:点赞、浏览、设置、收藏、评论、事件等等。例如点赞-延伸为你很棒用大拇指来表达,游戏延伸为游戏手柄、设置-延伸为机械操作用齿轮来表达,评论延伸为对话使用对话框来表达,浏览-延伸为用眼睛的图标表达。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

除此之外延伸表意的图标可以有多种设计方式,例如以事件为案例。

  • 方案 A:事件具有时间性,所以可以考虑用日历来置换;
  • 方案 B:事件具有告知的行为,所以考虑用喇叭来突出这个行为;
  • 方案 C:事件具有档案的意味,所以我们可以用表单的图形来做沿用。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

4. 组合型图标

主要是指该类图标的表意需要通过 2 个以上的图形进行组合才能更加准确进行表现,例如:群、群聊、好友、添加联系人、情侣、转账、红包。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

5. 创造类图标

特指认识中没有,因为产品需要被二次创造出来的图标,一般在一些新生业务中会常出现,这类图标初期往往需要伴随文字一同出现。例如:微信的朋友圈、视频号、小程序、手机系统的 Wi-Fi、蓝牙等类型等图标。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

图标的表现方法

常规的图标表现方法(线形、线面、面形、插图、叠色等等)我们基本都了解,但作为设计师更应该知道潮流趋势,清楚现在流行什么类型的设计,这样才能让你作出更加出彩的设计。

这里分享几种目前最流行的图标设计类型:

1. 磨砂质感图标

磨砂质感图标作为 2020 年底最流行的图标,已经在不少 APP 中看得了相关的设计,从设计方法上并不难,重点还是在于是否有需要和应用场景。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

2. 插图+磨砂质感

图标使用小插图的方式进行绘制,然后再结合高斯模糊的视觉表现手法,整体让图标更具有层次感和通透感。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

3. 3D 质感图标

3D 作为这 2 年最流行的设计趋势,自然也牵动着设计师的心。但 3D 的打磨相对会比较耗费时间,不过仍然是值得一试的设计方式之一,目前在 APP 的设计中比较少见到应用,或许会成为 2021 的趋势之一。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

4. 3D 磨砂质感图标

基于 3D 与毛玻璃图标的结合,整体的表现结合了这 2 种风格的特点,既保留了毛玻璃图标的通透,同时也具有 3D 的空间感。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

5. 流光溢彩的图标

算是属于渐变类型的一种,但颜色和细节的跨度相比常规的渐变图标更加丰富,整体让人感觉具有流光的效果,更加具有未来感。不过从目前来说,更适合作为独立的应用 APP 设计,作为常规的图标设计需要一定的接受度。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

图标的设计方法

想要了解设计的方法之前,我们得了解有哪些类型的图标,具体大家可以查看我之前撰写过的文章,里面有详细的分析了图标的设计类型。除此之外,这里还可以分享下我日常中设计图标使用的方法。

这个专题也有超详细的分类和教程 → https://www.uisdc.com/zt/icon-drawing-guide

1. 表意+基础形

基础形体使用普适性较高的图标造型,在图标的亮点或者点缀处通过表意关联进行创意设计,从而让图标获得新的感受,但又具有较高的识别性。案例:例如我们以日历图标为案例,可以比较直观的使用日历的普识图形,然后通过日期的方式来进行强调赋予图标生命力,然后再叠加上颜色和质感,并且增加一点小趣味的折角设计。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

2. 关联延展

基于实际场景的认识来进行图形关联延展,并且进行一定的美感升级及图形的优化,延展出最终的图标设计,这种方法可以大大提高大家对于图标的识别度。案例:设计一个快速聊天表意的图标,聊天我们常规使用气泡,快速我们可以关联为闪电,然后把气泡和闪电进行结合。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

3. 组合升级创意

利用一些正负形的创意方法,使用 A、B 图形的进行有机融合或剪切,使其获得新的图标造型,让整体的图标感受更具有创意点。案例:例如我们尝试画一个具有宇宙感受的游戏图标,可以通过手柄和星球的有机结合让整体的图标带有游戏和星球的意思,整体提升了表达的创意。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

系统化方案呈现

方案的呈现属于设计的一部分,虽然不能起到决定性的作用,但好的呈现效果往往可以帮助我们得到更好的印象分,这里分享一下我在设计过程中尝试的一些方法。方案的大小或者输出的类型也决定着我们呈现方案的类型,下面根据不同的类型分享不同的呈现案例。

1. 纵横对比法

适用于需要大量尝试的时候,以穷举输出为典型案例,我们可以用最基础的图形为中心点,结合图形的表意和图形风格进行纵横的发散性扩展,例如横向为表意、纵向为图形风格,中间部分属于交叉部分。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

案例模版

图标设计如何快速过稿?来看腾讯设计师的私藏方法

2. 单个图标创意思考

对于一些标志类或重要的图标,我们需要阐述我们的设计想法或者来源,这种呈现的方式就可以很直观且简洁的表现我们的思考。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

案例模版

图标设计如何快速过稿?来看腾讯设计师的私藏方法

3. 整套输出

对于一整套的图标,我们需要在案例上呈现图形的设计规则,包括但不限于有:圆角、角度、组合规范、斜度等等。除了呈现图形之外,请补充上颜色的应用规则、颜色的表意等等。

图标设计如何快速过稿?来看腾讯设计师的私藏方法

案例模版

图标设计如何快速过稿?来看腾讯设计师的私藏方法

总结

图标设计虽然是一个小内容但却很重要,反映着着整个页面的精致度,在 UI 界面来说是除界面排版之外最重要的一环,因此是很值得我们去研究的设计之一,建议在日常工作中多练习多看。



文章来源:优设网     作者:ID设计站


蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

场景化设计

雪涛

前言

——

随着科技的进步和互联网的发展,过去机械的单向交互方式逐渐被打破,用户使用移动端的场景越来越丰富,设计师也开始需要通过主动的观察用户所处的不同场景,感受用户情感,预判用户意图,来为用户提供更智能更便捷更贴心更高效的服务,场景化设计已经融入互联网设计的方方面面,下面的文章当中,我将从三个方向去阐述和列举场景化设计。



随着移动端的不断发展,从固定电话到移动电话,移动端的设计渐渐的融入在用户的身边,深度的跟随着用户,陪伴着用户,慢慢的,开始观察用户,感受用户,在这个过程背后当中,场景设计逐渐产生,设计师通过针对用户所在的实际场景来设计,建立用户与场景之间的联系,给用户带来更贴心,更高效的体验设计。



1-1  基于不同用户的场景化设计

——————————————


腾讯视频 - 播放器护眼模式

如今各大产品都在上线了“青少年模式”,越来越多的产品关注到了成人与儿童这两个不同的用户群体,腾讯视频在青少年模式中推出的播放器护眼模式,通过摄像头来获取用户当前距离手机屏幕的距离,当用户离屏幕太近会有提醒并停止播放,当用户位置在正常距离以后,提醒消失。帮助青少年养成合理观看手机,爱护视力的好习惯。


滴滴打车 - 关怀模式

滴滴打车新增了“关怀模式”,在关怀模式下,整体的页面字号放大,在功能上,更极简的打车模式,将复杂的任务拆分为拆分为目标清晰的子任务,并提供清晰的反馈,来方便用户的使用,关怀模式更有利于老年用户以及视障用户使用产品。

产品在体验上的提升不应该仅仅是针对主要群体,跟多的是考虑到特殊群里的体验,以上两个案例,根据不同的年龄人群“青少年和老年”,适应了不同的产品体验模式,让更多的用户群体都能够得到更好的产品体验。


腾讯地图 - 左手操作功能

当用户在腾讯地图设置中开启左手操作功能,首页地图上的侧方操作控件会移动到屏幕的左侧,方便左手用户点击和操作,人性化的设计容纳了拥有不同使用习惯的用户。


高德地图 - 视觉障碍模式

在地图软件当中,我们通常都会用红色表示路段拥堵,绿色表示通畅,在色盲色弱人群当中,红绿色盲也是比较常见的色盲类型,所以在高德地图中,为色盲色弱用户做了专属的路况配色,贴心的考虑到了特殊人群的体验。


优酷视频 - 色弱模式

优酷视频在更多模式选择中,为用户提供了“色弱模式”,并有不同色弱人群的细分“红色弱”“绿色弱”“蓝黄色弱”


饿了么 - 无障碍色盘

在饿了么送货骑手中,约8%受色盲色弱的困扰(全国男性群体中红绿色盲色弱占比达8%-9%,饿了么骑手男性占比90%),为此饿了么设计团队在2019年对app的进行了重新设计,包括使用WCAG无障碍色彩对比度,以及无障碍色盘,以及调整字阶,使用辅助图形等设计手段来解决部分骑手在送货途中使用APP的痛点问题。



1-2  基于不同时间的场景化设计

——————————————


美团/美团外卖 - 不同时间段展示不同推荐

外卖行业本身就具有一定的时间属性细分,用户早中晚点餐上肯定会有不同的诉求,美团外卖在不同的时间顺应用户的不同诉求来推荐不同的内容,帮助用户挑选在该时间段内的用餐。

美团在一些周末和特殊节日上,用户在不同时间的诉求不同的,相关推荐也会有所不同。


QQ音乐 - 不同时间的个性化push推荐

QQ音乐会根据不同的时间,给用户推荐不同的个性化push通知,早上是“每天起床气一句”“最气不过起床气” 冬日是“冬夜需要”。结合用户当前时间段下推荐相关的push,不仅增加了用户的点击欲望,也拉近了和用户的距离,让用户时而暖心,时而感到有趣,这么可爱的push通知,也是辛苦QQ音乐的运营小编了~



1-3  基于不同地点的场景化设计

——————————————


iOS - 勿扰模式新增位置属性

在iOS12系统当中,新增了地点勿扰模式,长按勿扰模式的按钮,可以选择“直至我离开此位置”,用户在看电影,会议或一些特定的地点可以灵活的使用该功能。


大众点评 - 首页根据地理位置个性化推荐

在使用大众点评时,当我的地理位置在我的常驻地北京时和将地理位置切换到“重庆”时,首页展示的信息和内容框架都发生了变化,产品根据我的地理位置推断出我现在搜索的目标地不是我的常驻地,预判到我可能存在即将出游到当前定位的城市,会直接给我推荐一些攻略,和一些“怎么玩”“”订住宿“”游景点“的旅游攻略向内容。



1-4  基于不同环境的场景化设计

——————————————


iPhone -  接听功能

iPhone在用户接电话的场景下,根据用户所处环境不同,适配了不同的方案。不同的当iPhone处于息屏状态接电话时滑动接听,防止误触;当iPhone在使用时接听电话为按键接听。减少用户操作成本。


支付宝 - 收款码功能键盘

在支付宝的收款码扫一扫功能中,用户向他人展示收款码时,手机向下倾斜后,扫码的提示文字和用户的头像会发生旋转,其他功能会相应弱化或者直接消失,以便方便付款人阅读,充分考虑到了现实中的操作环境,保证了双方的使用体验。


支付宝等金融类产品 - 后台运行下模糊处理

支付宝等金融类的产品,在用户开启后台后,会对页面进行高斯模糊处理,避免了后台场景下用户无意中泄漏自己的信息,也防止了被偷窥。(支付宝在页面底端还添加了温馨提示:支付宝全力保护你的信息安全)



1-5  基于不同事件的场景化设计

——————————————


支付宝 - 停车缴费功能

在输入车牌省份时,会直接弹出各省/直辖市的缩写专用键盘,并且可以直接进行大写字母与城市简称的切换,降低了用户的输入成本,提高了整个功能的使用效率。


百度键盘 - 横屏游戏模式

百度键盘在游戏模式下,会接入游戏快捷回复语并自动开启和谐模式,增加趣味性的同时方便了我们在游戏进程中的快捷输入,将九宫格按键进行等比缩小展示,方便用户点击。


iPad OS键盘 - 浮动式键盘/速滑输入

Pad OS键盘在使用中,可双指捏合可以快速缩小键盘,然后将它移到合适的位置,即能单手打字,又能给你的app留出更多的空间,并且增加了快速输入的功能,只需要在键盘之前轻扫,即可打字。



情景预判的交互设计是建立在整个产品的框架上和对用户深刻理解上的细节迭代。预判设计主要有两类目的:一是在用户初次体验某种功能时引导用户,避免用户陷入困惑;二是提前判断用户行为,缩短行为路径。新功能引导更倾向于产品功能本身的逻辑和价值,这次我们主要主要讲第二点,提前判断用户行为。



预判设计强调主动性和智能性,是决定产品是否体贴、聪明的重要因素,是走向人工智能的基础,对微交互中的预判设计进行分类研究有助于加深对其了解和认识,进而在实践中应用以提升用户体验。预判设计可以很好的在用户的操作过程当中进行简单高效的引导和预判,帮助用户更流畅舒适的使用产品。



2-1  顺应用户行为的预判设计

——————————————


在互联网发展中,产品功能的流程越长,操作步骤越多,越要求用户的理解能力和学习成本更大,耗时也会相应增加。因此体验设计师在理解用户行为的交互设计的基础上能够做到减少冗余步骤,简化操作流程。顺应用户行为的预判设计也可总结为四个字:以简驭繁。抛开繁杂的操作过程,运用更少的任务和行为来达成用户目标。简约不仅仅是视觉的形容词,同样适合行为。


支付宝 - 转账功能

聊天页转账:在支付宝聊天页,很多时候我们想给对方转账,会习惯性的在输入框中输入相应的数字,但在操作错误之后,支付宝会在输入框上方弹出相应数字的转账,点击之后会直接进入转账页面进行操作。对我来说,这个功能已经不是简单的帮助用户纠错,现在更像是一个快捷键一样方便着我们的操作。


手机号转账:当我们复制手机号后打开支付宝转账功能,会弹出该号码的转账气泡引导,提前判断了用户通过手机号去转账的路径。用户可以点击气泡一键跳转到转账页面。


消息页 - 找人转账:在消息页面,当用户开始上滑操作时,会出现「找人转账」的气泡提示,点击进入用户列表的简约页面,去掉了一些生活号服务号企业号等无用的对话框,提高了用户寻找的效率。

一个转账的功能,在不同的页面不同的场景下,支付宝在体验上把用户情景预判设计做到了极致,事实上,用户的行为中渗透了意识。从用户的行为推断用户意图,将用户的意图结果化,结合用户的使用场景,顺应用户的行为,缩短用户的路径,才能给用户带来最流畅的交互体验。

正如《一目了然》中所说,“当一个软件设计得很糟的时候,我们往往能立刻指出哪里做的很差;但一个优秀的软件,你却往往难以解释优秀从何而来”,因为沉浸式的流畅体验为你减轻了很多思考的路径与时间。


淘宝 - 智能填写地址功能

在新建收货地址的场景下,填写复杂的地址信息的过程往往都是繁琐而费时的,而设计师在此场景下考虑到用户需要地址的多样性,以及用户行为背后的含义,当用户复制了一段收货地址,打开新建地址页面时,App将主动提示弹窗“是否粘贴刚复制的信息”点击“确认粘贴”即可粘贴收货地址到对应列表项,这种预判设计对于用户来说是自然且让人愉悦的。我们不仅顺应了用户的操作行为,还在其中大大的帮助用户减少了很多操作。



2-2  分析用户行为的预判设计

——————————————

预判设计的主体是用户行为,从用户的视角出发,分析用户行为,是设计师建立在整个产品的交互里路程和功能框架上,对用户的行为深刻洞察后进行细节的改进。


Mac - 鼠标放大功能

当我们使用电脑时,总会发现找不到鼠标位置的情况,iMac设计师在识别到用户开始连续晃动鼠标时,分析到用户当前的状态可能是在寻找鼠标的位置,会对鼠标做一个放大的效果,帮助用户快速定位到鼠标的位置。


抖音 - 刚刚看过功能

在抖音我们刷到一些连载视频后,我们都会去进入作者的个人页去寻找上下集,在作者个人页作品很多的情况下,可能要寻找好久,抖音在个人页的作品卡片上添加“刚刚看过”的提示,方便了用户在浏览中能够更快速的定位到刚才的视频。方便继续衔接观看。虽然一个小小的功能提示,我们从用户行为,预判到用户的需求,带给用户更方便更快捷的体验。


美团外卖 -「再来一单」和「相似商家」

在美团外卖中用户可以在订单页面直接点击「再来一单」按钮选择和上次一模一样的商品加入购物车,如果一家店没有营业的话那么则会显示一个「相似商家」按钮。

结合实际我们操作的场景,外卖产品,我们重复下单的频率会比较高,当我们来到这个订单页面,「再来一单」的按钮可以更方便更快速的帮助我们下单,但当商家休息的时候,这个时候继续展示「再来一单」按钮对用户来说也是无效的,我们往往会回到首页去搜索相关类似的相关产品,然后再重新下单,而这时候「相似商家」按钮直接帮助用户一键定位到后续的一系列操作,真正的做到在分析用户行为中,预判用户操作。



2-3  符合用户行为的预判设计

——————————————


设计师做需求时,往往需要考虑在特定情景下,用户行为背后的思考与需求。因此符合情景的预判,我们也可称其为“符合用户感知的预判”。思考用户使用产品的情景,及时而高效的迎合用户对于当前场景的需求。


墨迹天气 - 降水雷达图

墨迹天气的降水雷达走势图,进入之后,放大、缩小屏幕就可以查看全中国的云图了,墨迹天气的云图可以查看到降水情况、闪电、积雪(冬天才有的功能),并且伴有文字提示,在未来两个小时的天气情况,方便了有出门需要的同学实时查看天气。


微信聊天 - 用户撤回消息/避免误点删除

在微信聊天功能中,我们可以对两分钟以内的消息进行撤回,但相信大家都有跟我一样的尴尬经历,发了错误的内容想要撤回,却一不小心点了删除,再也没有机会撤回了。

微信在这个功能上做了很好的改进,当我们的发出的消息小于两分钟时,该消息只能撤回,去掉了删除功能,在该消息超过两分钟后,则撤回按钮消失,只能进行删除操作,两个功能进行了互斥处理,很好的避免了这个场景下用户会误触。


宝 - 评价操作

当我们选择好评的时候,会自动勾选到“公开状态”,当我们勾选差评时,系统会自动取消”公开“状态勾选,默认匿名发送该评价,很好的保障了差评用户的人身安全问题和个人隐私问题。


宝 - 搜索结果页标签展示

当我们在淘宝搜索电脑包时,展示的内容下方会自动展示商品的容量标签“可放14寸电脑”,帮助用户在列表页面就能筛选到更合适自己的商品,当搜索玩具时,也会展示当前商品适用的年龄段。产品根据用户搜索的内容,自动匹配能够帮助用户进行筛选的标签。


小结

——

预判设计当中我们从三个层面进行了分析,从顺应用户行为的预判设计,到分析用户行为的预判设计和符合用户行为的预判设计。一个好的产品,往往会更多的使用用户语言,通俗易懂地让用户可以对整体的使用方式一目了然,而不是产生一系列的问题,迫使用户停下来,进行不必要的思考。用户的每一次停顿对我们来说可能都是一次用户流失。而预判设计要做的,是根据用户的行为/用户所在的场景,让功能主动找到用户,并让用户与之产生自然的交互。



场景化设计中,以情感化为目标的设计同样需要具体场景具体分析,通过细节上的改变使得产品在当前场景下能够与用户产生更多共鸣,主要从细节出发满足用户在当前场景下的情感需求,让用户感动,给用户惊喜。

其实用户在使用产品的过程中,同样渴望在使用产品时能够得到情感上的互动,这反映在设计上即是产品情感化设计。情感化把握得好的产品往往更能抓住用户的心。



3-1  本能层的情感化设计

————————————


躺平 - 空状态页面

躺平是一款阿里旗下的生活方式APP可爱的小人和拟人的语气,设计师让每一个空白枯燥的空页面瞬间变得可爱和有趣起来。


快手 - 节日开屏设计

快手在每一个特殊的节日都会给用户送来精美的开屏祝福,让用户在节日当天打开app就能接受感受到产品满满的心意和祝福。


B站/快手/网易云音乐 - 生日祝福

在用户生日的这个特定时间和特定场景下,很多产品都给予了用户不同的生日祝福,B站是一张有关于星座的动漫海报,快手给用户定制了专属生日开屏,网易云音乐的每日推荐为用户献上生日快乐歌,不同的产品结合自身不同的产品属性,给一位用户都带来了不同的生日祝福。



3-2 行为层的情感化设计

————————————


腾讯视频 - 夜深了提示

想必大家都有熬夜刷剧的经历,在腾讯视频中,在全屏模式下点击退出清屏模式下,页面上方的时间旁边会显示夜深了,只是简简单单的三个字,这深夜在这个场景下,感觉内心也有一瞬间被人关心的触动,体验了一个产品的人文关怀和对用户的体贴。


QQ音乐 - 会员到期弹窗

QQ音乐的绿钻到期挽留弹窗真的是别出心裁,推荐了4首歌曲,连起来就是VIP我们舍不得重要的你,用歌曲的的名字来表达对用户的诉求,趣味化的设计让这个小小的挽留弹窗不仅没有感觉到打扰,还感觉很有趣。


美团外卖 - 订单页面的天气

当有特殊天气时,我们打开美团外卖的配送页面时,页面会在页面中做当前天气的拟实物效果,下雨天整个页面也是下着大雨,下雪天整个页面飘着雪花,甚至雾霾天气整个页面是是伴着黄黄沉沉的云,设计师预判到用户打开该页面是想看外卖到了哪里,看到外面的天气如此糟糕,大家都不忍心催促外卖小哥了,大大减少了特殊天气下配送不及时的投诉率。


Bibilibi - 密码输入

在B站输入密码的时候,页面上方的小人会遮住眼睛,潜台词:我不看,你放心输入吧。在输入密码的情景下,设计师用趣味生动的卡通形象给用户带来了更信任更安全的感知。


Bibilibi - 黄油相机加载动画

黄油相机的加载动画,是一个可爱的切黄油的小人,并且加载当中的文案,会告诉用户当去前正在加载的内容是什么,能够让用户对于加载的时间有预期,让等待加载的过程不会枯燥。


3-3 反思层的情感化设计

————————————


苹果 - 残章人士emjio

苹果新增 13 个与残障人士相关的 emoji,包括导盲犬、轮椅、义肢、戴着助听器的耳朵等。有意思的是,苹果不仅按照以往的做法为涉及人物的 emoji 按照性别和肤色提供多个版本,而且在表示辅助器具的 emoji 中还做了细节上的区分,比如轮椅有手动和自动之分,不同导盲犬的导盲鞍样式也有所不同。

回看历年苹果emoji的更新,从肤色平等,到性别、性向平等,再到为残疾人设计,这让我想起了苹果为残章人士做的广告 - 科技属于任何人



豆瓣 - 悼念已故用户

最近,快手B站豆瓣等都陆续上线了“纪念账号”,产品的意义不仅仅是留住生者的精彩瞬间,更多的也是留住逝者的人生印记,对已故用户的账号进行保护,豆瓣在已故账号上做了悼念用户的活动“在他/她的头边放一束山茶花”的方式来纪念已故的用户。


腾讯公益 - 404页面

腾讯公益的404页面,这个项目的灵感源于欧洲失踪儿童联合会主导的,名为“NotFound Project”的网络公益工程。就是利用404页面展示那些被拐卖儿童、失踪儿童的信息,帮助那些孩子重新找到家人。


丁香园 - 404页面

丁香园404页面界面展现了因恶性医患遇害的医生同道,文案是“你所访问的页面就如那些遇害的同道,已离我们远去。”下面还会有这些白衣天使的照片和名字。以这样的方式悼念亡者,也侧面展现了丁香园的社会价值。

在页面走失的这种特殊场景下,404页面视作可被利用的空间,来呈现公益信息,这种方法暂时减弱了用户对产品页面走失的愤怒,将注意力转向对弱势群体或社会问题的关心,侧面感受产品的社会价值,这种方法适用于社会公益性质或相关业务的产品。以上的腾讯公益和丁香园对于这块的设计都是很好的案例参考。


快手 - 搜索页负面情绪引导

在快手搜索一些负面的情绪词汇时,会提示用户“别怕,我们都在”。并附有24消失免费心理危机咨询热线,从推荐位banner点击后会进入一个群聊,里面都是其他用户留下的暖心话语,这些情感化的设计让那些正在经历困难,或者想要终止生命的人传递以温暖。我们可以帮助你,你并不是孤单一人。微信/知乎等搜索引擎下都有不同的对于该情况的情感化设计。


京东/淘宝 - 搜索页面濒危动物保护

在京东搜索穿山甲,会直接挑战到保护濒危动物页面,传递出了一个企业对动物的保护意识。页面中的穿山甲≠治病,向全民科普濒危动物的现状和对于人们对于野生动物的错误认知。淘宝更是对野生动物保护启动了绿网计划,搜索穿山甲/象牙等都会进入到该活动页面。


小结

——

情感化离不开场景化设计,上面四个案例分别是两个404页面以及两个搜索引擎的不同设计,不同的产品赋予了不同的含义。不同的场景下设计师也需要有不同的思考,陪伴产品一同进步。

情感化设计更多的是带给用户瞬间感动,很难形成长期的用户激励或用户增长,因此情感化设计主要目的是通过情感累加,提升产品品牌形象;产品不仅是所有功能的集合,他们真正的价值可以是满足人们的情感需求,而其中最重要的需求就是建立自我形象与社会地位。 反思层是包含并超越前两个层次,我们要经常思考,为什么同类型的产品,我们要选择它,为什么它给我留下了很深刻的印象,这都是反思水平的设计需要做的。


文章来源:站酷  作者:刘狗蛋

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


日历

链接

blogger

蓝蓝 http://www.lanlanwork.com

存档