监控产品中“告警服务”的设计及演化

在“告警服务”的设计过程中,首先明确了“告警服务”的价值,然后通过用户画像描述了“告警服务”的实际应用场景,接着通过“用户体验地图”全面梳理了“告警服务”中用户的触点、痛点、机会点,并以此分析出设计的落地策略,最后通过对“告警服务”的设计及其迭代演化,逐步完善“告警服务”的设计方案、提升用户体验。

监控,可以拆解为“监视+控制”,监视(monitor)表示用户通过观察获取数据,控制(control)表示数据变化引发的用户行为。

作为云产品的一种,监控产品构成“数据—人—行为”的闭环,满足用户两层需求:

  1. 提供准确实时的产品数据
  2. 产品数据引导正确的用户行为

数据是监控的基础,行为是监控的价值变现。本文所述的“告警服务”就是在用户处于离线状态下,监控产品仍然能构成“数据—人—行为”的完整闭环。

一、告警服务的价值

用户需求

对于99%的用户,都不能7*24盯着监控系统,当处于离线状态时(干活、吃饭、睡觉、下班、休假…),用户与监控数据之间是隔离的。

在这种场景中,如果监控数据发生了异常变化,用户仍希望能够立马获悉,进而采取措施应对、避免造成损失。“告警服务”应运而生,用户设定一定的规则,当监控数据违反规则时触发告警并发送给用户,打破“人”和“数据”的的隔离状态,瞬间构成“数据—人—行为”的完整闭环。

业务价值

“告警服务”能极大解放用户的注意力。通过对产品的业务数据设定规则,业务人员就可以7*24的掌握产品数据的健康状态,得以将更多的精力专注于业务本身。

“告警服务”能使用户第一时间获取期望的业务数据。产品的业务数据一旦违反用户设定的规则即可迅速推送至用户,帮助用户过滤99%的无效信息,使数据精准触达用户。

二、用户画像

用户画像A

任盈盈,女,25岁,产品经理

负责苏宁易购某核心产品线-XX产品线的产品工作,日常的工作主要围绕XX产品线的需求、排期、研发、上线开展,工作节奏快、强度高。每天会登录数次监控产品,查看XX产品线的监控数据,以掌握XX产品线的健康状态。

由于工作节奏快,每天难以抽出充沛的时间去分析产品监控数据,会遗漏部分关键数据从而留下隐患。希望能通过告警服务获取所有XX产品线相关的关键异常数据,既不用花费大量的时间精力去分析数据,也不会遗漏任何关键数据。

用户画像B

令狐冲,男,35岁,技术负责人

负责苏宁易购某核心研发中心-XX研发中心的技术工作,日常的工作主要是XX研发中心的技术保障,工作责任重、压力大。每天一上班就会打开监控产品,随时查看XX研发中心相关的监控数据,保证系统的稳定。

由于系统是7*24小时运行,但自身无法全天候上线查看监控数据,尤其是下班后或节假日,没法做到随时查看监控数据。希望能通过告警服务及时获取XX研发中心相关的异常数据,以便第一时间作出判断、并决定是否安排人员介入。

三、用户体验地图

通过参考行业相关产品和调研用户需求,可以将“告警服务”拆分为4个阶段:

“配置告警策略——筛选产品数据——推送告警消息——接收告警消息”

以下是“告警服务”4个阶段的用户体验地图,可以从全局视角审视“告警服务”的每一个环节。

通过洞察用户的行为和心理,梳理用户在不同阶段的情绪点,可以盘点、挖掘“告警服务”四个阶段设计的机会点,如下:

  1. 配置告警策略:简单的配置规则、合理的指标、提供默认的阈值
  2. 筛选产品数据:计算平台处理能力强、计算平台准确性高、计算平台稳定性好
  3. 推送告警消息:告警平台稳定性好、告警平台对相同告警进行合并
  4. 接收告警消息:告警内容简单易读、告警消息支持多渠道发送、告警消息支持自定义接收者

四、分析与思考

用户体验地图给出设计的“机会点”,接下来需要思考如何将其落地、形成可参考执行的设计策略。

首先,需要关注存在哪些用户触点,这是设计落地的切入点,通过用户体验地图,分析如下:

1)在“配置告警策略”阶段,存在1个触点:告警配置模块。

结合该阶段的设计机会点,可以推定:在告警配置模块,需要提供简单的配置规则,在配置规则内尽量提供用户最合适的指标或组合,并且在关于阈值的设定上可以提供默认值、或者毋需用户设定。

2)在“筛选产品数据”、“推送告警信息”两个阶段,均由后台系统自动完成、用户不会直接接触,因此不存在用户触点。

但是并不意味着设计不需要关注这两个阶段,在设计的过程中,需要根据目前的技术能力给出合理的设计方案,尽量避免凭空想象。

3)在“接受告警消息”阶段,存在2个触点:终端接收设备、告警内容。

结合该阶段的设计机会点,可以推定:

  • 针对“终端接收设备”,用户希望可以选择自己需要的渠道接收告警消息,并且告警消息发送给谁也由用户自己决定,这两项均属于配置阶段的内容。
  • 针对“告警内容”,用户希望能按照重要、紧急两个维度将告警内容从上到下排列,并且尽量减少冗余信息、提升可读性。

