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 的充分条件”

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?”

如何「设计驱动」

公司最近计划将设计师们独立出来,成立 UED。独立部门之后,大家讨论最多的,则是在不依赖产品部门的情况下,如何体现设计的价值。

咋一听似乎是个老生常谈的话题,但在不同的公司文化、业务下,这个问题确实需要被重新思考和解决。

不要喊口号

设计师们在讨论这个话题的时候,反复提到 Design Thinking、设计驱动等字眼,我个人认为都太像口号。

喊口号不具备可操作性,打完鸡血之后仍然一脸懵逼,不知从何下手。我们不需要口号,我们需要的是「操作手册」。

动之以情不奏效,必须晓之以理

以用户为中心的设计本身并不是抽象的概念,而是可重复实践的工作方法。如果周围的合作伙伴认为用户体验设计是抽象的、感性的,那么「动之以情」往往只会遭来背后的白眼。

与其苦口婆说的念叨「我们是从用户角度出发的,用户真正的需求是xxx,这样的设计更符合用户心智模型」(依托于大家有相同的知识背景才能达成的共识),还不如以「具体的设计方法指导我们做选择,以线上数据论证我们的设计」。

越是 UXD-unfriendly 的工作环境,越应该注重方法和结果,而非「意识层面的影响」。

往后走

如果我们把 UXD 分为三段,以用户为中心的调研、以用户为中心的设计、以用户为中心的测试。那么对于 B2B SaaSUED 更能发挥价值的,可能在后面两段。

越往前肯定越好,这个道理我们都很懂,这也是最高理想,但迫于工作运作模式,我认为后两点是设计团队可发力的突破点。

· 以用户为中心的设计

设计团队的交付物可能仅仅是线框、视觉、动效等等,但其设计过程中涉及到的范围,应该拓展到这个用户的所有可体验到的流程中。

这不是对能力的要求,这是对职责的要求。每个设计师(不管 junior 还是 senior)都按照这个方法去工作。

可实施的方法有:体验大图
每次新需求来的时候,以最宏观的视角看待需求本身,同时又是绝对的用户视角。

· 以用户为中心的测试

这应该算是 UED 最在行的了,但少有公司设有用户研究人员,也少有公司愿意花时间做发布前用户测试。我不是理想主义,我非常理解公司的利益关注点。

所以「单纯谈理想讲道理」将再次不受用,但结合数据分析,将会是非常有效的方法。

继续阅读“如何「设计驱动」”