UI 是 UX 的充分条件

UI 是 UX 的充分条件。UX 不等于 UI,但 UI 绝对属于 UX 范畴。

微软 UX 顾问 Madeline Schenck 在 19 的时候,写过一篇文章来表述 UI/UX 的差异。本以为这是个老掉大牙的话题,根本不值得再去反复讨论,但随着公司对设计师 Tilte 的转变(统分为:体验设计师+创意设计师+用户研究),让这个本以为已经是行业常识的概念,又逐渐变得更加模糊。甚至因为少了职位(UI/UX)差异,我认为这个问题只会越来越严重,甚至会到最黑暗的时刻。

我常常觉得自己不善言辞,找不到合适的表达,准确的传递自己内心所想。幸运的是,我总能找到表达能力更好的人,说出我的心声。

以下文字为我的翻译文,原文地址:https://devblogs.microsoft.com/premier-developer/ux-is-not-ui-but-ui-is-definitely-ux/

继续阅读“UI 是 UX 的充分条件”

对于「用户研究」的常见误解

– 本文章属于 Fight for User Research 系列 –

英文原文:uxmatters.com/mt/archiv

用户研究(User Research)虽然已非常成熟,但对于用户研究的价值,以及具体如何通过用户研究方法去理解用户,挖掘用户需求,业界仍旧存在一些常见的误解和迷思。

误解 1: 用户研究总是能提供惊艳的发现。

刚接触用户研究的人,总是对于用户研究本身抱有不切实际的幻想,认为通过这个方法,就能找到未被发现的重要事实,惊艳四座。有时候为了说服客户或项目组增加用户研究环节,我们通常会不自觉地夸大其作用和效果,以至于对方产生不切实际的期待。

真相:用户研究的核心价值是提供有用的信息,其中有可能会包括一些惊艳的洞见。用户研究确实有可能会揭示一些之前没有发觉的,但又非常有价值的信息,但通常而言,其揭示的事实很可能都是一些常规的,甚至跟你之前的个人猜想和假设相符合的。项目组成员由于长期投身于业务之中,对用户有自己的理解和认知,所以要么他们会高估自己的认知,并把这些认知用于辅助自己做决定;要么他们会认为这些是常识,不具备任何价值。用户研究揭示的那些事实,则恰好是平衡这两种极端情况,让项目组成员更客观冷静地看待事实。

用户研究的目标不是去挖掘不为人知的惊人秘密;用户研究的目的,是帮助我们更好的理解和认知我们的用户:他们的目标是什么,他们使用什么样的工具,以及他们的工作环境。这些事实无所谓是惊艳的还是已知的,对于后续做设计决策都是非常重要的支撑。

误解 2:用户研究可以指导我们该如何设计。

提供设计决策的依据,跟提供直接的设计方案还是有很大区别的。而用户研究的作用是前者,不是后者。

真相:用户研究是提供有价值的用户信息,帮助产品设计师更全面的了解和认知用户,它并不能提供解决方案。解决方案需要结合用户研究提供的信息,以及其他相关信息(市场数据、行业数据、人类学数据,等等)做出综合的判断。设计方案是迭代出来的,不是用户调研出来的。

误解 3:用户研究就是随机搜集用户的常规信息。

用户研究之前,我们往往不可能知道我们会拿到什么样的信息,所有很多新手用户研究员会先入为主的认为,用户研究就是搜索用户的常规信息,看到什么就记录什么。

真相:用户研究之前,请明确你的调研目的。没有明确调研目的话,你会发现可被记录的信息实在太多了,到最后可能就是一堆信息,不知道如何下手。当然,理论上来说,提前去收集所谓的全部信息是可行的,前提是你提前定义好信息的结构,以备后续使用。但从实际情况来看,我们通常在有限的预算、有限的时间内去搜集有限的用户的信息,所以一定要提前设计好你的调研,你希望获得用户哪方面的信息。比如工作环境是什么,比如用户自己是如何解决某个难题,等等。