通过以上分析,可以清晰归纳出,设计的落地点主要由两个:

  1. 配置告警策略(支持自定义的渠道和接收者)
  2. 告警消息所推送的内容

针对这两项的设计策略如下:

五、设计及演化

配置告警策略

参考行业相关产品,告警配置模块主要分为两个部分:

  1. 告警策略的展示列表
  2. 告警策略的添加/编辑状态

本质上两者都是即围绕“告警策略”开展设计。

针对“告警策略”,一般由4种内容组成:

  1. 告警策略的名称
  2. 告警监控的对象
  3. 告警针对的指标
  4. 告警触发的条件

在本案例中,由于“终端接收设备”模块的内容合并至“告警配置模块”,因此本案例中的告警策略需要再增加一项内容:告警消息的推送。

1)告警策略的名称:指本条告警策略的名称,与人的姓名一样,是用户识别告警策略的主要标识。

2)告警监控的对象:指本条告警策略是针对哪些对象而配置的,监控这些对象的状态变化。

3)告警针对的指标:指针对哪个数据指标设立告警规则,指标可以是单个或一组,需要选择合适的指标才能更好的发挥告警服务的价值。

4)告警触发的条件:指选定的数据指标达到什么阈值即触发告警的生成,这个决定告警服务的精确程度。

5)告警消息的推送:指告警消息发送的人员,以及发送的方式,也就是解决“通知谁、怎么通知”的问题。

梳理完告警配置模块的元素,就可以根据“配置告警策略”的设计原则,开展设计:“配置规则简单、指标契合、阈值有默认值、自定义接收渠道、自定义接收者”

当用户进入告警配置模块,未配置任何告警策略,提示、引导用户开始创建。

针对“添加告警策略”,经历了3版设计方案的演变。

第一版方案,基本符合上述的设计原则。

该方案上线之后用户配置了大量的告警策略,但发生了意想不到的事情:不告警。经过排查定位,最终确认是计算平台产生了非常严重的阻塞,即“用户体验地图”的第二阶段“筛选产品数据”出了问题。复盘之后,认定有两方面的原因:

  1. 一是所选择的告警指标“影响用户占比的环比增长率”涉及大量的“去重”计算,严重消耗计算平台的性能;
  2. 二是监控对象没有做限制,多个筛选条件排列组合之后产生了大量监控对象,远远超过了计算平台的极限。

因此,决定从两个方面优化设计方案:

  1. 使用新的告警指标
  2. 对监控对象做限制

这是第二版方案,在延续第一版所遵循的设计原则基础上,针对性做了优化。

  1. 监控对象限制了可配置的数目,降低现有计算平台产生阻塞的风险;
  2. 改用新的告警指标,舍弃了“去重”计算,提供“绝对值”、“相对值”两种指标供用户选择,覆盖面更广;
  3. 精简了触发条件,减轻现有计算平台的压力;
  4. 消息推送的渠道默认值只设置“豆芽”,降低成本(豆芽是苏宁内部员工使用的IM工具)

第二版方案上线之后,告警计算平台的阻塞问题解决了,但是用户反馈:监控对象可配置的太少。这个当时已经预料到会有这个问题,但是现有的计算平台性能受限,“巧妇难为无米之炊”,只能采取这种妥协的方式。

随着新的计算平台上线,性能得到极大提升,设计方案也不用“畏手畏脚”。第三版方案在保留原有优点的基础上,主要针对“告警对象”做了重点优化。

  1. 告警名称提供默认值,解决用户对告警名称填写过程中“不愿想、不愿写”的”懒“需求;
  2. 监控对象的来源,提供用户常见的场景作为待选集合,方便用户快速选择告警对象;
  3. 监控对象的配置,让用户行为从“输入”变成“勾选”,并提供批量选择,简化用户的配置步骤;
  4. 监控对象的数目,限制数放开至200,并可通过后台配置进行动态调整。之所以将数目暂定于200,是方便用户从四个TOP异常的场景中分别选中一类,正好200。

添加完告警策略之后,告警模块至少会有一条告警策略。

  1. 支持用户对告警策略列表进行筛选、搜索
  2. 支持继续添加告警策略
  3. 将告警策略的五种主要内容(告警名称、监控对象、告警指标、触发条件、消息推送)显示在列表内
  4. 支持对单条策略的开关、编辑和删除,其中“开关”场景是用户暂时需要关闭策略、但不对其进行删除

告警消息

告警消息指的是当告警发生以后,告警平台将该条告警相关的信息推送至用户,是“数据—人—行为”闭环的重要一环,用户通过阅读告警消息获取当前系统的健康状况、从而采取对应的干预措施。

根据“告警消息”的设计原则,开展设计:

“提供关键数据、精简告警内容、减少冗余信息、提升可读性”

