Be For Web - 情境 http://www.beforweb.com/taxonomy/term/137 en 锁屏小组件需要考虑情境信息的传达 http://www.beforweb.com/node/1121 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-icon-s-widgetkit.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>偶有所感,起意起笔,望自知所言。</p> <p>由 iOS 16 锁屏小组件想到。近来看到一些开发者的稿子或 TestFlight,或简约或精美,大都能将新系统新特性和自己的产品比较恰当的结合起来,给人带来不错的锁屏信息快速获取体验。</p> <p>但其中往往有一些共通的小问题。见多了也便察觉到规律。即,开发者本人固然了解自己所设计与实现的锁屏小组件为何物,而站在用户的角度则未必。问题在于:无论是占据单格的进度或数字形式,还是双格的图表或文本形式,锁屏小组件非常容易令人混淆,甚至忘记其所属的 app 或功能。因为:</p> <!--break--><p>锁屏无法提供 app 自带的情境感。</p> <p>我们习惯了面向 app 的内部环境进行设计,即,可以假设用户在绝大多数时候拥有明确的情境感知,因此多数界面框架、控件、元素当中无需刻意体现情境或品牌信息。你可以认为用户知道自己在哪里,所处理的信息类型为何,对交互结果也有大致预期。</p> <p>但锁屏小组件自身以较为单一的控件形式出现,且锁屏界面本身缺失特定 app 或功能的情境感,因此当我们习惯性的把一个自认为用户熟悉的控件放置其中时,控件自身实际上无法传递更多关于所属产品的显而易见的信息。</p> <p>除非通过其中的内容本身,或额外的图形元素来提供线索。如果内容为数字形式,考虑提供明确的单位,或任何与 app 相关的只言片语作为暗示。文本内容同理。而恰当的图形元素,譬如 app icon 中的标志性元素,或 app 内的令人耳熟能详的典型视觉元素,等等,亦有效用。</p> <p><img alt="" src="/sites/default/files/images/2022/640.jpeg" style="width: 450px; height: 333px;" /></p> <p class="figure-caption">系统是不错的参考:世界时钟、空气质量、日落时间</p> <p>另外建议更实境化的测试。将自己 app 的锁屏小组件与其他 app 的一并放在锁屏中,测试实际感知,考量是否可能产生歧义或完全无法传达情境信息。</p> <p>大致这样。</p> <p><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="width: 500px; height: 128px; border: none;" /></p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/319" typeof="skos:Concept" property="rdfs:label skos:prefLabel">小组件</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/318" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Widgets</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/359" typeof="skos:Concept" property="rdfs:label skos:prefLabel">iOS 16</a></li></ul> Sun, 21 Aug 2022 15:39:03 +0000 C7210 1121 at http://www.beforweb.com http://www.beforweb.com/node/1121#comments 图文版 WWDC 设计分会:跨平台设计 (1) 平台选择 http://www.beforweb.com/node/1056 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-wwdc-2019-apple-s.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>风扇的声音承载着夏天的味道。然而明明已是九月中旬,暴躁的阳光却依然一马平川地肆虐在大地上,将一切映照得如此刺眼。</p> <p>过去一两周稍作休息,本周继续&ldquo;图文版 WWDC 设计分会&rdquo;,进入新的系列。<br /> ​<br /> 开始之前我们稍作回顾。目前已经完成的两个系列包括:&ldquo;<a href="http://beforweb.com/node/1047" target="_blank">iOS 13 设计新特性</a>&rdquo;,涉及深色模式、SF Symbols、卡片面板及情境菜单等话题,错过的朋友不妨回看,毕竟新系统将会在近两日正式推送。在&ldquo;<a href="http://beforweb.com/node/1051" target="_blank">基础设计原理</a>&rdquo;当中,演讲人通过一场夏威夷之旅带领我们了解了一系列重要的设计原理,包括一致性、可供性、心智模型、渐进呈现等等,深入浅出,老少咸宜,强烈推荐。</p> <!--break--><p><img alt="" src="/sites/default/files/images/201909-WWDC-56/170-essential-design-principles.png" style="width: 620px; height: 362px; border: noen;" /></p> <p class="figure-caption">Mike Stern 老师的&ldquo;基础设计原理&rdquo;</p> <p>而本期开始的新话题则聚焦于如何面向 Apple 生态体系中的多种设备进行设计,包括如何选择平台,如何针对不同的平台权衡功能与外观风格,如何构建生态体验等等;演讲者是 Apple 的设计师 Cas Lemmens。</p> <h3> 跨平台设计 - 平台选择</h3> <p>在 Apple,我们非常自豪于我们所创造的一系列设备平台。在创造和升级这些平台的过程中,我们都会以提升人们的日常生活品质为目标,并力图在人与设备之间构建富有意义的关联。这关联未必仅存在于单一平台当中;你所使用的 Apple 设备越多,便越发能体会到整个生态带来的依存关系。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00002-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>你可能会戴着 Apple Watch 晨跑,可能会在 MacBook 或是 iMac 上完成一天的工作;下班后,你可能会借助 iPhone 的一系列功能来使用公共交通,或是在你的车里使用 CarPlay;回到家,你可能会通过 Apple TV 看剧或电影;睡前,你可能还会在 iPad 上读书。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00004-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00005-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>无论你正在使用何种设备,Apple 的平台生态都可以识别你、理解你,并帮助到你。</p> <p>面向这样的生态体系进行设计,你必须对其中的每一个平台都有着深刻的理解。对于 Apple 的设计师而言,这样的挑战已经变得司空见惯。我们必须谨慎思考每一个 app 可能适合的平台类型,以及如何使其针对不同的平台进行相应的调整。</p> <p>Apple 开发的 app 当中,有些是面向全平台的,例如&ldquo;照片&rdquo;或&ldquo;音乐&rdquo;。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00009-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>而有些则仅存在于特定的平台当中,例如&ldquo;备忘录&rdquo;、&ldquo;邮件&rdquo;等等。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00011-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>有些服务可以在你拥有多种设备的情况下带来最优体验,例如 ApplePay;另外一些则必须基于多台设备同时运行,例如 FaceTime。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00014-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>今天,我要与各位分享的,便是 Apple 的设计师在进行跨平台设计时所采用的典型流程。希望这些经验可以帮助各位更加高效且目标明确地将你的产品和服务推向 Apple 生态圈当中的更多平台。</p> <p>我们首先会从&ldquo;<strong>平台选择</strong>&rdquo;开始,即了解每一个平台的情境特质与能力特征,并以此为基础选择最恰当的目标平台。</p> <p>然后是&ldquo;<strong>平台适配</strong>&rdquo;,即基于目标平台的设备特性,对我们希望实现的功能进行权衡与管理。</p> <p>接下来是&ldquo;<strong>风格协调</strong>&rdquo;,即在品牌风格与平台规范之间寻求平衡,对 app 的视觉外观及操作体验进行定义。</p> <p>然后是&ldquo;<strong>平台连接</strong>&rdquo;,即探索如何在不同的设备平台之间实现功能的连续性,打造轻松、无缝的使用体验。</p> <p>最后,我们还会尝试&ldquo;<strong>平台扩展</strong>&rdquo;,即探索如何同时基于多平台实现最优的综合生态体验。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00015-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>以上便是跨平台设计的主要流程。接下来,我们将对这五个步骤逐一进行了解。</p> <h4> 平台选择</h4> <p>所谓&ldquo;平台选择&rdquo;,即回答&ldquo;我要面向哪个平台进行设计&rdquo;这个问题。</p> <p>或许你还没有上线过任何 app,目前正在考虑以哪个平台作为首发;或许你已经在一两个平台上发布过 app,正在考虑接下来应该进行怎样的扩展。</p> <p>在选择平台时,有两个最为关键的概念需要我们重点思考:</p> <ul> <li> 情境:特定平台最为适用的时间、地点及其他环境要素。</li> <li> 能力:特定平台最具差异性的功能特征。</li> </ul> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00016-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>对于&ldquo;情境&rdquo;的理解至关重要,因为当情境发生变化时,人们通常会切换他们所使用的设备,以不同的方式完成不同的任务。</p> <p>举个例子。譬如你正在办公室里工作,或是在学校上着课;这些都是高度聚焦和稳定的情境。当你离开这些场所,乘上了公交车或地铁,你便进入了高度动态和移动化的情境。这两类情境之间的差异非常明显,我们通常会从 Mac 切换至 iPhone 或 Watch,因为后两者本就是面向移动化情境进行设计的。</p> <p>而对于&ldquo;能力&rdquo;的理解则可以帮助你掌握并充分利用特定平台的独特功能。</p> <p>接下来,让我们从&ldquo;情境&rdquo;与&ldquo;能力&rdquo;这两个方面,对 Apple 生态体系当中的一些典型平台进行分析。</p> <h4> 平台分析</h4> <p>首先是 iPhone,因为这可能是我们多数人最为熟悉的平台了。</p> <p>从情境的角度来看,iPhone 始终保持开机,始终与我们相随,因此它是高度移动化的;同时,iPhone 也是高度私人化的设备,我们不会轻易与他人共享使用;此外,iPhone 通常被用于高频而短时的互动,我们每次使用不会超过几分钟。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00017-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>iPhone 所具有的能力可以有效地支持其情境特质。&ldquo;始终开机,常伴于身&rdquo;的特性要求 iPhone 必须具备良好的环境感知能力,其内置的陀螺仪、加速计等传感器可以始终在背景进程当中处理环境相关的信息,即便是在我们没有使用 iPhone 的时候;iPhone 的 Touch ID(及 Face ID 等机制)则会为我们提供私人化的保护;其高清晰度的触屏则能确保我们在短时间的互动过程中获得轻松与愉悦的体验。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00018-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>与 iPhone 类似,Watch 也具备&ldquo;始终开机,常伴于身&rdquo;的特性,且同样是高度私人化的。但 Watch 具有更强的即刻性,所面向的是更为短暂的互动,譬如你只需一瞥便可以从表盘上获取与当下情境最为相关的信息;而提示信息在你注视稍久时还会进一步提供详细信息。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00019-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>Watch 所具备的能力与其私人化的情境特质息息相关。Watch 可以追踪你的运动状态、地理位置及心率;其触觉反馈可以通过轻触手腕来提醒你查看信息;而表盘也是高度定制化的,你可以让最为需要的信息始终呈现在表盘之上,便于一瞥之间快速获取。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00020-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>而 iPad 则具有较为复杂的情境特质,既可以被用于稳定的环境,同时也支持移动化场景。你可以用 iPad 完成一些精确而聚焦的任务,也可以将其作为放松型设备来享受影视或游戏体验。而所有这些互动过程都比 iPhone 或 Watch 更加持久。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00021-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>从能力的角度,iPad 的大屏正是对这些情境特质的有效支持。充足的屏幕尺寸可以帮助你完成高精度的操作,环境光传感器可以使其良好适应于日夜不同的光照条件;高保真扬声器和高精度触屏可以为影音或游戏带来更具沉浸感的视听体验;若是配合 Apple Pencil,iPad 还能帮助你完成更加精确、更具创意性的工作。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00022-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>再来看 Mac。其情境特质具有高度的专业性,你可以进行非常精确而聚焦的工作,譬如设计和开发 app;MacBook 可以被作为共享设备来使用,但它同时也是个人化的,因为多数使用者都拥有独立的个人帐户;我们通常会长时间使用 MacBook 或 iMac,譬如每天都会有几个小时的互动时间。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00023-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>在能力方面,为了支持高度专业化的任务,Mac 具备着非常高的性能表现;键盘鼠标可以帮助你进行精确而复杂的操作;多任务能力允许你以自己所需的方式进行工作;而多帐户体系则能使 Mac 适用于更多样的工作场景。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00024-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>最后来看 Apple TV。这是生态当中最具共享性的平台,我们通常会与家人或朋友一起观看;TV 最具稳定性,始终与电视机绑定在一起,不会四处移动;TV 是完完全全的放松型设备,我们用它来享受影音或游戏,每次使用时长通常在三十分钟到几个小时之间。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00025-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>配以高清显示屏,TV 的画质将会鲜活得呼之欲出;TV 的遥控器轻便易用,你可以轻松地将其传递给朋友和家人;TV 可以与 HomeKit 良好配合,使其高度稳定的特性得以在&ldquo;家庭&rdquo;这个场景中充分地发挥;其界面设计特别面向 10 码左右的距离进行优化,使你可以轻松地窝在沙发里享受娱乐体验。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00026-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>通过以上分析,你便能理解,为何了解每个平台的&ldquo;情境&rdquo;与&ldquo;能力&rdquo;对于你的目标平台选择来说是如此重要的事了。</p> <p>&ldquo;情境&rdquo;是平台的立命之本,而&ldquo;能力&rdquo;则决定了其独特性。</p> <p>对于你的 app 来说也是如此。你需要问自己两个关键问题:我的 app 可以在怎样的情境里体现产品价值?要实现产品价值,需要哪些特定的技术能力作为支持?</p> <h4> 平台选择练习</h4> <p>在 Apple 内部,每当需要为 app 选择目标平台时,我们都会反复进行一项简单的练习。现在我来为各位进行演示。</p> <p>首先让我们以&ldquo;健身记录&rdquo; app 为例。</p> <p>想想看&ldquo;健身记录&rdquo;的产品特性,你会发现它首先必须具备移动性。它需要追踪你全天的运动行为,以便进行精确的数据统计。因此它需要设备平台具备&ldquo;始终开机,常伴于身&rdquo;的特质,即高度的移动性。</p> <p>同时,&ldquo;健身记录&rdquo;还必须是私人化的。它应该能且只能追踪你个人的数据。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00027-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>接下来,我们要通过象限图来建立情境特质与平台之间的映射关系。其中横轴代表&ldquo;移动性&rdquo;,从左到右递减;一系列 Apple 设备平台按照各自的特质分布在轴线上,譬如 Watch 最具移动性,而 TV 最具稳定性。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00028-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>而纵轴代表&ldquo;私人性&rdquo;,从上到下递减。其中 Watch 最具私人性,TV 则最具共享性。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00029-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>对于&ldquo;健身记录&rdquo;而言,由于要同时具备高度的移动性与私人性,因此在象限图当中会大致位于左上方的位置。这便解释了为什么它会出现在 Watch 和 iPhone 当中,而非其他平台。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00030-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>接下来我们以 GarageBand 为例。</p> <p>GarageBand 涉及到的人机互动是高度精准型的,因为人们需要非常准确地操作音频内容,使它们出现在正确的时间和地点。</p> <p>此外,GarageBand 必须良好地支持多任务,因为人们往往会将多种音频器材和乐器连接进来同时进行演奏。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00031-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>我们通过象限图来建立映射关系。其中横轴代表交互的精确性,左端为粗放型,最具代表性的平台是 Watch,因为其屏幕较小,而人们的手指相对粗大,难以完成具有高精度要求的操作;右端为精准型,代表平台为 MacBook 或 iMac,因为键鼠操作具备最高的精确度。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00032-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>纵轴则代表&ldquo;多任务能力&rdquo;,从上到下递减。在 Mac 上,我们可以轻松地进行多任务操作;而对于 Watch,你每次只能完成一项任务。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00033-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>GarageBand 需要同时具备高度精确的交互能力,以及良好的多任务能力,因此在象限图当中会大致位于右侧偏上的位置,所对应的即是 Mac、iPad 和 iPhone。</p> <p><img alt="" src="/sites/default/files/images/201909-DC-DAP/00034-designing-across-platforms.png" style="width: 620px; height: 362px; border: noen;" /></p> <p>这两个例子都非常简单,各自仅涉及到两方面的情境特质。在实际当中,我们通常需要将更多、更复杂的特质因素考虑进去;最终,我们希望能够为 app 找到最适合其生存的平台。</p> <p>以上便是跨平台设计流程中的第一步,&ldquo;平台选择&rdquo;,即综合考量不同设备的情境特质及能力特征,进而为 app 选择最为适合的平台。</p> <p><img alt="" src="/sites/default/files/images/s/Banner-PS-BFW-3x.png" style="width: 600px; height: 154px;border:none;" /></p> </div></div></div><ul class="field_categories"><li class="product taxonomy-term-reference-0"><a href="/product" typeof="skos:Concept" property="rdfs:label skos:prefLabel">产品</a></li><li class="design taxonomy-term-reference-1"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/292" typeof="skos:Concept" property="rdfs:label skos:prefLabel">WWDC</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/200" typeof="skos:Concept" property="rdfs:label skos:prefLabel">产品设计</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/167" typeof="skos:Concept" property="rdfs:label skos:prefLabel">跨平台</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Wed, 18 Sep 2019 15:48:02 +0000 C7210 1056 at http://www.beforweb.com http://www.beforweb.com/node/1056#comments 不知道,看情况 http://www.beforweb.com/node/866 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-n-logo-comment-mistake-error-user-experience-design-ui-interface-product.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>怕是入冬前最后一个温暖的周末?下午四点不到,已经眼见着阳光开始暗淡下来,那团柔和的光亮向着西边的天际线渐渐沉去,挂在床头的麻叶头巾与美国国旗在夕阳的映照下显得有些乖巧。</p> <p>在一个天气仿佛文科班姑娘难以名状与揣摩的心绪一样的城市里,冬天从不会如此可爱,周末却很久没有如此安宁闲散,我甚至睡了午觉,并梦见在练鼓,将一首节奏机械的舞曲改编成了Dave Grohl风格,醒来之后依旧心潮澎湃。</p> <p>太多是真的,太多是假的。记忆是真的,记忆是假的。亦真亦假的现实的气息就这样一周一周的通过一些弱不禁风的文字做着标记。我就是在做这件事。</p> <p>VR休耕一周。回归传统UX话题。</p> <p>下面进入译文。译文。译文。</p> <p>UXer们很喜欢讨论,而且总会因为某些话题而最终升级为争论。在同行们碰面的时候,试着抛出这些问题:</p> <ul> <li> Material Design(或&ldquo;扁平化设计&rdquo;等等)好还是不好?</li> <li> 哪款原型工具最好?</li> <li> 我是不是不应该在界面里使用轮播(或&ldquo;汉堡包菜单&rdquo;等等)?</li> </ul> <p>多数人会侃侃而谈,你能得到各种各样的答案,形形色色的似乎都有道理。</p> <p>但很少有人会说:&ldquo;不知道,看情况。&rdquo;</p> <!--break--><p>或许因为UX设计师通常会被认为(或自诩为)能够完美回答所有这类问题?只是我认为UX方面的很多问题实在没有所谓的完美答案。需要综合考虑的因素太多,而且并非一成不变,我们始终需要在用户、技术、业务等诸多要素之间寻求平衡点。</p> <p>UX设计师不是知道所有答案的人,而是懂得寻找最优解决方案的人。</p> <h3> 看什么情况?</h3> <p>对于你的项目,Material Design可能&ldquo;好&rdquo;,也可能&ldquo;不好&rdquo; - 脱离了特定的产品,所谓&ldquo;好与不好&rdquo;的问题没有任何意义。你在设计怎样的东西?要解决怎样的问题?聚焦于哪一类用户群体?他们通常在怎样的环境中通过怎样的设备使用你的产品?此外,Material Design这个概念本身就很宏观,包含很多方面的组成要素。</p> <p>再以原型工具为例,市面上的选择有太多,各有特色,你无法绝对客观的评判出一个&ldquo;最好&rdquo;的产品,但我们能够确定的是,对于你来说,最适于解决你的特定需求的、最易学易用的那一款就是&ldquo;最好&rdquo;的 - 这个问题的答案最终取决于你要实现哪种类型的原型,以及你自身的能力。</p> <h3> 避免非黑即白</h3> <p>我们通常所理解的那些设计原则在特定的情境中同样会受到挑战,一成不变的解决方案并不存在,你需要考虑诸多方面的因素以最终制定设计决策,&ldquo;看情况&rdquo;才是常态。</p> <h4> 坏模式?也未必</h4> <p>近些年,汉堡包菜单在可达性等方面被各种诟病。选项默认会被隐藏起来,人们越发觉得这种方式弊大于利。不过实际上,汉堡包菜单的&ldquo;好与不好&rdquo;也要看情况。在特定的界面环境中,如果设计意图本就是希望将次要信息或动作默认隐藏起来、从而使主要信息得以最大化的突出呢?这种情况下,汉堡包菜单便是一种不错的模式。</p> <p>轮播的口碑也是越来越差,太多内容被隐藏起来,发现的成本较高,内容易被错过。不过同样,优劣取决于实际情况。如果设计本就意在隐藏次级内容而突出重点内容呢?不妨将其看做用以区分不同权重信息的设计手段(参考&ldquo;<a href="http://beforweb.com/node/770" target="_blank">显而易见的,易达易用的,可达可用的</a>&rdquo;一文),类似亚马逊展示相关产品时的做法,或是Airbnb在搜索结果页面展示房屋照片的设计模式。</p> <p><img alt="01-ux-design-ui-depends.png" src="/sites/default/files/images/201610-4/01-ux-design-ui-depends.png" style="width: 600px; height: 224px;" /></p> <p><img alt="02-ux-design-ui-depends.png" src="/sites/default/files/images/201610-4/02-ux-design-ui-depends.png" style="width: 415px; height: 342px;" /></p> <h4> 基本设计原则的相对性</h4> <p>近年来,&ldquo;符合直觉&rdquo;一词在UX行业怕是有些被过度使用了。人们不需要怎么学习和适应的模式就是符合直觉的优秀模式?仔细想想也不尽然,最典型的一个案例便是苹果在几年前的一次Mac OS X更新当中将滚屏与触控板操作方向的对应关系完全调转了过来,与触屏设备的模式保持了一致。在当时,这对于桌面设备来说简直是最不符合直觉的设计决策。但实际情况是,已经在触屏设备上习惯了这种对应关系的用户们很快便接纳了桌面设备上的这次革新。</p> <p>此外,我们都知道不该给用户太多选项,以便将认知负荷控制在较低的范围内。但这一原则的适用性同样无法脱离具体的产品环境。如果产品本身就具有超高的复杂度,或是大范围的选项本就是产品的价值所在呢?Photoshop、Axure、Excel等等都是我们平日能够直接感知到的典型案例。它们的功能量级都相当庞大,各种菜单、工具栏、面板...界面环境极为复杂,但我们每天都在反复而高效的使用着。对于这样的产品,UX设计的重要工作之一就是管理复杂度,而非强求简化。</p> <h4> 情境是一切</h4> <p>可以良好运作于其他产品的设计模式未必适用于你的产品;可以良好运作于某一类硬件平台的界面未必适用于其他平台,诸如此类,皆通一理,关键在于&ldquo;情境&rdquo;:你的产品有特定的用户群体,他们有特定的需求及使用环境,作为设计师,就是要事无巨细的去&ldquo;看&rdquo;这些特定的&ldquo;情况&rdquo;。即便那些很重要的设计原则,譬如&ldquo;保持一致性&rdquo;或&ldquo;遵守设计规范&rdquo;等等,在各种&ldquo;情况&rdquo;面前实际上都是次要的。</p> <h3> 没有完美的答案</h3> <p>如果UX设计师们知道所有问题的答案,用研也就没有存在的必要了。所以下一次如果你被问到难以或根本无法被明确回答的问题时,&ldquo;不知道,看情况&rdquo;可能就是最为准确的答案。当然,对于这样的问题,&ldquo;看情况&rdquo;只是一个开始,具体看怎样的情况,在不同的情况下有怎样的答案,才是需要进一步分析和思考的。也许你可以反过来问一些问题,或是和用户聊聊,或是做些必要的用研工作来探索真正的答案。寻找这些答案的过程实际上就是UX工作最令人兴奋的地方之一。</p> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/115" typeof="skos:Concept" property="rdfs:label skos:prefLabel">视觉设计</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/68" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计模式</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Mon, 07 Nov 2016 04:21:30 +0000 C7210 866 at http://www.beforweb.com http://www.beforweb.com/node/866#comments 设计师应该了解的Beacon基础知识 - 交互体验解析 http://www.beforweb.com/node/485 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/logo-s-icon-beacon-ibeacon-app-mobile-ux-product-design.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>上周四和小伙伴们去了辰山植物园。然后预订今天和老小伙伴们再次去辰山植物园。然后因为刮风下雨没去成。没了野餐,没了蛋糕,没了小春游。一切讨厌的事情全都怪天气不好。</p> <p>周末伴随着坏天气很快就要过去的样子这让我觉得很没劲,根本就是任何事情都没什么心情做,站也没建书也没看琴也没弹,完全没有建设性!...话说博客也是正事,继续上周关于Beacon基础知识的话题,开拓开拓视野呗。下面进入译文。</p> <p>OK,我们已经了解了<a href="http://www.beforweb.com/node/484">Beacon是什么</a>,很棒。接下来的问题是,作为设计师,我们能做些什么?我们能在这种技术平台上打造怎样的交互体验?</p> <p>我和我的搭档Nick Urban决定把这个问题拆解,将Beacon涉及到的交互模式进行分割,以一种清晰的、尽可能非技术化的方式把其中的每个方面都搞清楚。</p> <!--break--><p><img alt="01-beacon-interaction-ux-design-glossary.jpg" src="/sites/default/files/images/201405-2/01-beacon-interaction-ux-design-glossary.jpg" style="width: 500px; height: 298px;" /></p> <p>我们认为,这种方式也能帮我们更好的评估Beacon技术带来的各种可能性,而不只是将目光局限在零售/优惠券等等方面的情景当中。</p> <p>我们希望本文能够对以下这些人有所帮助:产品人员、设计师、开发者、满脑子疯狂创意的硬件创业者...基本上,就是所有想要了解或打造Beacon交互体验的人吧。</p> <h3> 怎样对问题进行解构?</h3> <p>我们试着从整体上对Beacon平台进行俯视,看看能从中分割出哪些部分,以组成一套比较典型的&ldquo;Beacon交互体验&rdquo;,解构的结果大致包含以下四个部分:</p> <ol> <li> <strong>设备通讯</strong>:设备之间是怎样进行通讯的?</li> <li> <strong>代表</strong>:每个Beacon设备代表着什么(谁)?</li> <li> <strong>用户情境</strong>:当Beacon系统内发生着人机互动时,用户的心智情境是怎样的?</li> <li> <strong>邻近响应</strong>:邻近系统中的变化会触发怎样的响应?</li> </ol> <p>任何一种Beacon系统的交互体验都可以被分割为这四个&ldquo;切片&rdquo;。此外,在进行详细分析之前,我们还需要学习一点基础知识,对Beacon系统的一些软硬件组成要素进行了解;我们把这部分称为&ldquo;切片0&rdquo;。</p> <h3> 切片0:Beacon系统组成要素</h3> <p>其实&ldquo;Beacon&rdquo;这个说法有些信息过载了;我们来按照不同的情境将这个概念进行解析:</p> <h4> Beacon设备</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="02-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/02-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>具备蓝牙能力的小盒子,安静的呆在那里每隔几毫秒就播放一次信号,以表明自己的存在;除此之外它不能做任何其他事情,生活蛮无聊的。</p> <p>不过,也正是这唯一的一个能力可以使其被&ldquo;Beacon探测设备&rdquo;发现,并使后者能够持续计算出与Beacon设备之间的距离。</p> </div> </div> <h4> Beacon探测设备</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="03-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/03-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>通常就是指我们的智能手机、平板电脑或某些&ldquo;迷你计算设备&rdquo;(例如&ldquo;<a href="http://zh.wikipedia.org/wiki/树莓派">树莓派</a>&rdquo;,Raspberry Pi)&mdash;&mdash;任何能够扫描到Beacon信号并探测出两者距离的设备。</p> <p>本质上讲,Beacon探测设备无非也就是个具备蓝牙能力的小装置,但不同之处就在于它是附加在智能设备之上的,这就使其能够以非常强大的、充满想象力的方式对Beacon信号做出响应。</p> <p>另外,通过编程,任何一种Beacon探测设备都可以变身为具备信号播放能力的Beacon设备(或称&ldquo;虚拟Beacon&rdquo;),只要你愿意。</p> </div> </div> <h4> Beacon SDK</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="04-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/04-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>Software Develoment Kit,软件开发工具包,也就是开发者用来在应用当中实现信号扫描、距离计算或信号播放功能的代码库。</p> <p>开发者们可以将不同的SDK搭配在一起使用,以打造更加强大的功能。例如通过Beacon的SDK实现与特定地点的距离探测功能,进而触发一些由AR(Augmented Reality)方面的SDK所实现的现实增强功能。</p> </div> </div> <h4> Beacon平台</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="05-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/05-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>以上这些要素的总和,外加一点其他的东西。当你走过了探索和实验阶段,准备以一定的规模将Beacon设备及服务投入到实际运用当中时,所要考虑的就是这个整体概念了。</p> <p>Beacon厂商们推出了很多互具竞争性的平台,其中通常包括一整套解决方案,例如Beacon硬件设备、内容及媒体管理服务、部署及设置Beacon设备的管理系统、厂商定制化的SDK开发包等等。</p> <p>举例来说,Qualcomm的<a href="https://www.gimbal.com">Gimbal平台</a>面向不同的物理环境提供了不同种类的Beacon设备,相应的SDK也包含了各种类型的功能,例如地理围栏(Geofencing)、数据分析、消息推送、可由终端用户定制的隐私管理等等。</p> <p>关于基础知识的了解就到这里(也可参考<a href="http://www.beforweb.com/node/484" target="_blank">设计师应该了解的Beacon基础知识 - 什么是Beacon?</a>一文来了解更多),接下来我们进入前面提到的四个切片当中的第一个。</p> </div> </div> <h3> 切片1:设备通讯</h3> <p>在任何一个Beacon交互系统中,必然有一个设备扮演信号广播者的角色,而另一个扮演着接收者的角色。不过有些设备还能同时扮演这两种角色,所有设备之间共有三种可能的通讯模式。</p> <h4> 广播者</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="06-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/06-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 通常指Beacon物理设备,例如<a href="http://estimote.com">Estimote</a>或<a href="http://beekn.net/guide-to-ibeacons/">其他</a>。</li> <li> 此外,智能手机、平板电脑或其他计算设备上的特定应用也可以被编程成为单向的广播者。</li> <li> 想象一下博物馆某展区当中放置着Beacon设备供游客在手机上接收相关文物信息,或是智能手机、可穿戴设备扮演着广播者的角色,在用户(例如病患)失去意识或行动能力的时候向急救人员发送病人的医疗数据信息等使用情境。</li> </ul> </div> </div> <h4> 接收者</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="07-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/07-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 通常指我们手中的智能手机或平板电脑,或任何带有蓝牙连接功能的计算设备。</li> <li> 想象一下智能手机上的特定应用接收到博物馆某展区中的信号后自动推送相关的文物信息,或是某种具备蓝牙连接功能的计算设备被安装在急救车里,当扫描到病患身上的智能手机或可穿戴设备发送的特定信号后,便能接收病人的医疗数据。</li> </ul> </div> </div> <h4> 广播者/扫描者</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="08-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/08-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 能够同时发送和接收Beacon信号的设备。</li> <li> 想象一下智能手机上的特定应用,一边能接收到零售店中的Beacon信号并展示特价商品信息,一边还能广播信号,让店员即刻了解到用户已经收集了哪些特价商品。</li> </ul> </div> </div> <p>通常,接收者能够从某个广播者那里收到的只有距离信息以及一个唯一的识别符。那么我们前面提到的&ldquo;发送病人的医疗数据信息&rdquo;又是怎么回事?</p> <p>接收者都是智能设备,从Beacon设备上接收到的广播信息后,完全可以触发接收者本身就已经具备的各种功能,例如联网、视频、游戏、GPS等。</p> <p>所以在前面提到的例子当中,病患身上的手机或可穿戴设备发送的Beacon信号本身无需(也不能)携带任何其他数据,急救车上的扫描设备接收到Beacon信号后,可以自主通过网络连接向储存着病人医疗信息的服务器发送请求,并下载相关的数据,供急救人员参考使用。</p> <h3> 切片2:代表</h3> <p>广播与接收这两种行为本身并不具备什么价值。只有当它们各自代表着背后的一些东西的时候,价值才会体现出来。</p> <p>说起Beacon系统,通常出现在我们脑海里的就是智能手机接收到某个固定地点播放的Beacon信号这个情景。其实我们完全可以扩大视野,就像前面提到的,Beacon信号源也可以被用户穿戴在身上,而某个固定地点中放置的计算设备则是信号的接收者。</p> <p>各种可能性都是有的。那么处在&ldquo;广播-接收&ldquo;这一通讯模式两端的设备各自代表着什么呢?</p> <h4> 人</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="09-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/09-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>移动或静止的(可穿戴、保留在身上、不被留意到的)。</p> <ul> <li> 智能手机</li> <li> 智能手表</li> <li> 智能眼镜</li> <li> 任何人们可以穿戴的智能设备</li> </ul> </div> </div> <h4> 物</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="10-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/10-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>移动或静止的(可以被放置或停放的)。</p> <ul> <li> 篮球</li> <li> 骑车</li> <li> 库存物品</li> <li> 测量血糖的仪器</li> </ul> </div> </div> <h4> 地区(中、小型)</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="11-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/11-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>非移动。</p> <ul> <li> 商场中的鞋帽区</li> <li> 会议室</li> <li> 酒店餐桌</li> <li> 小停车场</li> </ul> </div> </div> <h4> 地区(大、中型)</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="12-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/12-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>非移动(集群)。</p> <ul> <li> 购物中心</li> <li> 办公楼或办公区域</li> <li> 体育场或停车场</li> <li> 这些大中型地区中的Beacon集群里,每个单一的Beacon设备都代表着一个小型地区</li> </ul> </div> </div> <p>Beacon设备可以被独立或成组的部署。设想在一个繁忙的咖啡厅里,每个餐桌下都安装着一个Beacon设备。这种情境下,每个Beacon都代表一个餐桌,而全部Beacon设备组成的集群则代表着咖啡厅里的整个餐饮区。</p> <p>在这个情境中,用户无需排队,直接坐到桌前拿出手机打开应用就可以点餐。手机可以接收到桌下安装的Beacon设备发出的识别信号,通过网络连接发出订单信息后,咖啡厅的点餐系统就能知道哪个桌的客人点了哪些东西。</p> <h3> 切片3:用户情境</h3> <p>到目前为止,我们讨论的都是硬件设备在整个Beacon系统中扮演的角色。至于用户呢?</p> <p>他们会习惯把手机放在感应设备前进行一触式付款(touch-to-pay)吗?他们所要参与的交互行为符合他们的预期吗?</p> <p>换句话说,当Beacon系统内发生着人机互动时,用户的心智情境是怎样的?</p> <h4> 必要行动</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="13-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/13-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>&ldquo;我想要一个结果,我发起行动。&rdquo;</p> <ul> <li> 一触式付款、一触式登录、一触式下单。</li> <li> 博物馆的参观之旅:你一直把手机拿在手里,逛着一个又一个展馆,每到一处,收听推送过来的展馆音频介绍。</li> </ul> </div> </div> <h4> 预期发生</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="14-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/14-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>&ldquo;我想要一个结果,我不必发起行动。&rdquo;</p> <ul> <li> 订阅推送消息,以便对自己感兴趣的主题保持关注。</li> <li> 当你驾车外出时,家庭成员会收到推送消息。</li> <li> 离店时自动付款。</li> </ul> </div> </div> <h4> 被动</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="15-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/15-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>&ldquo;我没有想要一个结果,也不知道发生了怎样的互动。&rdquo;</p> <ul> <li> 统计分析</li> </ul> </div> </div> <h4> 惊喜</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="16-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/16-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <p>&ldquo;我没有想要一个结果,但是发生之后我知道背后产生了怎样的互动。&rdquo;</p> <ul> <li> 游戏化设计/奖励机制。</li> <li> 基于用户所处情境发送特定的优惠券。</li> <li> 当用户在卖场购物时,通过推送消息向他们推荐商品。</li> </ul> </div> </div> <p>这里所说的&ldquo;期待&rdquo;和&ldquo;知道&rdquo;,指的是用户在一个非常具体的交互时刻当中产生的感受。</p> <p>设想用户在隐私设置中允许你的应用接收Beacon信号并反馈位置信息,通常情况下,他们对数据交互这个事情还是会有感知的,但当他们在货架前溜达的时候,突然收到一张8折优惠券,惊喜的感觉仍然会有。</p> <p>用户通常不了解互动过程中的每一个细节,但他们通常会有广义上的感知。</p> <h3> 切片4:邻近响应</h3> <p>在发现附近的Beacon设备的同时,接收设备还可以读取具体的邻近数值。这个值可以显示出广播者与接收者之间的大致距离,并且每隔几毫秒就会刷新一次。</p> <p>这里有个问题:接收设备应该针对哪些类型的距离变化进行响应?</p> <p>在讨论这个问题之前,要做一点说明:因为在不同的情境中广播设备与接收设备的角色可能会互换,所以我们接下来统一使用&ldquo;Beacon设备&rdquo;一词来代表广播设备。</p> <h4> 接触</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="17-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/17-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 想象一下用户通过将手机与感应设备进行接触来付款,或将手机贴近Apple TV来登录自己的账户。</li> <li> 按照前面提到的用户情境来划分,&ldquo;接触&rdquo;属于典型的用户自主发起的&ldquo;必要行动&rdquo;。</li> </ul> </div> </div> <h4> 边界变化</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="18-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/18-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 想象一下用户从一个人为规定的较远的距离范围移动到较近的距离范围,例如在卖场里走进距离某专柜若干米的范围内,触发特定的事件。</li> <li> 如上面所说的例子,可以代表用户从一个较宽泛的关注范围移动到了一个他更加感兴趣的特定的主题范围。</li> <li> 不过需要考虑的是,如果用户只是从这片区域当中穿行过去呢?这还需要经由软件方面进行解释,例如判断用户特定范围内的停留时间再触发事件,等等。</li> </ul> </div> </div> <h4> 距离渐变</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="19-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/19-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 与&ldquo;边界变化&rdquo;类似,只是没有人为规定的距离范围等级。</li> <li> 仍以卖场为例,只通过用户与特定地点的距离增减来判断其兴趣及目标。</li> <li> 信号未必足够顺畅到能判断出平滑的渐变。</li> </ul> </div> </div> <h4> 多点定位</h4> <div class="group figure-content-wrapper"> <img class="figure" alt="20-beacon-interaction-ux-design-glossary.png" src="/sites/default/files/images/201405-2/20-beacon-interaction-ux-design-glossary.png" /></p> <div class="figure-content-content"> <ul> <li> 如果接收设备能同时读取多个Beacon设备发出的信号,那么精确定位就成为可能了。</li> <li> 可以想象成一种室内GPS技术。</li> <li> 不过这种模式也会受到信号噪音的影响,目前的发展还很不成熟。</li> </ul> </div> </div> <h3> 汇总到一起</h3> <p>如此将问题分割开来进行分析,你就可以从不同的维度上探索新的可能性。例如你想到了一种新的产品体验模式,那么可以试着将整体分割开,在不同的&ldquo;切片&rdquo;中尝试各种想法。</p> <p>你也可以把这种切片化的思路作为探索产品模式的起点,从每一个切片中挑选出一些对你来说有价值的点,然后将它们组合起来,作为新产品的基础。例如你可以以&ldquo;边界变化&rdquo;作为触发模式,以可穿戴设备与某种固定的物体作为接收者与广播者,帮助用户完成某种&ldquo;预期发生&rdquo;或&ldquo;惊喜&rdquo;事件。这种模式可以用于酒店房门及电力的自动激活,或是滑雪度假酒店向那些完成了15次斜坡滑行的客人免费提供一份午餐等等。</p> <h3> 补充</h3> <p>如果你觉得从技术角度来讲要部署一套Beacon系统完全不成问题,那么最好再从成本、效率和简单性等方面来审视一下。很多时候,围绕着Beacon平台来构建一整套服务是很说的通的,而有些时候则未必如此,哪怕技术再成熟。</p> <p>要时刻记得,在构建产品与服务体验的过程中,Beacon技术是一种补充性的选项,它所带来的并非创建某种&ldquo;新东西&rdquo;的能力,而是一种新的情境化触发机制,让我们的设备能够在更加恰当的时间与空间去做那些它们本来就有能力做的事情。</p> <div class="embed"><article id="node-285" class="node node-related-books" about="/node/285" typeof="sioc:Item foaf:Document"><section class="embed-article"><div class="embed-article-entry"><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><div> <div> <span class="thumbnail"><a href="http://www.amazon.cn/移动互联-用户体验设计指南-Rachel-Hinman/dp/B00DQH2LZQ/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23"><img alt="移动互联:用户体验设计指南" src="http://beforweb.com/sites/default/files/images/products/30.jpg" /></a></span> </div> <div class="content"> <h4><a href="http://www.amazon.cn/移动互联-用户体验设计指南-Rachel-Hinman/dp/B00DQH2LZQ/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">移动互联:用户体验设计指南</a></h4> <p><a href="http://www.amazon.cn/移动互联-用户体验设计指南-Rachel-Hinman/dp/B00DQH2LZQ/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">本书阐述如何设计出独一无二的移动体验,展示移动用户体验最重要的要素,介绍各种设计框架和实践。本书首先介绍移动用户体验的关键特点,接着介绍五种广泛使用的移动用户体验模式,然后介绍移动体验设计的设计实践、原型方法以及设计指南,最后讨论移动体验的前沿设计...</a></p> </div> </div> </div></div></div></div></section><span class="tag-title">相关书籍推荐</span></article></div> </div></div></div><ul class="field_categories"><li class="product taxonomy-term-reference-0"><a href="/product" typeof="skos:Concept" property="rdfs:label skos:prefLabel">产品</a></li><li class="design taxonomy-term-reference-1"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/165" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Beacon</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/166" typeof="skos:Concept" property="rdfs:label skos:prefLabel">iBeacon</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/24" typeof="skos:Concept" property="rdfs:label skos:prefLabel">移动应用</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-8" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Sun, 11 May 2014 07:03:05 +0000 C7210 485 at http://www.beforweb.com http://www.beforweb.com/node/485#comments 在正确的情境中向用户获取iOS权限 http://www.beforweb.com/node/468 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-context-permission-ios-ux-design.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>仔细想想,上周什么事情都没有发生,似也无从念叨;这不是最好的状态么?周五和老小伙伴们碰头聚会,吃香喝辣,谈天论地,确是痛快。</p> <p>说到吃,昨天剪好头发在家门口小店买了炸鸡排,这是一直以来的习惯。自从小理发馆换了老板,体验便一次不如一次;自从炸鸡店换了老板,鸡排便越来越难吃;又想到从前常叫的外卖譬如拉面馆的炒面啊大盘鸡啊还有西北馆的各种风味小吃或是每到夏天都会犯瘾的烧烤,全都不好吃起来。</p> <p>才一两年的时间,好的都变得不好了,这事儿让我想起《基地》,丹莫茨尔撺掇谢顿研究心理史学时反复强调的衰败衰败...我不觉得自己在生活的细节里过分敏感,感觉正在变坏的,确是在变坏;真讨厌。</p> <p>话说今天这篇文章,最近几日看到到处在转另外一版译文,相对浓缩一些,也挺好看的;我学我的,我做我的。文中阐述的思路和具体方法,值得各位设计伙思考与参考;&ldquo;术&rdquo;未必对所有的产品都适用,但&ldquo;道&rdquo;确是皆通一理。下面进入译文。</p> <p>Cluster是我设计过的第一个iOS原生应用,整个历程让我学习到了很多在过去的Web设计当中不曾考虑过的东西。在Web世界中,你通常只需要创建页面让用户浏览或使用,而在iOS上,除了引导用户下载并使用你的应用以外,你时常需要向他们索取各方面的权限,例如获取地理位置,或是访问通讯录、相机、照片等等。</p> <p>在设计Cluster的过程中,我们在很多细微却充满变数的交互环节里花了不少心思,以提升用户的满意度及信任感;其中&ldquo;怎样向用户索取权限&rdquo;就是我们关注的重点之一。</p> <!--break--><p>关于这一点,我们得出的结论可以概括为:</p> <ul> <li> 除非当前确实需要,否则不要向用户索取权限。</li> <li> 索取权限时要让用户明确的了解授权后的好处是什么。</li> </ul> <h3> 一次性成功获取权限的重要性</h3> <p>对很多应用来说,无法成功获取权限便意味着整体功能和体验的大打折扣。例如LBS类的应用,如果在索取权限时遭到用户的拒绝,那么该应用基本等同于无用了。另外,如果消息推送在你的应用当中扮演着微妙而重要的作用,能使用户保持习惯性的使用,那么获取权限时的失败或许会导致用户的流失。</p> <p>更坏的是,点击&ldquo;不允许&rdquo;是很轻松的,而要撤销这个决定则不太容易,用户至少需要以下五步才能打开授权,而且在应用内部很难为用户列出这些详细的步骤,更没法帮他们直接进入相关设置界面,用户只能靠自己去摸索。</p> <p><a class="lightbox" href="/sites/default/files/images/201404-3/01-app-access-ux-design-ui-user-experience.jpg" rel="lightbox"><img alt="01-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/01-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 242px;" /></a></p> <p class="figure-caption">1.退回到系统 2.进入设置 3.找到&ldquo;隐私&rdquo;设置项 4.进入&ldquo;照片&rdquo; 5.找到需要授权的应用并打开权限</p> <p>换句话说,如果用户第一次拒绝了授权,使应用无法正常使用,那么应用自身几乎没可能向用户解释怎样修复这一问题。所以我们要尽最大努力确保第一次向用户索取访问权限时用户能点击&ldquo;好&rdquo;。</p> <h3> 两种常见的设计模式</h3> <p>关于索取访问权限,我们通常会见到两种设计模式。</p> <h4> 初次加载时即刻索取(不推荐)</h4> <p>大家应该都见过这种模式。你下载好一个应用,初次打开,界面当中立刻跳出一个提示:&ldquo;我们可以给你推送消息吗?&rdquo;然后又是一个提示:&ldquo;我们可以访问你的相机吗?&rdquo;接着又是一个&ldquo;我们可以访问你的通讯录吗?&rdquo;</p> <p>除非用户很熟悉或信赖这款产品,否则他们更可能去点击&ldquo;不允许&rdquo;。这种方式和走在大街上随便拉一个人过来问&ldquo;你能和我约会吗?&rdquo;差不多。</p> <p>我们在第一版的Cluster里使用了这种方法,结果只有不到40%的用户会同意授权。</p> <h4> 让用户了解好处(次佳)</h4> <p>比起没头没脑的向用户索取权限,这种方式略好些,但有效性依然不高。</p> <p><a class="lightbox" href="/sites/default/files/images/201404-3/02-app-access-ux-design-ui-user-experience.jpg" rel="lightbox"><img alt="02-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/02-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 532px;" /></a></p> <p>如上图所示,HeyDay应用在索取权限时会在提示框中对授权之后能得到的好处进行说明。而且,他们是在功能介绍的最后一步向用户索取权限的,这使得用户在决定是否授权之前就已经对应用的功能有了大致的了解(假设用户确实会阅读功能介绍),从而更有可能通过授权。</p> <p>我们的Cluster在采用了这种方式之后,一次性通过授权的用户量从40%提升到了66%的样子。</p> <p>对于某些特定的应用,如果只能在以上两种方式当中进行选择,那么让用户在了解好处之后再决定是否授权,比单纯的提问要有效的多。</p> <h3> 我们的探索</h3> <p>我们持续探索着Cluster向用户索取权限的方式,并找到了两种方法,使权限对话框尽可能的在用户想要说&ldquo;好&rdquo;的时候才出现。</p> <h4> 预授权对话框</h4> <p>我们用到了一个小技巧,也就是在系统弹出授权对话框之前向用户展示我们自己创建的&ldquo;预授权&rdquo;对话框。</p> <p>正像前面所说的,用户在系统层面拒绝对应用授权是很糟的状况,因为要重新打开授权是很麻烦的。不过如果我们在系统级授权对话框之前预先询问,那么即使被用户拒绝,我们也仍然有一次机会能让他们说&ldquo;好&rdquo;。</p> <p>对于Cluster的照片访问授权来说,那些在&ldquo;预授权&rdquo;对话框里点击&ldquo;不允许&rdquo;的用户当中有46%会在接下来出现的系统级授权对话框中点击&ldquo;好&rdquo;。</p> <p>实现方式比你想象的要简单。你可以增加一个额外的iOS系统对话框,或设计一个定制化的界面,来实现&ldquo;预授权&rdquo;。</p> <h5> 1.iOS系统风格的预授权对话框</h5> <p>在较早的一个版本中,我们尝试了这种方式,也就是使用iOS系统风格的对话框询问用户两次;其中第一次的就是我们额外增加的&ldquo;预授权&rdquo;对话框:</p> <p><a class="lightbox" href="/sites/default/files/images/201404-3/03-app-access-ux-design-ui-user-experience.jpg" rel="lightbox"><img alt="03-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/03-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 355px;" /></a></p> <p>预授权对话框(上图中间的界面)会在应用第一次需要访问照片时弹出,其中的说明文字是&ldquo;这可以让你从相册中选择照片并添加到群里&rdquo;;两个按钮分别是&ldquo;现在不授权&rdquo;和&ldquo;给予授权&rdquo;。如果用户点击&ldquo;现在不授权&rdquo;,应用并不会将这个行为认作系统级的&ldquo;拒绝授权&rdquo;,而是会在将来需要的时候进行二次询问,其中,我们进一步向用户解释:&ldquo;Cluster只会上传和分享你所选中的照片&rdquo;。</p> <p>那些第一次匆匆忙忙拒绝授权的用户仍然有机会了解情况并改变决策;而根据统计,那些第一次点击了&ldquo;给予授权&rdquo;的用户当中只有3%会在第二次询问中点击&ldquo;不允许&rdquo;。</p> <p>虽然这种双重确认的模式看上去有些烦人,但至少对我们来说是相对有效的方式,让我们仍有可能获得那些第一次拒绝了授权的用户。而且根据我们的测试,没有一个被测用户在看到第二个对话框时表现出犹豫或迷茫。</p> <h5> 2.具有引导性的预授权浮层</h5> <p>在向用户索取通讯录访问权限的环节里,我们想给用户展示更多的说明信息,以确保更多的用户可以授权应用访问通讯录。这时系统的对话框就显得不够用了,另外灵活性也不足,于是我们设计了一个浮层:</p> <p><img alt="04-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/04-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 355px;" /></p> <p>用户决定邀请好友时,我们首先会通过这样一个浮层(如上图中间界面所示)给用户两个选择:一是从系统的通讯录中选择好友,一是手动输入对方的联系方式。我们让用户知道第一种方式更加便捷,但是需要授权;这能使用户尽可能充分的知情,对接下来将要发生的事情有所了解。那些选择了&ldquo;使用通讯录&rdquo;的用户在很大程度上已经是对情况有所了解并作出授权决定的,于是在接下来弹出的索取权限对话框中更有可能直接确认授权。</p> <p>和前面一种方式类似,双重询问的模式感觉是有些麻烦,但在这种情况下,用户可以更多的知情,几乎没有人会点击&ldquo;不允许&rdquo;。而且那些一开始选择了手动输入联系方式的用户仍然有退路可以重新选择使用通讯录。</p> <h4> 用户自己触发的权限对话框(最为成功的方式)</h4> <p>上面介绍的&ldquo;预授权&rdquo;模式,本质上讲,更多的是在减少用户不授权的可能;我们觉得这里依然有优化的空间。通过将问题进行解构,我们意识到,以上方式并没有改变&ldquo;用户不期望被索取权限&rdquo;的现实,所以我们继续探索,并尝试了一种让用户自己有意触发授权的方式。</p> <h5> 访问照片</h5> <p>过去的版本中,在Cluster创建新空间的第一步就是添加照片。这就意味着用户点击&ldquo;创建Cluster&rdquo;之后立刻会看到获取访问照片权限的提示。当时的统计数据是,67%的用户会给予授权。我们认为这一数字仍有提升空间。</p> <p><a class="lightbox" href="/sites/default/files/images/201404-3/05-app-access-ux-design-ui-user-experience.jpg" rel="lightbox"><img alt="05-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/05-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 355px;" /></a></p> <p>我们决定将上传照片的环节向后推迟几步,直到用户首先理解了Cluster推崇的概念到底是什么,能怎样玩儿,然后由他们自己主动产生尝试的欲望,并点击相机图标,接着是&ldquo;选择照片&rdquo;,此时再提出获取权限的请求。</p> <p>这一改变使获取照片权限的通过率从67%上升至<strong>89%</strong>。</p> <p>因为在这个时候,用户已经有意去上传照片了,给予应用访问照片的权限是再自然不过的事情了。</p> <h5> 访问通讯录</h5> <p>我们曾经问过自己,<strong>如果用户同意应用访问他们的通讯录,那么他们能得到的最大的好处是什么</strong>?在曾经使用过的&ldquo;预授权&rdquo;模式当中,我们允许用户手动输入想要邀请的朋友的联系方式,并希望藉此来促使他们选择&ldquo;使用通讯录&rdquo;的方式,同时授权应用访问手机通讯录。这种方式的思路是对的,但问题在于,在用户进行选择之前,他们是无法感觉到手动模式的&ldquo;痛苦&rdquo;的,相应的也就难以看到授权访问通讯录的甜头。</p> <p><a class="lightbox" href="/sites/default/files/images/201404-3/06-app-access-ux-design-ui-user-experience.jpg" rel="lightbox"><img alt="06-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/06-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 355px;" /></a></p> <p>最终,我们决定在添加朋友的环节中默认使用手动输入的模式,首先让用户尝到一点点&ldquo;苦头&rdquo;,让他们感受到在无法访问通讯录的情况下添加联系人有多空洞。当用户手动输入联系人名字的时候,会发现没有任何查询结果,同时看到&ldquo;从iPhone通讯录中匹配结果&rdquo;的选项。这时,用户便会更加主动的去点击这一选项;接下来,我们便向他们索取访问通讯录的权限。</p> <p>这一改变使获取通讯录权限的通过率达到了<strong>100%</strong>。</p> <h5> 推送消息</h5> <p>Cluster这款应用可以帮助用户在自己的朋友圈子里创建小私密空间。我们再次问自己,<strong>推送消息可以给用户带来的最大价值是什么</strong>?答案是让用户了解他们的朋友在小空间当中的动态。</p> <p><a class="lightbox" href="/sites/default/files/images/201404-3/07-app-access-ux-design-ui-user-experience.jpg" rel="lightbox"><img alt="07-app-access-ux-design-ui-user-experience.jpg" src="/sites/default/files/images/201404-3/07-app-access-ux-design-ui-user-experience.jpg" style="width: 600px; height: 355px;" /></a></p> <p>当用户第一次创建了私密空间,并邀请了一些朋友,我们会问他们一个非常符合当时逻辑的问题:&ldquo;是否希望在他们接受邀请加入空间后通过消息提示到你?&rdquo;如果用户选择&ldquo;提示我&rdquo;,那么索取推送信息权限的对话框就会呈现,如果他们选择&ldquo;不用,谢了&rdquo;,我们就会跳过这一步。</p> <p>这里的数据和前面一样:<strong>100%</strong>的用户在点击&ldquo;提示我&rdquo;之后会选择授权。</p> <h3> 我们所学到的:情境至关重要</h3> <p>当然,每个应用都各有不同,但是道理是相通的:要顺利的获取用户授权,你必须用心考虑在哪些时候、怎样的情境下,用户会真的<strong>需要</strong>应用从他们的手机中获取数据;你要确保在正确的环节当中使用户期望自己被问到,期望应用能想其所想<a class="eLink" href="http://beforweb.com">。</a></p> <p>推荐阅读:<a href="http://www.beforweb.com/node/407">情境,一切在于情境</a></p> <div class="embed"><article id="node-263" class="node node-related-books" about="/node/263" typeof="sioc:Item foaf:Document"><section class="embed-article"><div class="embed-article-entry"><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><div> <div> <span class="thumbnail"><a href="http://www.amazon.cn/移动应用UI设计模式-尼尔/dp/B00AMAI1AO/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;qid=1380852787&amp;tag=c7210-23"><img alt="移动应用UI设计模式" src="http://beforweb.com/sites/default/files/images/products/07.jpg" /></a></span></div> <div class="content"> <h4> <a href="http://www.amazon.cn/移动应用UI设计模式-尼尔/dp/B00AMAI1AO/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;qid=1380852787&amp;tag=c7210-23">移动应用UI设计模式</a></h4> <p><a href="http://www.amazon.cn/移动应用UI设计模式-尼尔/dp/B00AMAI1AO/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;qid=1380852787&amp;tag=c7210-23">这是一本移动应用UI设计模式参考书,分10大类介绍了70个移动应用设计模式(包括反模式),用400多个屏幕截图和图解帮助读者理解和利用UI设计模式,以解决常见的设计难题,同时提供了&ldquo;即学即用&rdquo;式的技巧和经验...</a></p> </div> </div> <p>&nbsp;</p> </div></div></div></div></section><span class="tag-title">相关书籍推荐</span></article></div> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/24" typeof="skos:Concept" property="rdfs:label skos:prefLabel">移动应用</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/48" typeof="skos:Concept" property="rdfs:label skos:prefLabel">iOS</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Sun, 13 Apr 2014 03:44:05 +0000 C7210 468 at http://www.beforweb.com http://www.beforweb.com/node/468#comments 情境,一切在于情境 http://www.beforweb.com/node/407 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-mobile-app-context-ux-ui-design-experience.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>上周买了辆新自行车,轻轻的快快的,每天趁有太阳的时候出去骑一骑,心情舒畅;只是外面太脏了,路上灰灰的,所以今天又买了口罩。话说口罩前面做个拉链就好了,拉开就可以抽烟,不需要摘下来。</p> <p>待业假期过半,还剩一周,该看的书还没看完,倒是把Quake4又通关了一遍...难得玩玩游戏,也就原谅自己了...其余很多时间又被Slam Dunk的动画片占据了(现在就在看)...其实从来都不太喜欢动画版,太拖沓;96、97年那时花了蛮多零花钱到处搜刮终于攒齐了一整套书,当时的引进版叫做《篮球飞人》诶;后来被叫做灌篮高手了,矫情。记得买的第一本就是三井回来砸馆子那集,激动啊,看着那么多人一起打架...</p> <p>那,不说闲话了,趁天气好,进入本周正文时间。下面开始译文。</p> <p>不久的将来,我们设计的每一样东西都会与情境有关。</p> <p>如今,广告商比Web/App设计师们更明白一件事:情境。广告商必须对情境敏感,才能知道在什么时候以什么方式展示广告。他们有人专门负责判断在何时何地展示内容,因为他们知道,如果没有情境,广告就没有任何价值:在关于石油泄漏的纪录片当中插播油气公司的广告,或是在关于PETA(善待动物组织)的故事中播放培根广告,这些都是浪费广告预算的典型例子。</p> <!--break--><p>在这个随时随地多屏幕在线的时代,&ldquo;情境&rdquo;正变得比以往更加重要。过去,我们被拴在书桌前;如今,我们可以随时随地访问互联网。不过,令人惊讶的是,互联网的创建者们直到最近才发现一种规格的内容是难以适配所有平台的。我们迈出的第一步就是对付各种屏幕尺寸,力求使内容像水一样可以被灌入各类容器;耳熟能详的响应式设计便是其中的方式之一。但事情远不止&ldquo;尺寸&rdquo;这么简单。</p> <p>对于移动应用和移动化网站来说,情境化界面设计的真正核心在于基于地点、时间和事件状况的设计&mdash;&mdash;在用户需要的时候,主动通过最恰当的界面形式展示最恰当的数据内容,而无需强迫用户发起相关的请求。在最理想的情况下,情境化设计对用户来说是无形的,因为界面可以随时随地、在任何状况下都能从容的帮助用户获取信息、完成目标。</p> <h3> 实践启发</h3> <h4> 声音</h4> <p>声音其实是我们可以深入挖掘的一个重要的情境化元素,而我们在多数时候总会忽略它的存在。举个简单的例子:在民航方面,机场或航班会使用很多声音线索来提醒旅客对事件或状态进行关注,譬如机舱里那些&ldquo;叮叮&rdquo;的提示音。也许可以试着让智能移动设备监听这种特定的声音,并使设备自动进入飞行模式,或是关机。</p> <p><img alt="01-s-facebook-like-mobile-app-ux-design-context.jpg" src="/sites/default/files/images/201403-2/01-s-facebook-like-mobile-app-ux-design-context.jpg" style="width: 320px; height: 137px;" /></p> <h4> 起居室</h4> <p>起居室是有待我们去征服的下一个数字化空间。众多公司已经开始这方面的研究,而其中Intel更是走在前列。他们正在测试一种遥控器的原型,该遥控器可以识别出正在拿着它的人是谁,并根据已知的用户信息在电视中提供相应的节目推荐。想象一下,当小朋友拿起遥控器时,电视屏幕中会出现卡通或是学习节目的推荐,而当他们的老爸拿起遥控器时,体育类的节目便取而代之。</p> <p>将诸如此类的概念与传说中的iTV结合起来,我们就可以看到各种可能性正在前方等待我们去探索。例如,我们可以在电视节目、电影或是广告当中植入某种&ldquo;音频水印&rdquo;,当我们手中的智能设备监听到这些水印时,某个特定的应用或网站就会自动开启并呈现与电视上的内容相关的信息。</p> <h4> 地点,地点,地点</h4> <p>星巴克与Square的合作是一个典型的情境化设计商业案例。用户最终将可以通过移动设备来点一杯拿铁,并直接使用关联在App当中的信用卡付账,到门店报上自己的名字,拎着拿铁走人&mdash;&mdash;如此简单而令人兴奋。</p> <p><img alt="02-facebook-like-mobile-app-ux-design-context.jpg" src="/sites/default/files/images/201403-2/02-facebook-like-mobile-app-ux-design-context.jpg" style="width: 500px; height: 261px;" /></p> <p>苹果的Passbook则可以帮助众多第三方公司创建自己的票券,并将所有的票券集中在同一个地方。最棒的一点就是Passbook可以与用户所处的情景关联起来。以电影票为例,当你在电影即将开场时走进影院,便会立刻收到一条提示,电影票的信息就包含在其中。你不用再到某个应用中匆忙的寻找自己购买的电影票,只要人在特定的情境中,设备便会帮你搞定一切。</p> <p><img alt="03-facebook-like-mobile-app-ux-design-context.png" src="/sites/default/files/images/201403-2/03-facebook-like-mobile-app-ux-design-context.png" style="width: 320px; height: 568px;" /></p> <h4> 社会化</h4> <p>&ldquo;Facebook Like&rdquo;衣架是社会化情境的典型案例。这是C&amp;A(著名时装零售品牌)在巴西推出的一款&ldquo;高科技&rdquo;衣架,上面的小屏幕会显示该服饰在Facebook上有多少人点过赞,顾客可以清楚的了解服装的受欢迎程度,作为购买决策的辅助参考。</p> <p><img alt="05-s-facebook-like-mobile-app-ux-design-context.jpg" src="/sites/default/files/images/201403-2/05-s-facebook-like-mobile-app-ux-design-context.jpg" style="height: 329px; width: 500px;" /></p> <h4> 日历</h4> <p>设想一下,用户的日历当中显示明天有朋友的生日事件。当该用户走进某商店选购礼品时,手机会根据日历中的生日事件自动提出礼品购买建议,并提供打折&mdash;&mdash;将时间情境与空间情境结合起来,又酷又贴心。</p> <p><img alt="04-birthday-mobile-app-ux-design-context.png" src="/sites/default/files/images/201403-2/04-birthday-mobile-app-ux-design-context.png" style="width: 320px; height: 567px;" /></p> <h4> 设备生态圈</h4> <p>IPv6极大的提升了互联网能够支持的设备地址容量。本质上讲,所有东西都可以连接到互联网上,并输出相关信息&mdash;&mdash;除了我们所熟悉的数码设备以外,任何实际物体都可以做到这一点。设想一个&ldquo;智能啤酒杯&rdquo;,它可以探测到里面装着的啤酒类型,是否接近空杯状态,等等。这种事情听上去有点极端和遥远,不过事实上真的没有我们想象的那么遥不可及。</p> <h3> &ldquo;恰到好处&rdquo;的体验</h3> <p>&ldquo;金发姑娘原则&rdquo;同样适用于情境化设计:凡事必有度,宜&ldquo;恰到好处&rdquo;。为了情境化而一味的从界面中移除内容,你有可能是在&ldquo;抢劫&rdquo;用户的信息&mdash;&mdash;如果不想显示某些内容,你最好有足够强大而恰当的理由。</p> <p>另外还有一些很常见的设计陷阱值得注意。例如,&ldquo;移动设备的网速较低&rdquo;这种说法未必在任何时候都正确;此外,各种不同的情境对用户注意力的分散程度也有所不同,这些因素都是在进行情境化设计的过程中需要考虑到的。(相关阅读:<a href="http://www.beforweb.com/node/180">关于移动应用的上下文情境</a>)</p> <p>情境化设计给产品带来的灵活性更多的是体现在体验模式的细微变化和调整当中,不要一味的将其理解为界面或交互模式的彻头彻尾的变化。细节中的灵活性是很重要的,例如,在iOS6中,用户可以为短信和来电设置&ldquo;勿扰模式&rdquo;。但是,如果确实有事态很紧急的电话打进来该怎办?设计师们考虑到了这种可能性,并给出了相应的方案:如果某人连续多次拨打该电话,则通话将允许被接入,而忽略掉&ldquo;勿扰模式&rdquo;的限制。</p> <h3> 小结</h3> <p>人们与设备的交互方式在最近几年当中发生了巨大的变化,而&ldquo;情境&rdquo;的概念则在有形无形当中为这场变革打着头阵。芯片的尺寸变得越来越小,价格也越发低廉,我们将能在生活各处见到越来越多的联网设备,基于不同的使用情境,它们能接受的输入类型也各有差异。</p> <p>要做出优秀的产品设计,一个根本前提是对目标用户有着深层次的研究与认知,包括理解他们的需求目标所基于的典型情境。情境化设计的关键并非随着设备或使用情境的不同而增减内容,而在于根据不同的情境渐进式的调整体验模式。要认真分析对于用户的研究数据,针对产品可能面对的各种特定的情境来规划最恰当的功能/内容呈现方式,充分利用智能设备的硬件技术作为不同情境下的输入模式,使用户在特定的时间和地点无需自己动手便能接收到合适的信息,完成特定情境下的需求目标。</p> <div class="embed"><article id="node-285" class="node node-related-books" about="/node/285" typeof="sioc:Item foaf:Document"><section class="embed-article"><div class="embed-article-entry"><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><div> <div> <span class="thumbnail"><a href="http://www.amazon.cn/移动互联-用户体验设计指南-Rachel-Hinman/dp/B00DQH2LZQ/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23"><img alt="移动互联:用户体验设计指南" src="http://beforweb.com/sites/default/files/images/products/30.jpg" /></a></span> </div> <div class="content"> <h4><a href="http://www.amazon.cn/移动互联-用户体验设计指南-Rachel-Hinman/dp/B00DQH2LZQ/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">移动互联:用户体验设计指南</a></h4> <p><a href="http://www.amazon.cn/移动互联-用户体验设计指南-Rachel-Hinman/dp/B00DQH2LZQ/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">本书阐述如何设计出独一无二的移动体验,展示移动用户体验最重要的要素,介绍各种设计框架和实践。本书首先介绍移动用户体验的关键特点,接着介绍五种广泛使用的移动用户体验模式,然后介绍移动体验设计的设计实践、原型方法以及设计指南,最后讨论移动体验的前沿设计...</a></p> </div> </div> </div></div></div></div></section><span class="tag-title">相关书籍推荐</span></article></div> </div></div></div><ul class="field_categories"><li class="product taxonomy-term-reference-0"><a href="/product" typeof="skos:Concept" property="rdfs:label skos:prefLabel">产品</a></li><li class="design taxonomy-term-reference-1"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/54" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户研究</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Sun, 16 Mar 2014 08:38:18 +0000 C7210 407 at http://www.beforweb.com http://www.beforweb.com/node/407#comments 移动应用可用性测试的实践经验总结 http://www.beforweb.com/node/188 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-mobile-app-ux-design-usability-test.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>印象里,似乎最近地震的消息蛮多的,世界各地;前面一周的天气也是大起大落的赶脚,很热接下去又很冷。</p> <p>我很高兴自己接下来可以投入一个绝对以移动产品为主的工作当中了,终于。这事儿可是真心盼了好久,却始终因为各种原因无法实现。那么,在这里感谢所有有意无意帮助我走进这个阶段的人吧,无论你们是否可以看到。对我来说,每年的春天总会或多或少或大或小的发生些能够让自己记住很久的事情,今年在工作上的进化算是不错的一笔。</p> <p>不多念叨了,进入本周译文。我个人觉得很受益的一篇文章,作者总结了自己过去几年中在移动产品可用性测试的工作里获取的一些实践经验,或是说小贴士小方法,值得借鉴。走起。</p> <p>这里进入译文。如果你不大熟悉移动应用的可用性测试,没关系,这事儿没你想象的那么困难;不过移动应用与传统网站产品在可用性测试方面确实有一些关键的区别需要我们注意。</p> <p>过去的几年当中,我(英文原文作者)为不少移动产品做过测试,从戒烟应用到移动版的车辆保险网站,其中既包括在实验室使用复杂设备进行的测试,也包括在各种实境化的条件下进行的非正式测试。在本文中,我将为各位分享一些经验心得,希望能帮诸位在实际工作中节约时间,提升效率。</p> <!--break--><h3> 1.关于纸质原型测试</h3> <p>我很喜欢Frank Lloyd Wright的一句话:&ldquo;修改草稿只需要橡皮,修改实际产品则需要大锤&rdquo;。在产品初期通过纸质原型与用户进行沟通是一件事半功倍的事情,不过如果待测产品的界面需要滚屏的话,应该怎样处理呢?</p> <p>将一张包含若干屏界面元素的纸质原型一股脑展示给用户的话,很难达到良好的测试效果。可以试着用硬纸板制作一个手机模板,如下图所示,在屏幕上下两端各开一道缝隙,将长界面原型插入到模板当中。这样就可以模拟用户在实际设备上所看到的可视区域了。</p> <p><img alt="01-s-mobile-paper-prototype-app-product-ux-design-interface-usability-test.jpg" src="/sites/default/files/images/201304-2/01-s-mobile-paper-prototype-app-product-ux-design-interface-usability-test.jpg" /></p> <h3> 2.屏幕录制软件的局限</h3> <p>用于智能移动设备的屏幕录制软件在可用性测试中是很有价值的,而且它们通常不会干扰用户的操作。不过苹果对这类应用的审查十分严格,例如Display Recorder这样的产品只有通过Cydia才可以使用,但我个人并不希望为了做测试而越狱。安卓当中倒是有一些可用的屏幕录制软件,不过其中的一些缺点也是蛮明显的:</p> <ul> <li> 屏幕录制软件无法记录手势操作,例如用户为了点击一个微小的按钮而连着点了十多次屏幕,或是在界面上进行滑动操作等等。</li> <li> 这类软件在性能和资源占用量等方面具有一定的局限性,很难支持连续一个小时以上的测试流程。</li> <li> 这类软件在一次录制过程中通常只能支持一个应用当中的行为记录。</li> <li> 必须使用安装了这类软件的测试机进行测试,灵活性有限。</li> <li> 这些软件通常无法与Morae一类的可用性测试工具整合使用,场外观察者不能看到即时的记录影像。</li> <li> 无法借助这类软件录制用户的面部表情或口头表述。</li> </ul> <p>据我所知,有两款iOS应用可以比较好的解决其中的一部分问题。一个是<a href="http://www.uxrecorder.com">UX Recorder</a>,这款应用不仅可以记录屏幕上的各种行为,而且可以捕捉用户的手势(圆圈表示点击,箭头表示滑动扫屏等),同时还能通过前置摄像头及麦克风记录用户的表情和语音。不过最大的问题在于,这个软件只能用来在浏览器中对移动网站进行测试,不能用在原生应用上。</p> <p>另外一款应用是<a href="http://magitest.com">Magitest</a>,在我看来比UX Recorder更有用些,它不仅可以记录界面行为、用户手势(目前只支持点击,我相信他们未来会支持更多手势操作)、用户表情及语音,最重要的是,Magitest提供了一个开发包,只要开发人员将相关代码加入待测产品的原型当中,我们就可以为原生应用进行测试了。</p> <p><img alt="02-Screen-Recorder-ScreenShots-app-product-ux-design-interface-usability-test.jpg" src="/sites/default/files/images/201304-2/02-Screen-Recorder-ScreenShots-app-product-ux-design-interface-usability-test.jpg" /></p> <h3> 3.使用&ldquo;雪橇&rdquo;</h3> <p>除了使用屏幕录制软件记录用户行为之外,我们还可以采用一种更直接和有效的方案,即&ldquo;雪橇&rdquo;设备,也就是将智能手机或平板电脑放在一个挂着摄像头的支架上,供用户进行测试;这种设备的外形很像雪橇。</p> <p><img alt="03-sled-app-product-ux-design-interface-usability-test.jpg" src="/sites/default/files/images/201304-2/03-sled-app-product-ux-design-interface-usability-test.jpg" /></p> <p>这种方式可以全面的记录用户的实际操作,无论是界面上发生的一切还是用户执行的手势操作都可以尽收眼底,而且雪橇上的外置摄像头可以直接与桌面设备上的测试、观察软件整合使用,譬如Morae,它可以同时支持两个摄像头输入,一个挂在雪橇上,一个用于记录用户的表情,使场外观察员能够即时的看到全部测试过程。</p> <p><img alt="04-Morae-Mobile-Test-Output-app-product-ux-design-interface-usability-test.jpg" src="/sites/default/files/images/201304-2/04-Morae-Mobile-Test-Output-app-product-ux-design-interface-usability-test.jpg" /></p> <p>很多设计师都使用他们<a href="http://www.90percentofeverything.com/2010/05/07/quick-tip-make-your-own-iphone-usability-testing-sled-for-5/">自制的雪橇设备</a>进行测试,我自己也是如此。这其中有几点需要注意:</p> <ul> <li> 雪橇必须足够轻巧,使用户可以连同移动设备一起拿在手中进行测试。</li> <li> 不能让雪橇遮挡住设备屏幕,干扰用户测试。</li> <li> 雪橇的尺寸规格应该能够适应多种主流设备,便于用户通过自己的手机进行测试。最理想做法的是使雪橇外形和尺寸可调节。</li> <li> 雪橇的造型应该允许用户调转设备的屏幕方向。</li> <li> 雪橇整体应该足够稳固。</li> </ul> <h3> 4.外置摄像头的选取</h3> <p>最初,我们在DIY的雪橇上使用了罗技的两款摄像头,C910和C615。这两款摄像头的影像质量不错,解析度很高,可以和Morae测试软件很好的整合使用。不过最大的弊病在于这两款摄像头的尺寸过大,而且C910要安装在雪橇上也不是很容易。</p> <p><img alt="05-logitech-hd-webcam-c910-app-product-ux-design-interface-usability-test.jpg" src="/sites/default/files/images/201304-2/05-logitech-hd-webcam-c910-app-product-ux-design-interface-usability-test.jpg" /></p> <p>我们试过的另外一款摄像头是微软的Lifecam,分辨率有720p,可以和Morae整合,同时便于安装在雪橇上。不过弊端还是尺寸与重量的问题,另外其原生的录制软件也很难用。</p> <p>除了传统的网络摄像头外,我们还尝试了IPevo的文档摄像头。它最让我们喜欢的地方在于足够轻巧,拥有很高的分辨率,可以和桌面软件良好的整合,而且本身就带有一个很灵活的塑料支架。不过缺点也很明显,它很难安装在雪橇上,而且每秒的帧数太低,毕竟它本是用于拍摄文档的。</p> <p>我们最终选用的是Hue的高清网络摄像头,它很轻巧,分辨率不错,每秒帧数也足够,本身带有一个可调节的软管支架,可以直接与台式设备连接使用,另外可选的颜色也很多。不过为了避免用户的注意力被过多的吸引,我们还是选择了黑色的。</p> <h3> 5.不该使用技术设备的时候</h3> <p>之前几点实践经验都是聚焦在技术方面的,不过在某些时候我们还是要提倡远离技术设备的(手机和平板除外)。前面提到了,我们最近测试了一款专为孕妇设计的戒烟应用,为此我们招募了一批已经生了小宝宝的年轻妈妈来参与测试。这次的情况比较敏感,我们需要到这些用户的家中进行测试,而不是请她们来实验室。</p> <p>为了营造和谐融洽的氛围,使这些用户更愿意进行交流和表达,我尽量让整个测试过程显得轻松随意。其中一次测试甚至是在沙发上进行的,对方一手抱着她5个月大的孩子喂着奶,一手操作iPhone进行测试。这种情况下显然不适合使用任何影像设备进行录制,其他技术设备也很有可能在这种生活化的测试环境中造成干扰。</p> <h3> 6.考虑使用情境</h3> <p>我们都知道移动情境对于应用设计的重要性,但这其中的重要程度也会根据不同类型的产品而存在差异。<a href="http://www.smartinsights.com/marketplace-analysis/customer-analysis/new-free-worldwide-digital-media-statistics-reports-starting-with-uk-us-and-europe/">来自comScore的统计</a>表明,人们使用移动互联网最为频繁的时候是早上和晚上8点之后,这些时候人们通常是在家中的。</p> <p>我们需要认真考虑自己产品的目标用户通常是在怎样的情境中使用产品。举个例子,孕妇戒烟应用的很多目标用户都提到,她们平时主要是在独自呆在家中、手机就在手边的时候使用这款应用。而对于我们参与过的一个旅行类应用来说,目标用户则会更多的在真正的移动情境中使用产品。对于具体产品的使用情境的理解将有助于我们更有针对性的进行可用性测试。</p> <p>推荐阅读:</p> <ul> <li> <a href="http://beforweb.com/node/180">关于移动应用的上下文情境</a></li> <li> <a href="http://beforweb.com/node/25">移动设备上网时间的统计分析</a></li> </ul> <h3> 7.模拟用户的使用情境和周边环境</h3> <p>在实验室中,我们通常都能得到稳定的无线网络连接,环境当中也不存在什么干扰因素,但是在实际生活中,这样的环境并不多。人们会在各种情境下使用应用,例如火车上、公交车上、排队过程中等等。在这些情境中,网络连接不会一直保持稳定,用户可能随时拿出设备使用产品,而交互流程也会随时会被打断。</p> <p>保险界的一个客户曾经希望我们对用户在失去网络信号或离开当前会话的30分钟之后再继续操作时的心理预期进行研究。在可用性测试的过程中,我要求用户&ldquo;设想一下你现在正在火车上使用这个产品,穿越隧道时没有网络信号了。&rdquo; 然后我问他们在这种情况下他们希望产品在接下来应该怎样表现。通过这种简单的假设,我们可以在一定程度上使用户进入一种实际情境的模拟状态。</p> <p>在我们测试戒烟应用的时候,有一部分用户提出希望来到我们的实验室来做测试。我们决定按照用户的要求来进行,不过为了使环境尽量贴近于&ldquo;家&rdquo;的感觉,我们决定直接在观察室的沙发上进行测试和交流,而不是使用到处都是设备的实验室。虽然这并非用户的实际使用环境,不过比起实验室来说,更接近于家庭环境的空间所带来的测试结果可以更有效。</p> <h3> 8.使用用户自己的设备,发现更多问题</h3> <p>在我们测试移动版的车辆保险网站的时候,我们发现Galaxy和iPhone用户喜欢通过日期选择器的方式完成日期的输入,但是一位HTC的用户却在使用日期选择器输入年份的过程中遇到了很大麻烦。年份的选项太多,导致反应迟钝,用户在滑拨的时候一下子就将整个界面滚动起来。</p> <p>在测试旅游计划应用的时候,我们让用户使用自己的设备进行操作,发现其网络连接和部分界面反应速度确实很慢。这类问题在使用我们的测试机进行测试的过程中是很难发现的,其中有些问题在发现之后确实是可以进行改善的。</p> <h3> 总结</h3> <p>围绕移动设备进行的用户体验设计早已不是一小撮UX人所进行的小领域工作了,无论设计过程本身,还是诸如可用性测试这样的上下游相关工作环节,都需要我们投入更多的精力去思考和对待。</p> <p>本文提到的这些经验都是从我个人的工作过程中总结归纳出来的,希望能为大家提供一些参考价值,少走些我所走过的弯路。</p> <div class="embed"><article id="node-289" class="node node-related-books" about="/node/289" typeof="sioc:Item foaf:Document"><section class="embed-article"><div class="embed-article-entry"><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><div> <div> <span class="thumbnail"><a href="http://www.amazon.cn/妙手回春-网站可用性测试及优化指南-克鲁格/dp/B003XM3TF0/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23"><img alt="妙手回春:网站可用性测试及优化指南" src="http://beforweb.com/sites/default/files/images/products/34.jpg" /></a></span> </div> <div class="content"> <h4><a href="http://www.amazon.cn/妙手回春-网站可用性测试及优化指南-克鲁格/dp/B003XM3TF0/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">妙手回春:网站可用性测试及优化指南</a></h4> <p><a href="http://www.amazon.cn/妙手回春-网站可用性测试及优化指南-克鲁格/dp/B003XM3TF0/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">作者Steve Krug继畅销书Don't Make Me Think后推出的又一力作。书中详细阐述了一种简化的网站可用性测试方法,让任何人都能够尽早并频繁地对其网站、应用程序和其他产品进行可用性测试,从而将最严重的可用性问题消灭在萌芽状态...</a></p> </div> </div> </div></div></div></div></section><span class="tag-title">相关书籍推荐</span></article></div> </div></div></div><ul class="field_categories"><li class="design taxonomy-term-reference-0"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/24" typeof="skos:Concept" property="rdfs:label skos:prefLabel">移动应用</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/37" typeof="skos:Concept" property="rdfs:label skos:prefLabel">可用性测试</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/64" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原型</a></li><li class=" taxonomy-term-reference-8" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Sun, 21 Apr 2013 03:31:31 +0000 C7210 188 at http://www.beforweb.com http://www.beforweb.com/node/188#comments 关于移动应用的上下文情境 http://www.beforweb.com/node/180 <div class="field field-name-field-article-thumb field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img typeof="foaf:Image" src="http://www.beforweb.com/sites/default/files/article-thumbs/icon-logo-wifi-mobile-app-context-user-experience-ux-design.png" width="70" height="70" /></div></div></div><div id="comment-wrapper"></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>印象里每逢春天便会生病的样子,这是一种怎样的精神?10年前非典期间相当给力的高烧与咳嗽,如今恰逢H7N9,又开始疑似起来。就这样我还有心思跟这打字呢?</p> <p>在很难受的时候,却开开心心的把石康的《晃晃悠悠》又读了一遍,顺便又想到并怀念了一通自己的大学岁月。上次看还是高中的时候呢,十二、三年之后再读起来,确实是另外一番感受。说正经的吧,本周小译文一篇在下面,属于闲来无事可以瞧两眼琢磨琢磨的那种,走着呗。</p> <p>这里进入译文。要打造终极完美的体验是不可能的,因为每个用户都会以不同的方式使用产品,其中涉及到的因素有方方面面,包括文化、社会环境、个人品味、目标动机等等。</p> <p>虽然这些因素使得我们难以精确的了解不同的用户在使用产品的过程中产生了怎样的体验,不过,对移动应用上下文情境的研究可以帮助我们对这些因素进行梳理,以便尽可能全面深入的了解用户,有针对性的打造产品的体验模式。</p> <!--break--><h3> 三种情境</h3> <p>在实际设计与开发一款产品之前,充分的研究工作是非常必要的,我们至少需要对产品最核心的那个目标用户群有所认知。这项工作不需要进行的很复杂,有时候一支笔、一张纸,外加一些常识就足够了。</p> <p>对上下文使用情境的研究特别有助于在前期预计产品投放到市场后会遇到的一些陷阱和潜在问题。上下文情境分为三类:</p> <ul> <li> <strong>物理情境</strong>:用户在使用产品时所处的物理环境。</li> <li> <strong>技术情境</strong>:会对用户理解与使用产品产生影响作用的技术因素,包括移动应用自身的设计,以及产品所处的系统平台、硬件设备等等。</li> <li> <strong>社会情境</strong>:对产品的推广传播起到推动作用的互联网社会属性。</li> </ul> <p><img alt="01-c2-context-circles-mobile-app-ux-design-user-research" src="/sites/default/files/images/201304-1/01-c2-context-circles-mobile-app-ux-design-user-research" style="width: 600px; height: 300px;" /></p> <h3> 物理情境</h3> <p>作为产品的设计与开发者,我们通常会将注意力过多的集中在产品本身上,从而忽视了很多会影响用户体验的外在因素。了解用户、提升体验的第一步就是要明白目标用户是怎样使用产品的。他们在怎样的环境中使用你的应用,在家还是路途中?使用的时候是否会处于匆忙的状态下?是否时常有外部因素会导致使用过程被中断?</p> <p><img alt="02-c-physical-circles-mobile-app-ux-design-user-research" src="/sites/default/files/images/201304-1/02-c-physical-circles-mobile-app-ux-design-user-research" style="width: 600px; height: 300px;" /></p> <p>让我们说的具体一些,比如当你正在手机上玩游戏时,很有可能是因为在等车而打发无聊时间。玩游戏的过程随时都会被打断,例如车来了,你必须上车;这时游戏的体验就中断了。当你在车上坐定之后,又会拿出手机继续之前的游戏,此时你显然希望可以从之前中断的地方继续玩下去。对于这款游戏产品来说,暂停按钮或是退出时自动保存进程的功能就是必需。</p> <p>通过创建这样的情境剧本,你可以比较清晰的预见到产品在实际使用当中有可能遇到的问题。</p> <p>我们可以从两个方面来分析产品所处的物理情境:一是<strong>环境背景</strong>,例如户内或户外、背景噪音、光照强度等,二是人的<strong>行为状态</strong>,例如行走、驾车、站立等待、下厨、购物等。结合用户的核心目标与需求,分析他们通常会在怎样的环境背景与行为状态下使用产品,你将发现很多有可能影响产品体验的外在因素,并在设计过程中有针对性的进行解决或规避。</p> <p>下面我们将物理情境方面的问题汇总一下:</p> <ul> <li> 用户通常会在怎样的地理环境使用你的应用?</li> <li> 这样的地理环境当中有哪些因素会分散用户的注意力?</li> <li> 对于这些干扰因素,你的产品当中能否有相应的预见与响应机制?</li> <li> 用户在使用你的产品时是否通常处于多任务状态下?</li> <li> 用户自身的行为状态是否会干扰产品的使用?</li> <li> 对于用户自身行为所产生的干扰,产品当中能否有相应的预见与响应机制?</li> <li> 是否有必要根据用户在使用产品时通常所处的地理环境,对产品的功能与设计进行优化调整?</li> </ul> <p>相关阅读:<a href="http://beforweb.com/node/80">iOS Wow体验 - 为应用的上下文环境而设计</a></p> <h3> 技术情境</h3> <p>另外一个需要考虑的是产品自身的设计、技术特性,以及用户使用产品的技术能力。举个简单的例子,眼下有不少关于拟物化与扁平化界面设计风格的争论,实际上,一个大体的原则是,无论使用怎样的设计风格,都必须确保界面的自解释性,使用户能够在很短的时间内理解并上手使用。</p> <p><img alt="03-c-technological-context-circles-mobile-app-ux-design-user-research" src="/sites/default/files/images/201304-1/03-c-technological-context-circles-mobile-app-ux-design-user-research" style="width: 600px; height: 300px;" /></p> <p>充分的测试工作是很有必要的,譬如你新设计了一个自认为非常容易理解的图标,但是用户很有可能因为从没有见过这样的设计而无法理解图标的含义。</p> <p>在设计过程中,通过纸质原型进行可用性测试总是会有帮助的。简单快速的测试工作不需要很大的成本,却可以帮助你观察实际用户与产品原型之间的实际交互过程;记录并分析他们的反应和决策,这个过程可以为你带来很多意想不到的信息。</p> <p>根据目标用户的群体特征来选择产品面向的系统平台,这也是一个重要的决策。你需要问自己一些具体的问题,例如产品功能对平台设备有怎样的技术需求,对系统资源及电量的消耗如何,等等。像待办事项这样的轻量级应用不该产生很大的耗电量,用户也很难保留功能有限却非常耗电的应用。设计师应该与开发者一起,将这些有可能影响产品体验的技术情境要素考虑进来。一些典型的问题包括:</p> <ul> <li> 根据目标用户的特征,你的应用产品需要支持哪些系统平台?</li> <li> 不同系统平台之间的优势与劣势在哪里?</li> <li> 应用需要利用的硬件设备功能有哪些?</li> <li> 应用对系统资源的消耗量如何?</li> <li> 目标市场的技术前景如何?</li> <li> 应用是否需要用户保持网络连接?</li> <li> 应用对于流量的消耗量如何?</li> <li> 在功能设计与技术上有没有可能降低数据的传输量?</li> <li> 怎样确保用户数据的安全?</li> </ul> <p>相关阅读:<a href="http://beforweb.com/node/39">怎样打造高性能的移动体验</a></p> <h3> 社会情境</h3> <p>考量移动应用产品所处的社会情境是具有挑战性的。互联网将整个世界连接了起来,我们不能低估各类社交网站对产品推广和传播所起到的作用。</p> <p><img alt="04-c-social-context-circles-mobile-app-ux-design-user-research" src="/sites/default/files/images/201304-1/04-c-social-context-circles-mobile-app-ux-design-user-research" style="width: 600px; height: 300px;" /></p> <p>我们需要判断产品身上有可能具有的社会化因素,考虑能否有效的利用互联网的传播能力。如今,&ldquo;分享&rdquo;或&ldquo;喜欢&rdquo;这类功能是很常见的,不过你需要首先弄清楚这些社会化功能与自己的产品是否具有相关性,能否有效的产生附加价值。</p> <p>要考量产品的社会情境特征,我们需要从用户的角度出发考虑一些问题:</p> <ul> <li> 用户的目标和实际需求是什么?</li> <li> 产品的目标是什么?</li> <li> 用户是怎样与产品进行互动的?</li> <li> 用户与产品互动的过程中需要集中多高的注意力?</li> <li> 产品有哪些核心功能?</li> <li> 用户是怎样使用这些功能的?</li> <li> 用户使用产品的方式是否会与设计目标有所出入?</li> <li> 用户对于界面会产生怎样的反应?</li> <li> 用户使用某些功能的时候是否需要保持网络连接?</li> </ul> <p>通过对社会情境特征的分析,你可以发现产品当中那些有利于社会化传播的功能与文化元素,并有针对性的推广给潜在的目标用户。</p> <p>相关阅读:</p> <ul> <li> <a href="http://beforweb.com/node/109">将产品在移动应用市场中推向成功的十点建议</a></li> <li> <a href="http://beforweb.com/node/129">移动应用的成功准则 - 从产品概念到市场推广</a></li> </ul> <h3> 总结</h3> <p>你即将或已经开始设计开发一款移动应用产品了吗?记得考虑以上这些有可能影响产品体验的上下文情境因素。要打造一款能够真正帮助用户解决特定问题的产品,这方面的研究工作是必不可少的,毕竟,在真正设计和开发工作之前,你应该了解用户为什么会下载你的应用,以及他们会在怎样的环境中以怎样的方式使用你的应用,如果有可能的话,又是否可以促进他们主动传播你的产品<a class="eLink" href="http://beforweb.com">。</a></p> <div class="embed"><article id="node-261" class="node node-related-books" about="/node/261" typeof="sioc:Item foaf:Document"><section class="embed-article"><div class="embed-article-entry"><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><div> <div> <span class="thumbnail"><a href="http://www.amazon.cn/移动设计-傅小贞/dp/B00DINCMYI/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23"><img alt="移动设计" src="http://beforweb.com/sites/default/files/images/products/05.jpg" /></a></span> </div> <div class="content"> <h4><a href="http://www.amazon.cn/移动设计-傅小贞/dp/B00DINCMYI/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">移动设计</a></h4> <p><a href="http://www.amazon.cn/移动设计-傅小贞/dp/B00DINCMYI/?_encoding=UTF8&amp;camp=536&amp;creative=3200&amp;linkCode=ur2&amp;tag=c7210-23">作者从人-机-环的角度出发来阐述移动应用的设计,并建立了移动应用设计的基本原则;然后,根据移动端的情境、移动设备的特征,以及触摸的交互方式,总结了移动导航和框架设计的主要形式,并给出了导航设计的原则和思路...</a></p> </div> </div> </div></div></div></div></section><span class="tag-title">相关书籍推荐</span></article></div> </div></div></div><ul class="field_categories"><li class="product taxonomy-term-reference-0"><a href="/product" typeof="skos:Concept" property="rdfs:label skos:prefLabel">产品</a></li><li class="design taxonomy-term-reference-1"><a href="/design" typeof="skos:Concept" property="rdfs:label skos:prefLabel">设计</a></li></ul><ul class="field_article_categories"><li class=" taxonomy-term-reference-0"><a href="/study" typeof="skos:Concept" property="rdfs:label skos:prefLabel">学习</a></li><li class=" taxonomy-term-reference-1"><a href="/point" typeof="skos:Concept" property="rdfs:label skos:prefLabel">观点</a></li></ul><ul class="field_tags"><li class=" taxonomy-term-reference-0" rel="dc:subject"><a href="/taxonomy/term/14" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户体验</a></li><li class=" taxonomy-term-reference-1" rel="dc:subject"><a href="/taxonomy/term/31" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UX</a></li><li class=" taxonomy-term-reference-2" rel="dc:subject"><a href="/taxonomy/term/32" typeof="skos:Concept" property="rdfs:label skos:prefLabel">UED</a></li><li class=" taxonomy-term-reference-3" rel="dc:subject"><a href="/taxonomy/term/36" typeof="skos:Concept" property="rdfs:label skos:prefLabel">交互设计</a></li><li class=" taxonomy-term-reference-4" rel="dc:subject"><a href="/taxonomy/term/54" typeof="skos:Concept" property="rdfs:label skos:prefLabel">用户研究</a></li><li class=" taxonomy-term-reference-5" rel="dc:subject"><a href="/taxonomy/term/24" typeof="skos:Concept" property="rdfs:label skos:prefLabel">移动应用</a></li><li class=" taxonomy-term-reference-6" rel="dc:subject"><a href="/taxonomy/term/37" typeof="skos:Concept" property="rdfs:label skos:prefLabel">可用性测试</a></li><li class=" taxonomy-term-reference-7" rel="dc:subject"><a href="/taxonomy/term/137" typeof="skos:Concept" property="rdfs:label skos:prefLabel">情境</a></li><li class=" taxonomy-term-reference-8" rel="dc:subject"><a href="/taxonomy/term/16" typeof="skos:Concept" property="rdfs:label skos:prefLabel">原创翻译</a></li></ul> Sun, 07 Apr 2013 03:39:54 +0000 C7210 180 at http://www.beforweb.com http://www.beforweb.com/node/180#comments