误解 4:用户研究就是去问用户他们想要什么。

有的人会认为,用户研究就是去问用户他们想要什么,遇到了什么问题,以及他们期待的解决方案。这种方式更像传统软件开发商做需求及市场调研的做法,他们会在这个过程中去咨询用户对新功能的意见和反馈。但用户研究不是这样的。

真相:用户研究旨在探索用户需求。用户研究过程中,我们确实可以看到用户的明确诉求,但不是通过直接提问的方式,而是在我们采访和观察中用户在真实坏境中的行为看到的,但这些结论不是目的,而是素材,最终帮助我们去推理用户的真正需求,然后我们根据用户的需求去设计产品,之后再通过可用性测试来验证我们的假设和解决方案。

用户研究强调观察法和采访(interview),而不是问答(ask),因为问答存在以下缺陷:

1)用户很难准确口述自己的行为,所以不如真实的操作来得准确和直接。

2)用户不具备提供解决方案的能力。他们非常了解自己遇到了什么困难,但他们不知道该如何解决。

3)对于潜在的需求,用户也几乎不太可能给出有效的反馈。这完全需要用户自己靠想象去揣测自己是否会遇到这个困难,以及这个新功能能否解决这个想象出来的困难。

用户研究通过自然观察法,挖掘用户的潜在需求;通过访谈,更好的了解用户的处境。两者结合后,我们再去做产品设计,以解决用户痛点,满足用户需求。

误解 5:不要听用户的,用户研究没用。

如果你认为用户研究就是问用户他们遇到了什么困难,他们想要什么的话,确实限制了产品设计的创造性。但用户研究不是,所以也自然不会限制设计师的创造力。

真相:用户研究提供生产资料,生产资料促进生产,而不是限制。用户研究不能直接得出结论,而是去搜索有用有效的信息,所以它并不妨碍创造性地提供解决方案。老话说得好,「需要是发明之母」,需求促进创新,而不是限制。

误解 6:不要听用户的,用户研究没用。

正如前面所说的,用户很难觉察自己真的的需求是什么,也很难自己想出解决办法来,所以会有人提出较为极端的言论,即:「不要听用户的」,以至于后续发展为「用户研究没用」。有一些设计师信奉自己的判断,觉得根绝自己的诉求去做设计就可以了,且常常引用乔布斯以及福特先生的名言来证身。事实上,「不要听用户的,用户研究没用」是一种误导。

真相:我们探索的是绝大多数人都受用的方法和框架,所以用户研究的价值不可忽略。与其说「不要听用户的」,还不如说「不要只听用户的」。聆听,是用户研究中很重要的一个手段,我们仔细听用户描述他们遇到的困难,他们在操作过程中的情绪变化,等等,随后深入思考背后的含义和真实诉求。拿福特的案例来说的话,我们可以先观察用户如何骑马车,以及问他们为何需要一匹更快的马,以反推出他们想要快速到达某个地方的诉求,从给发明公共交通或者私人汽车。

误解 7:用户研究耗费太多,也耽误时间。

磨刀不误砍柴工。有时候我们无法推进一个设计方案,不是因为方案本身不够好,而是大家内心对用户的需求没有达成共识。各自怀揣自己的假设去评估一个方案,当然很难达成一致,且止步不前。

真相:对用户的正确认知,是一切的基础。用户研究确实消耗资金和时间,但反反复复无意义的讨论,导致项目延期,本质也是一种高成本的消耗。消耗不可怕,关键在于投入产出比是否划算。用户研究本身不是目的,而是手段,一套成熟的方法和框架,帮助我们更好的理解和认知用户。如果项目组不愿意花时间去做所谓的用户研究,那么也需要花时间找到一个可以达到同样目的的替代方法。

误解 8:用户研究就是可用性测试。

刚开始接触用户研究的设计师,往往最先接触到的是可用性测试。就会形成用户研究=可用性测试的错误认知。