相比于“配置告警策略”,“告警消息”没有出现过较大版本的优化。通过参考行业相关产品和用户需求,择取了9个字段,实际的告警消息有两种模板,分别对应两种告警指标:异常数、绝对值。

  1. 告警策略的名称:用户第一时间判断和自身的相关程度,是否自己创建、是否是高优先级告警策略。
  2. 当前产生的告警等级:判断该告警的严重程度,决定了采取何种干预措施。
  3. 产生告警的监控对象:确认告警是由哪个监控对象引起,如果要采取措施可据此联系责任人。
  4. 触发告警的数据:查看现场数据,在告警等级的基础上进一步判断该告警的严重程度。
  5. 告警发生的时间:时间可用于定位告警的原因和判断时效性。
  6. 告警所属的产品:附属信息,当用户名下有多个产品时据此区分。
  7. 告警发生的来源:附属信息,当用户使用多种监控系统时据此区分。
  8. 告警消息的接收者:附属信息,用户用以判断相关干系人是谁。
  9. 告警策略的创建者:附属信息,用户用以判断该告警策略是否是正常、合法创建。

六、总结

小结

在“告警服务”的设计过程中,首先明确了“告警服务”的价值,然后通过用户画像描述了“告警服务”的实际应用场景,接着通过“用户体验地图”全面梳理了“告警服务”中用户的触点、痛点、机会点,并以此分析出设计的落地策略,最后通过对“告警服务”的设计及其迭代演化,逐步完善“告警服务”的设计方案、提升用户体验。

随着AI和大数据等技术的引入,“告警服务”会持续进行优化迭代,主要围绕3个方面:

  1. 更简单的配置。通过采取态势感知、智能化的带状阈值区间会逐步取代人工设定的阈值,能极大降低用户使用“告警服务”的成本。
  2. 更具体的对象。目前的告警策略针对的还是零散的告警对象,未来将会将围绕“场景”概念为用户提供更加具体的业务告警对象,价值更高。
  3. 更精准的决策。目前的告警服务仅仅限于将现场数据告知用户,未来将会提供给用户加精准的辅助决策,以达到智能化运维的目标。

反思

设计师都是理想主义者,设计过程就是一个理想主义者不断与这个世界妥协的过程,与用户妥协、与技术妥协、与时间妥协,但这也体现体验设计的魅力:围绕用户需求进行快速迭代。

“设计没有好与坏,只有合不合适”

作者:胡欣欣,公众号:吹拉弹唱大师(ID:cltcds)

本文由@吹拉弹唱大师 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash, 基于CC0协议

用户研究有必要扩展做商业分析吗?

编辑导语:当你觉得你在用户研究这个专业已经做到了很好,需要一些突破和进步,在你有一定的专业程度和积累了一下项目实践后,可以尝试融合其他学科的知识到本专业里;本文作者详细介绍了用户研究有没有必要做扩展这个问题。

大约在2年前,我隐约感觉到自身在用研的天花板已经快到了;当具备了一定程度的研究功底(对于实用主义者来说够用就好),也积累了很多跨行业(社交、支付、手游、互金、物流、电商)的重要项目实践后,我开始思考还能怎么提升自己以及团队。

当然,我指的是专业路线上的提升,这里不涉及到管理路线;关于研究类岗位人才的管理路线发展,有机会再和大家分享。

在个人的专业上,我一直保持的一种提升方式是:多尝试融合其他学科到我的本专业中,比如将人类学、行为经济学、社会学等基础学科的方法与实验心理学、统计学结合,应用在项目实战中。

这篇文章主要回顾的是团队专业性的提升,我在思考时主要有两个不同视角:首先根据用研所做的事情、以及思维层面,将用研人才划分为三个层级,去看我以及团队目前在哪层级,接下去需要到哪层级;然后结合岗位的演变规律来推断岗位的进化方向,赶在行业重大信号发出之前,先行一步做好准备、积攒经验。

一、关于用研人才层级的思考

如下图所示:

用户研究有必要扩展做商业分析吗?
  • 第三层级是运行层:比如通过可用性测试、版本的满意度调研、竞对分析等常用的工具方法,帮助产品部门、设计部门通过定位到操作层面的问题,来去优化现有的产品,使之符合好的用户体验标准(好用、易用、情感)。
  • 第二层级是战术层:比如通过用户洞察的方法,去做产品的创新研究,从而找到既能满足用户多样化需求,又能为公司实现更多商业价值的机会点。
  • 第一层级是战略层:比如通过识别公司现有业务的核心问题,进行研究与分析,找到业务的解决方案或开发新的业务。

而商业分析(Business Analysis,也可以叫业务分析)源自于管理咨询(ManagementConsulting)行业,主要的工作就是:就业务发展中的核心问题进行判别、研究、分析和解决。

用户研究有必要扩展做商业分析吗?

所以从用研人才层级的视角来看,如果要做到第一层级,必然需要学习BA是如何做的。

二、关于用研岗位发展

大家可能都知道,很多偏向于专业型的岗位都在不断演变和进化。

比如我们去看设计领域,从美术工程师——UI设计师——交互设计师——体验设计师——产品设计师;演变的方向很容易分析出来:全面综合化、不断接近上游岗位直至可以整合归一。

那么目前我们称之为用户研究/用户体验的这个岗位,它是从什么岗位进化而来,又会进化成什么岗位或者说是将来的职能范围会扩展到哪里去呢?

在当时,我对用户研究的发展脉络,做了如下图所示的梳理:

用户研究有必要扩展做商业分析吗?

