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

 

 

TeambitionUED 2018 设计方法年鉴

项目时间:201812 – 201903

我个人是设计方法的推崇者,实践者,探索者。我深信设计方法可以帮助更多的人达成设计目标。

于是我发起并主导了「设计方法年鉴」的项目。我带动所有的设计师一起,整理了过去的 2018 年里整个设计团队使用的设计方法和设计理论。

我主要的贡献领域为:设计分析和设计练习。2019年,我希望可以在「设计练习」上继续探索下去。「磨刀不误砍柴工」是我专研设计练习的核心理念。

年鉴目录

  • 用户体验地图
  • 核心流程梳理
  • 基于用户故事的用例
  • 图解抽象概念
  • 最小可行产品
  • 可用性测试
  • 交叉共建
  • 设计评审
  • 实验室
  • 单词卡片
  • 产品特性脑暴
  • 情绪板
  • 直觉设计 v.s. 拼凑设计

👇立即下载

TeambitionUED 2018 设计方法年鉴

任何个人或组织,如果需要使用该手册,请务必联系我本人。手册最终解释权和使用权归 Teambition UED 团队所有。

项目总结请戳这里

PROTOTYPE

在我的认识范畴下,设计应当属于原型阶段的工作,属于过程,而非结果。

好比工业设计,从一开始的概念草图,到最后的泡沫或油泥等等的 1:10 或 1:1 的模型,甚至到最后能够直接运行的零部件组合体,都应该属于原型产品。说回网页设计,从手绘草图到视觉高保真,甚至到前端/后端 mock 数据跑流程的时候,我认为都是原型阶段。

很久没有再提及这个词。昨天偶然间看到 youtube 上某个介绍高科技马桶的视频,讲解员在讲解功能原型的时候,称呼整套零散部件  prototype,触动了我。

对呀,这才是原型啊,而如今我们在讨论原型的时候,我们又在讨论什么。这不由得让我再次回忆我个人的交互设计经历,以及目前身处的环境,实在让人遗憾。

原型产品的目标

可以看下视频中,该马桶的原型介绍:

由于该马桶属于高科技产品,每个部件的功能实现和设计,都可能是难题。所以当整个产品的概念已经确定之后,分工调研必不可少,而调研结果可行性的最佳方法之一,就是原型测试。

从视频中可以看出,该高科技马桶的粪便储蓄仓、干湿分离、液体存储、回收、固体处理、人工蓄电等几大关键功能,都在原型中做了体现。而这个原型,完整的实现了整个马桶想要达到的效果,我们关注功能的可行性,我们关注整体的状态。这个时候的我们,暂不关心缺点,暂不关心外观。

如果说这是工业设计既定的「老套」流程,那么互联网产品的研发呢?很多人可能都还没有意识到,所谓精益创业、敏捷研发、MVP 等等概念,本质就是在映射「原型」。当然,这个原型是相对于未来完整的产品功能而言的。但往小了说,即便是在 MVP 的工作方式中,交互设计、前端设计本质也应该配合走完原型阶段的。但考虑目前行业的现状,这个步骤基本就省略在用户体验层面了,或者说,省略在交互设计画的粗糙的线框图上了。

如果能是这样,也很不错,但是…

目前交互设计俨然已不在原型阶段

很可惜的是,身边很多交互设计师包括我自己,目前被要求的都是一次性交付尽可能精细和完整的设计方案。这没有错,但我很担忧。我猜有不少近几年入行的交互设计师,第一份交互文档都是 Sketch 精心排版后的效果,甚至从来没有画过所谓的粗糙的线框图。久而久之,肯定会有人觉得交互设计就是去掉颜色的视觉设计以及交互视觉没必要再分开,blabla…非常让人惋惜。

直到偶尔问题出现,可能会有人反思

最近在做一个表格,虽然目前有类似的功能在线上,但本次有一些微调。直到提交测试的前一天,前端同学还在讨论实现方案,以及某些难题似乎根本就不能来得及了。这件事情,也不得不让我反思,并继而想到了过去常常挂在嘴边的 fancy 词:prototype。

我相信有很多工程师应该是有这个思维的,部分交互设计师也有,但 stakeholder 却往往没有,以至于在整个产品从 0 -1 的过程中,瀑布式终究占了大头。

交互设计师,原型设计师,用户体验设计师?

交互设计属于用户体验设计的一环,交互设计师可以做原型设计,原型设计师可以 fake demo,界面的、实体的均可。原型设计保证产品可行性,用户体验保证产品可用性。What a tricky world~ 希望有一天,我能在原型的基础上,去做更好的用户体验工作。

上海:阴雨