真相:用户研究包括但不限于可用性测试。也许设计师们都有这个常识,即可用性测试只是用户研究的一个部分,但并非所有人都这么理解。认为用户研究=可用性测试的,也许大有人在。所以设计师除了执行用户研究以外,对外科普用户研究也是一个重要的责任,只有当我们的合作伙伴,上级,客户真正理解了这套科学的方法,他们才能理解为什么用户研究是从项目立项就开始,一直延续到下一个迭代。

误解 9:实地研究能够 100% 还原真实的状况。

实地观察用户在实际环境中如何工作和生活,肯定会比邀请他们到实验室更真实。但实际情况来看,当用户知道自己正在被观察或记录的时候,他们的表现往往会异于平常。

真相:请用户研究员们一定记住,即便是不干涉用户为前提的实地观察,也是有别于用户的常规表现的。一定要保留这个意识,尽最大可能做好 0 存在感,并且辩证地看待一些易于常规的状况。

误解 10:用户研究嘛,做做总比不做好。

如果你无法说服项目经理实施一套完整的用户研究,那就做个简单的问卷调查也行啊,做做总比不做好,说不定会收集到有价值的信息。

真相:say no is a better choice。实施一套完美的用户研究方案,依赖天时地利人和,所有有时候会走捷径,或做阉割版。但这是一个风险很大的事情,耗费常规用户研究一半成本的调研,拿到的数据不一定就是有效数据的一半。如果你遇到了这样的情况,尽量说服负责人预留完整的用户研究方案所需的时间,如果不行,索性不作更好,不要给非专业人士留下一种,随便做做也是做的错误印象。

扫除迷思,正确认知用户研究才是王道。

让客户或项目负责人充分理解用户研究的价值,并设定合理的理性的期待,是用户体验设计师启动用户研究前必不可少的功课。意识到用户体验重要性的人,越来越多,但他们以为的用户体验,可能跟专业领域定义的用户体验有偏差。市场给了体验设计师发挥的机会,但设计师万不可自己乱了脚步,坚持科学的、专业的做法,才是长久之计。

系列文章:

产品策略可行性测试


原文:

Jim Ross, 2015, 10 User Research Myths and Misconceptions.

拓展阅读:

Isabelle Peyrichoux, 2020, 10 Best UXmatters Articles on Foundational User Research.

产品策略可行性测试

– 本文章属于 Fight for User Research 系列 –

可用性测试几乎耳熟能详,但产品策略可行性测试,可能会稍显模式。但从随着产品和设计工作结合越来越紧密的现状来看,后者显得越来越重要。那么问题来了,如何执行产品策略可行性测试呢?

答案:以可用性测试框架为基础,只需稍微改动一点点即可。

产品策略可行性测试 v.s 可用性测试

测试产品策略的可行性,跟测试设计方案的可用性,是完全不同的。产品策略可行性测试通常在项目前期,设计正是开始之前,用以探索整个产品大方向的可行性;可用性测试则是对于特定任务的,鉴定其用户体验的方式,通常在设计开始之后。

产品策略可行性测试与可用性测试在测试方式上非常接近,所以我们只消稍微改动一下,就能完成。但设计师必须非常清楚这两者的本质差异,避免在执行过程中走偏。

为什么要用快速原型去测试产品策略可行性?

  1. 一个快速原型,可以帮助用户在操作中更好的表达自己的诉求。纯文字的抽象沟通对用户而言门槛太高。
  2. 快速原型成本低,迭代快,适合前期的探索。
  3. 几乎所有人都希望设计师尽早给点东西出来,索性一举两得。

执行框架

1:1 的定性调研通常都遵守相同的框架(图1),产品策略可行性测试与可用性测试相比,存在以下 2 点特殊性:

1)访谈:你需要去设计一些能启发用户回答更高层次的问题,而不是可用性层面的。

2)任务还原准备(测试任务的设计):不做提前预设。

图1

具体执行建议如下:

设计策略依托于产品策略,产品策略是一切后续工作的基础。不管是用上述的方法,还是借助其他方法论,设计师通过科学的用户体验研究方法,提前介入产品和业务,推进项目往正确的方向挺进,都是用户体验设计价值的范畴。