关于起源,从国内互联网公司开始崛起后,以阿里腾讯为首,开始学习国外可用性工程。所以圈内的多数同行都认同用户研究岗是从可用性测试工程师发展来的,并且加入了多元化的研究视角。

1. 可用性工程定义

以美国认知心理学家诺曼和尼尔森为代表,是一门在产品开发过程中,通过结构化的方法提高交互产品的可用性的学科,建立于认知心理学、实验心理学、人类学和软件工程学等基础学科的基础上。

包括一整套工程过程、方法、工具和国际标准,它应用于产品生命周期的各个阶段,核心是以用户为中心的设计方法论(user-centered design – UCD);强调以用户为中心来进行开发,能有效评估和提高产品可用性质量,弥补了常规开发方法无法保证可用性质量的不足;九十年代以来开始在美、欧、日、印等国IT工业界普遍应用。

但其实早在国内开始引进、培养可用性测试工程师之前,传统领域就有市场研究这类岗位了,现在其实很多用户研究的同学都仍然在使用传统的市场研究方法与概念。

2. 市场研究定义

ICC/ESOMAR(国际商会/全球市场研究者协会)、中国市场研究协会(China MarketingResearch Association)将市场研究定义为:

“是指为实现市场信息目的而进行研究的过程,包括将相应问题所需的信息具体化、设计信息收集的方法、管理并实施数据收集过程、分析研究结果、得出结论并确定其含义等。

所以我认为,可用性工程与市场研究,都可以作为用户研究的前世。只不过这两位前世并没有消失,目前还活跃在很多公司中,并且也是很重要的角色。

毕竟很多行业的人才技能更新速度相比于互联网公司,还是会慢很多年。谁让互联网的人才更迭速度和互联网产品的迭代与消亡速度成正比呢。

所以这也是为什么,我们这些互联网行业的IT民工,所承受的学习压力和成长焦虑,是其他行业从业者很难理解的。

前世说完,接下来是今生。

3. 用户研究定义

用户研究是以用户为中心的设计流程中的第一步。

他是一种理解用户,将他们的目标、需求与企业的商业宗旨相匹配的理想方法。

用户研究的首要目的是帮助企业定义产品的目标用户群、明确、细化产品概念;并通过对用户的任务操作特性、知觉特征、认知心理特征的研究;使用户的实际需求成为产品设计的导向,使产品更符合用户的习惯、经验和期待。

那为什么我会坚持认为,用户研究需要向商业分析演变,或者职能范围会扩展到商业分析呢?

4. Business Analysis 定义

用户研究有必要扩展做商业分析吗?

翻译:商业分析(Business Analysis,也可以叫业务分析)通过定义业务问题(需求)和推荐解决方案来交付价值给利益相关者,从而引导企业变革。

因为如果要不断强化用户研究的价值,就要关注三件事:

  • 你做的事情对公司当前来说是否很重要:当公司业务遇到很大瓶颈时你是否仍然在关注APP的细节优化?
  • 你做的事情是否有可持续的价值:你是否会考虑到这件事情对公司长期发展来说能产生可持续的影响吗?
  • 你做的事情是否能解决复杂的问题:你是否一直在重复做着三下五除二就能搞定的简单问题?

商业分析的工作就需要具备这三个关键点:

用户研究有必要扩展做商业分析吗?

2018年6月,经过上述两个层面的思考后——用研人才层级、用研岗位发展,我用了4个月时间,快速但还算系统地学习了商业分析的工作视角、胜任能力、岗位技术、知识领域。

用户研究有必要扩展做商业分析吗?

2018年10月,正巧公司决定把我们用研团队与大数据中心合并,我果断向公司提出申请,把团队名称“用户研究”改为“商业分析”,“大数据中心”也随之改为“大数据策略中心”——时机刚刚好。

但当HR问我,大家的title是否也从“用户研究员”改为“商业分析师”时,我认为还没有到时候;因为我不想在只有我自己,但团队还没做好转型的准备时,因为岗位名称提前变化,使大家感受到的是“被迫成长”的压力。

不过后面又接着发生了一系列的组织调整变化,说来就话太长了。

所以从2018年10月开始,我们团队算正式把用户研究的职能扩展到了商业分析,后面经过一系列的策略性调整后,正式成立为战略部。

由于篇幅关系,下次再和大家分享,到底什么是商业分析,以及用研或者数据的同学转型商业分析,需要如何规划能力体系的学习。

为什么还要介绍什么是商业分析?因为我发现虽然很多人都知道商业分析,但是不同行业、不同岗位所理解的商业分析,是不一样的。

有人用业务视角来看认为是业务架构分析,有人用敏捷视角来看认为是项目流程管理,有人用BI视角来看会认为是数据分析商业化,还有人用IT视角来看觉得是需求工程。

作者:媛媛大王(微信公众号:用户研究社 ),资深用户研究员

本文由 @媛媛大王 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

用格式塔原理分析页面中的用户体验

我一直认为心理学和设计是包含用户体验的。每当我们的目标是解决需求的时候,我们的专业就需要有同理心。随着我继续深入研究心理学进入设计领域时,我偶然发现了格式塔原则。

那么,什么是格式塔原则?

格式塔心理学是一种将人的思想和行为视为一个整体的思维学派。当试图理解我们周围的世界时,格式塔心理学建议我们不要只关注每一个小部分。

相反,我们的头脑倾向于将对象视为更大整体的一部分,并将其视为更复杂的系统元素。这个心理学院在人类感觉和感知研究的现代发展中发挥了重要的作用。

这次发现格式塔原理的旅程让我充分理解如何将这些原理融入到我的设计中。因此,在本文中,我将与您分享如何将这些原则作为我设计解决方案并应用于我的网站和应用程序中:

1.接近

当物体彼此靠近放置时,这些物体被视为一个整体而不是单独的个体。

以下是我们如何在设计中使用接近法则解决问题的一个例子:

图0:用格式塔原理分析页面中的用户体验

标题和链接相距甚远

正如我们所看到的,类别标题(在线预订和邮轮)和链接(了解更多)彼此分开,这使得它们看起来像浮动元素。如果我们将创建一个线框,它会看起来像这样:

图1:用格式塔原理分析页面中的用户体验

线框

整个组件脱离了上下文,因为没有将图像,标题和链接关联在一起。因此接近法则是我们的解决方案。把三个单独漂浮在外层空间的元素,作为一个整体组件。

图2:用格式塔原理分析页面中的用户体验

中心对齐的标题和链接

在我们使用接近原则的设计解决方案中,我通过使用中心对齐来缩小标题和链接之间的距离。通过这种方式,我们能够将3个元素(图像,标题,链接)结合在一起,这有助于我们解决缺失的上下文问题。

2.相似性

当对象彼此相似时会出现相似性。人们通常将它们视为一个群体或模式。资料来源:graphicdesign.spokanefalls.edu

在下面的设计问题A中,我指出了蓝色的文字颜色。原因在于,在用户交互中,Heavy Data User 和 Flexible Maximizer 是相似的 – 它们在界面中实际上都是标签。

图3:用格式塔原理分析页面中的用户体验

设计A

那么,是什么让这两个元素彼此无关呢?

答案很多。但是更简单的说明,没有任何东西将这两个元素绑定在一起,这使得它们看起来很分散。正如我们所看到的那样,很明显,界面的品牌颜色是绿色的,但突然间一个蓝色的文字颜色从无处跳出。因此,相似法则的规律在于:

图4:用格式塔原理分析页面中的用户体验

作为我们的解决方案,我通过将文本颜色设置为绿色并调整按钮的左右填充来创建相似性,以便它更接近另一个按钮 Flexible Maximizer.。

这个设计问题A可以通过重新设计来进一步改进(这实际上需要重新设计),这样可以更加简化用户的体验。但现在,让它在制作中改动一小步来到达相似性原则 – 方法2:

图5:用格式塔原理分析页面中的用户体验

设计B

现在在方法2中,我们来观察它的基本部分 – 类型系统,它们是:

标题: 40px Regular

正文: 20px Regular

文字链接: 20px Regular

乍一看,我们可能会认为这只是一个我们可以忽略的普通类型系统。但是当我们看得更近时,问题发生在正文文本和文本链接之间,它们都共享相同的文字系统(20px Regular),这可能导致用户混淆并且缺乏用户信任。当他们浏览网站时,他们可能会犹豫,他们正在交互的是正文文本还是文本链接,那么就需要进行反复试验。

好的,那么我们如何解决这个问题呢?

图6:用格式塔原理分析页面中的用户体验

作为我们的相似性解决方案,我们需要稍微调整Type系统:

标题: 40px Regular

正文: 20px Regular

文字图标链接: 20px粗体

我们通过使文本链接加粗,并且添加了一个图标,这样就增加了对比度。通过进行这些更改,我们在整个文本链接中创建了相似度,并加快了用户的认知加载速度。

超出主题的快速提示:在创建一个Type系统时,请选择具有各种权重的字体(细,轻,常规,粗体等)。我们的目标不应该是具有较少权重的各种字体大小以获得更好的对比度,而是要具有几种不同权重的字体大小。

3.焦点

焦点是关注领域,强调或找到构图中的差异,以捕捉并保持观看者的注意力。

在焦点问题上,我们将展示两个设计问题:

图7:用格式塔原理分析页面中的用户体验

从电信网站

在上面的例子中,元素的布局实际上没有问题。但是我们拥有的信息层次结构 – 主要操作和次要操作共享相同的按钮系统。

我们可以看到,这个界面的目标是让用户下载应用程序,并且FAQ是一个支持文档,让用户更好地理解他们的应用程序。

因此,我们的解决方案是:

图8:用格式塔原理分析页面中的用户体验

设计解决方案A

利用焦点原则,我将View FAQs按钮界面更改为边框按钮,为下载应用程序按钮提供所需的聚光灯效果。我还交换了他们的订单,主要行动在右边和次要在左边。其原因在于古腾堡图(Gutenberg Diagram)。它说:

基于这个定理,右边的两个点(在“Z”的第一个点及其最后点)是游客期望采取行动的地方。因此,在这里,您的号召性用语属于正确还是左侧,在这里确实没有问题。它应该始终朝向屏幕的右侧。

欲了解更多信息,你可以在这里这里查看 😀