系列文章:

 

 

参考资料:

Michael Hawley, 2012, uxmatters.com/mt/archiv

拓展阅读:

Isabelle Peyrichoux, 202010 Best UXmatters Articles on Foundational User Research.

Your design works or not?

“用户体验度量也不是啥新话题了,我也知道 HEART 模型(Happiness, Engagement, Adoption, Retention, Task Success),PULSE 模型(Page views, Uptime, Latency, Seven-day active, Earnings)。他们都很好很强大,但我真的就想验证下我的设计方案到底有没有 work,这一个小小的心愿能不能满足啊?”  — 内心独白

设计交付质量体现在 过程 结果 上。过程包括:对需求的理解,对问题的解析,设计方案的探索,设计表达,项目内协作等等,但最终我们还是需要通过结果去验证设计方案

目标 核心任务 指标(Goals – Key Tasks – Metrics,简称 GTM)模型主要用于验证设计方案的可行性,解决单一问题。 GTM 的特点:

  • 以 Task Success 为核心思路
  • 只涉及用户行为纬度

GTM 相对于成熟的 HEART,PULSE 模型等,逻辑更简单,可操作性也更强。GTM 既是个人工作经验所得,也受谷歌团队的一篇论文[1]的启发,具体如下:

目标

任何一个产品或功能的迭代,都应该有自己的核心目标,无论是产品上的或用户体验上的。比如:「全局导航统一」项目,目标是兼容所有的企业级应用;「项目分组创建流程优化」项目,目标是降低邀请分组成员的门槛。通常而言,目标需要业务方和设计师一起设定

核心任务

核心任务核心任务核心任务来源于目标,是帮助我们验证目标是否达成的核心论据核心任务的难点在于任务的拆解和选择,一定要是关键的任务(不一定是重要的任务),好比建筑中的承重墙。以「全局导航统一」为例,核心任务拆解如下:

  1. 用户通过左上角返回首页
  2. 用户通过 Dock 切换应用

指标

如何验证核心任务是否达成可?可以从 结果行为路径 两个纬度去设定指标:

结果指标:用户是否顺利完成了核心任务?

具体分以下三个指标去考核:

  1. 效率:用户是否在预期时间范围内完成任务
  2. 完成度:用户是否完整的完成了任务
  3. 失败率:用户操作失败的比率

行为路径指标:用户的行为路径与「理想路径」差多少?

设计师需要为产品或某个功能设定一条理想的操作路径。产品上线后去追踪用户实际的操作路径,再与「理想路径」做对比。通常而言,偏差越大的用户,产品使用过程中则越困惑、效率也越低、成功率也越低,用户体验也就越差。

If an optimal path exists for a particular task(e.g. A multi-step sign-up process) it is possible to measure how closely users follow it.[2]

备注:有的情况下,用户的真实路径很可能是「理想路径」,这个需要具体问题具体分析。

 

继续阅读“Your design works or not?”

UX 交付质量评估模型

[1]:本次需求属于什么类型?以产品逻辑、数据、还是技术为主?设计活动在整个项目中起到的核心价值及比重是什么?
[2]:站着整个产品视角看,这次设计是否存在可用性问题。
[3]:就当前设计本身看,是否存在可用性问题。
[4]:客观完整的理解和看待自己的设计产物,预判设计风险点。比如上手困难、不适合小白用户,等等。
[5]:体验指标分宏观指标及相关指标。宏观指标比如 NPS(任何一次设计活动都不该降低宏观指标);相关指标特指本次需求涉及的指标,比如转化率,等等。

附:UX 设计能力金字塔

我个人对 UX 设计师的能力抽象分为三块:分析能力操作能力陈述能力。分别映射为更为抽象的思维框架设计方法论设计表现。思维框架和设计方法论是基建,是一个设计师的「硬核」能力;设计表现可理解为设计素质,比如设计评审技能,设计管理能力,等等。