我们通常可以看到的常见的按钮设计问题也仅仅是为了增加主题外的一些东西,为不同功能创建一种按钮界面(填写注册按钮,取消,加载更多内容,阅读更多内容等)。

难道创造一致性不好吗?

是的,我们都知道一致性在UX设计中扮演着重要角色,但我们称之为功能一致性。如果我们将创建相同类型的按钮设计来满足不同的功能,则会导致用户不一致的体验,并且可能会影响我们客户的业务目标。

脱离主题快速提示:按钮设计一致性=按钮功能。

现在转向Approach 2应用程序:

图9:用格式塔原理分析页面中的用户体验

两个按钮具有相同的视觉层次结构

这种设计也会出现同样的问题。“确定”和“取消”按钮共享相同的设计风格,这要求他们彻底阅读按钮标签,以便他们能够知道提交和取消的内容。

使用焦点,我们减少了阅读标签的时间,这导致我们设计解决方案B:

图10:用格式塔原理分析页面中的用户体验

我们互换了按钮并将按钮副本从OK更名为Submit,以使其更加上下文,并通知我们的用户,一旦他点击按钮,就会发生一个动作。

4.共同区域

共同区域的原则与邻近度高度相关。它指出,当物体位于同一封闭区域内时,我们认为它们被分组在一起。来源:用户测试

图11:用格式塔原理分析页面中的用户体验

Spotify,迪士尼,Netflix等功能不会与其类别一起分组,并且似乎是浮动元素。为了使它更简单,创建一个线框将看起来像这样:

图12:用格式塔原理分析页面中的用户体验

从上面的线框中可以看出,它比4个整体组件更可能是单个元素。因此,作为解决方案,共同区域原则:

图13:用格式塔原理分析页面中的用户体验

我们新的线框与共同区域原则

在线框中,我们使用框边将所有特征包含到它们各自的类别中,以便将它们视为一个而不是单个元素。以下是实施:

图14:用格式塔原理分析页面中的用户体验

除了边界框之外,我们用Plan Net 999替换了* Free Netflix六个月,并在Netflix元素的右上角用一个信息图标(彩色黄色图标)替代了功能列表的空间,一旦点击,会出现一个工具提示。

总结,这是4格式塔原则,可以节省您的设计时间。还有更多的格式塔原理可以用作您的解决方案。

希望你也受用

祝开心

本文翻译来自Medium感谢Psychology + design: Gestalt principles you can use as design solutions

以滴滴为例:聊聊价格理论与用户体验

人本质上都是趋利的,价值创造者应该顺势而为,聚焦效用与成本,才能真正做到以用户为中心。 

产品的效用与成本

我们可以把用户使用产品看作是一种“交易”,消费者付出一定的成本,获得了一定的价值。在经济学的价格理论中,我们评估商品能否成交,是基于商品给消费者带来的效用(满足程度)。

比较“A:消费者为了获取这些效用所愿意付出的最高价格”与“B:商品的实际价格”,如果:A<B,则交易无法达成,因为消费者要获取商品效用所愿意支付的最高价格比实际需要支付的价格要低。

俞军老师将其抽象为:

用户价值=新体验-旧体验-切换成本

这个公式很容易理解:

相比微信,子弹短信提供了更有价值的语音信息,用户不需要付出“听语音的成本”,就能接收到语音消息的内容,所以这里的“新体验-旧体验”是正值。但是, 微信上海量的好友关系,聊天记录,公众号,朋友圈等等,都让“切换成本”变得非常高,所以对于绝大部分微信用户,子弹短信的“用户价值”仍为负数,用户不会放弃微信。

为了让用户价值公式更好地指导产品设计,我们继续拆“体验”。我认为:

体验=效用-认知成本-时间成本-操作成本

  • 效用:产品/服务对用户的满足程度。例:当我饿又不想做饭的时候,饿了么的外卖服务为我提供了比较大的“效用”
  •  认知成本:思考产品/服务所需花费的成本。例:这个“微信7.0的即刻视频”到底是怎么用的?(用户要花大量精力思考)
  • 时间成本:等待产品/服务所需要花费的成本。例:ZEPETO最火的一天,服务器几乎无法登陆,用户无法深度体验
  • 操作成本:获取产品/服务所需花费的行为成本。例:相比支付宝,微信支付依托于微信高频的使用,在场景下不需要再单独打开APP付款,操作成本更低

综上,设计产品、创造价值的过程,我们本质上是追求:

  • 在相同的效用下,让用户付出更低的成本;
  • 在相同的成本下,让用户获取更多的效用。

以滴滴为例

1. 效用

作为用户,使用滴滴出行的快车服务,我们能获得多少“效用(满足程度)”?

  • 随时随地快速叫车,不用再为夜晚路上没有出租车打而烦恼。
  • 等待司机找乘客,不用为了打车到处走。
  • 透明的用车价格,不用再跟黑车司机议价、拼车。
  • 严格的路径规划,不用担心导致的绕路多计费。
  • 良好的司机服务,出行属于买方市场,乘客的评价对司机的利益影响较大,该模式倒逼司机提供更好的服务。
  • …….

相比传统出租车,滴滴快车在初期通过“补贴”快速获取市场份额,培养用户习惯。在补贴退出后,产品仍然能向用户提供“更快速响应、更多元、更方便、更透明安全(综合起来就是效用)”的出行服务。

2. 成本

① 认知成本:减少用户的“不确定性”,降低思考的成本

1)提前告知重要信息

一般用户在选择目的地后,会想要知道多久能打到车,为了让用户减少“认知成本”:

  • 滴滴出行,在选择目的地后会显示“预计上车时间”。
  • 神州专车,不会显示“预计上车时间”,用户想要知道只能叫车后等待。
  • 优步中国,在未选择目的地之前就会显示“预计上车时间”。

② 操作成本:简化高频操作,降低操作的成本

滴滴快车的订单操作中,有三步是必须的:选择位置选择车型支付车费。要降低用户的操作成本,需要围绕这3个关键步骤做优化。

1)预测用户行为

在通勤、蹦迪回家的场景中,用户的OD往往是固定的,可基于用户历史的订单数据,预测目的地,减少用户的“操作成本”。

2)主动替用户选择

打开APP,第一步是定位用户位置,对比了滴滴、神州专车、优步中国:

  • 滴滴出行,在初始状态会选择基于当前定位的最佳上车点,减少了用户的“操作成本”。
  • 神州专车,在初始状态提示“定位可能有偏移,请确认您的上车地点”。实际上选择了推荐的上车地点后,上车位置几乎没有变化,说明产品对“起始点合适程度”的判断逻辑还需要改进。

3)简化关键节点

开通免密支付,每次行程结束后自动扣除车费,减少了用户的“操作成本”。

③ 时间成本:要降低用户的服务等待时间,往往就是要解决供需匹配的问题

滴滴的出行是即时的,相对同城运输、干线车货匹配,其实时性要求更高,如果平台运力与需求的匹配度低,则需要通过“配给”或者“价格机制”解决供需失衡。

需求端:

  1. 乘客动态加价(价格机制)
  2. 提高车价(价格机制)
  3. 乘客排队(配给)

供给端:

  1. 任务奖金(价格机制)
  2. 提高车价/降低抽成比例(价格机制)

由于之前滴滴的动态加价遭受舆论的谴责,目前改用先到先服务的排队机制,应对当前监管压力下的供需失衡。然而,这种机制无法保障“最需要服务的人(也就是愿意出更高价格的人)获得服务”,资源的利用效率并不是最优的。

更重要的是,排队并不比价格机制更能解决问题,因为“即使出行”的用户决策时间很短,排队实际上也是变相的挤走了部分的需求(如下图),而这些被挤出的需求可能是更需要出行资源的人(也就是愿意出更高价格的人)。

总结

很多时候我们可能会疑惑“用户为什么不愿意用我们的产品”,其实是没有关注产品为用户提供了多少效用、用户为之需要付出多少成本。人本质上都是趋利的,价值创造者应该顺势而为,聚焦效用与成本,才能真正做到以用户为中心。

本文由 @代小艺 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自网络

京东内部资料:用户体验提升模型

经过项目中不断的探索与研究,结合几个方法论,我们整合出了一套用户体验提升的方法流程——用户体验提升模型。

下面就来详细的介绍一下,希望能给到大家帮助和启发。

先问几个问题:

  1. 你知道你所负责的产品/设计方案的用户体验好还是不好?
  2. 产品/设计方案体验不好时应该怎么做?
  3. 这个产品/设计方案的体验具体有哪些问题?
  4. 怎么优化出现的体验问题?
  5. 哪些模块或页面的问题最迫切需要解决?先优化哪些?后优化哪些?

用户体验提升模型能很好的帮我们解决以上问题。

先介绍一下用户体验提升模型的流程:线上版本调研 – 协作启发式评估 – 问题分析整理 – 优化方案

这篇文章也会以这个流程一一介绍。

一、线上版本调研

也可以是设计方案,我们采用了SUS系统可用性量表进行调研,SUS是评估产品可用性的一个花费少,但十分有效的工具。该量表包含了10条定向问题,每个问题均为5分,按强烈反对(1分)到非常同意(5分)评分。(各位小伙伴可自行网上查询系统可用性量表,有很详细的介绍,在这里不赘述了)

最佳的方式是在线上直接上一个问卷调研来收集真实用户的反馈,然后对收集到的结果做如下算法:

  1. 对于奇数序号的问题,将其得分减1;
  2. 对于偶数序号的问题,将其得分被5减去;
  3. 将所有问题的减法后得分加在一起,然后乘以2.5;
  4. 计算出的结果即为我们产品可用性的得分。

那么如何通过评分看出一个产品的好坏?

上图是一个评分参考,通过数据得出,系统可用性量表最终算出的评分达到70分左右,就可以比市面上一半产品可用性要好,也就是说这个产品的用户体验算是合格了。

但是系统可用性量表的评分结果是抽象的,这个分数只能让我们大概了解产品用户体验的好坏,在具体问题上却是缺失的,那我们知道产品评分较低时我们如何聚焦产品的优化方向呢?

二、协作启发式评估

为什么是协作启发式评估而不是启发式评估?

因为启发式评估主要由几名交互专家以角色扮演的方式,来完成设置的任务给出评估结果。

优点是成本低、快捷;

缺点也显而易见:

  • 一是交互专家团队中不一定有或者很少;
  • 二是可用性问题意见一致率很低,并不能很明确的指出为什么这是一个体验问题,有很多个人因素的主观见解。

因此我们决定用协作的形式来进行评估,而且不需要交互专家,可以是用户、测试、设计、产品、运营、商务等等,只要愿意参与测试,就可以。协作启发式评估以小组为单位,能够很好的整合出更多的问题,而且更准确。你说他们也不是交互专家,能起到好的结果吗?竟然都整理出方法了,那答案当然是能啊。

为什么能,因为整个评估过程中,我们是有最新的可用性原则来给予启发的,有了这套可用性原则,一秒变专家。

说到可用性原则,了解用户体验的都知道尼尔森的十大可用性原则,但是从1995年提出到现在,已经过去了二十多年,互联网世界已经发生了巨大的变化。在这样的情况下,尼尔森的十大可用性原则明显有些不那么符合或者说不能给出针对现今产品太全面的启发。

所以,我们重新整理了一套可用性原则,这套可用性原则更针对现今互联网产品,基本可以覆盖到所有出现的用户体验问题。

我们称之为最新21条可用性原则。(重点来了,重中之重)

有了这21条,可以让任何没有用户体验知识的人参与到协作启发式评估中来了,一秒变专家了有木有。当然,这21条可用性原则我们也会迭代优化,目的是做到更符合现今产品、更全面的可用性原则。

通过什么来确定的这21条可用性原则?

首先,我们都知道用户体验五要素,这已经是做产品设计的基本常识了。

我们来看这五个层级对用户体验能产生影响的有哪些?

战略层一定不会,如果一个产品立项了、已经上线了,一定是战略层成立了,如果战略层出现了问题那就要重新考虑产品要不要做或者是改变方向了。

那么剩下的4个层级呢?

范围层、结构层、框架层、表现层,其实都会出现用户体验的问题。

那我们看看这几个层级所包含的内容,视觉呈现界面设计导航设计信息设计交互设计信息架构功能规格内容需求,这样的话就有8个大类,然后我们通过多年的经验和对尼尔森可用性原则的理解,把可用性原则对应到这8个大类中,最后得到了这分类明确的21条可用性原则。

但是分了这8个类有个啥用?读下去,你就会知道。

具体方法:

先说说调研的具体方法。我们以协作启发式评估的方法,组织好调研小组(8人以上,样本越多越好,反正最后还要去重),宣讲完流程方法和操作任务,就可以开始进行评估了。我们一般为了省时间,宣讲完就把表格发下去,让他们自己找时间完成表格,然后再收回来。

这个表格就是用户体验问题记录表,包括问题所在位置、对应的21条可用性原则、严重程度等级、问题描述。

三、问题分析整理

收集了一堆问题之后应该怎么做呢?

通过小组会议讨论,把相同、相近的问题统一成一个,可优化的问题保留下来,不是体验问题的去掉,然后整理到一起,这就是整个产品存在的大大小小、各种各样的问题了。

接下来,我们引入另一个方法,就是用户体验八阵图

这张用户体验八阵图的8个点是不是有些眼熟?

没错,就是最新21条可用性原则里的8大分类,这就是上文为什么分为8个类的原因。中心向外为问题严重等级,依次为:小问题(1)、次要问题(2)、主要问题(3)、灾难性问题(4),一一应对到“用户体验问题记录表”中的“问题严重等级”。

怎么使用呢?

首先,对记录表里的“问题位置”进行归类,以模块化区分,比如:把登录注册流程做为一个模块,用一张八阵图来表示,最终把产品的每个模块都用一张八阵图来承载所对应的体验问题。

然后,把收集到的问题以“点”的形式点到对应模块的八阵图当中。

哪个模块问题最多?问题出现在哪个方向上?是视觉?还是交互?还是内容?哪些问题很严重需要迫切解决?一目了然。

四、优化方案

  1. 通过SUS系统可用性量表知道了产品的整体体验处于什么水平。
  2. 通过协作启发式评估知道了产品的用户体验到底有哪些问题。
  3. 通过最新21条可用性原则知道了如何避免出现体验问题。
  4. 通过用户体验八阵图知道了哪些模块最迫切需要优化。

知道了这些,我们进行产品优化的时候还会不知道如何下手吗?接下来就要靠你自己了,你一定会做的更好。

当然,这套模型只能对线上产品的用户体验提升起到一定帮助,一个产品真的牛逼还要从战略层一步步做起,我们需要去清楚的知道产品的目标是什么,我们能提供什么,我们想要去得到什么。对于产品的迭代,我们可以从使用人群(目标客户),主要功能(产品的服务方向),产品特色(与竞品的差异化),商业价值(盈利模式)上深入研究。

结语

好了,到这里就为大家介绍完了这套用户体验提升模型,如果还有什么不清楚的地方,随时欢迎大家咨询,期待与大家一起探讨~

作者:FTD,公众号:FTDesign

来源:https://mp.weixin.qq.com/s/y1Ct7DQLjdk3rqkV6hxXIA

本文由 @FTD 授权发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议