mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-16 22:23:45 +08:00
mod
This commit is contained in:
231
极客时间专栏/体验设计案例课/量化的体验评估模型/11 | 设计师的能力水平可以量化吗?.md
Normal file
231
极客时间专栏/体验设计案例课/量化的体验评估模型/11 | 设计师的能力水平可以量化吗?.md
Normal file
@@ -0,0 +1,231 @@
|
||||
<audio id="audio" title="11 | 设计师的能力水平可以量化吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/06/6c/06a02fc84f29d9fcde7988d69cabb06c.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
在上一个模块,科学的体验设计实操里,我们学习了体验设计的一些工具,以及工作的方法。在接下来的模块中,我们就要开始进入到我们的重头戏——体验量化了。
|
||||
|
||||
有朋友留言说 ,学习这个课程就是想看下只能凭感受的体验是如何被量化的。
|
||||
|
||||
从某一种角度来说,**万物<strong><strong>皆可**</strong>量化</strong>。比如,疼痛虽然是一种感觉,但是就可以被粗略量化。用户可以根据疼痛等级表,结合自身的感受和表现给出一个分值,帮助医生诊断情况。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/19/a3/19472aayyd4fd7f767b7413a47a7b8a3.jpg" alt="">
|
||||
|
||||
体验也是。跟体验相关的人、物、场景都可以通过类似的方法被量化。那么,给体验设计做量化的目的是什么呢?其实,就是**为了在不确定性中获得更多的确定性**。
|
||||
|
||||
如果我们能用量化的方式,给设计师的能力做个定级,那么我们在面试设计师的时候,我们就会有更多的把握。同时,我们还可以用这种方式,来审视自己身上的能力和不足。
|
||||
|
||||
今天,我们就着重讲讲设计师的能力怎么量化,方便你对齐自己能力以及有意识提升某块能力。
|
||||
|
||||
## 设计师能力模型
|
||||
|
||||
针对设计师的能力量化,我们总结了一个全面的设计师能力模型。在行业里,一般会将能力分为三类,分别是**通用能力、专业技能和组织建设**,每一类下面又细分更小的能力项。
|
||||
|
||||
接下来,我会带你一起分析每一个小项的定义,以及量化的标准。不过,有一点需要强调,在我们的体验团队,按照角色来划分,会有三个角色,交互、视觉和用研。
|
||||
|
||||
岗位角色不同,能力象限也是有区别的,我们这一讲主要以交互设计师为主。
|
||||
|
||||
## 通用能力
|
||||
|
||||
我们先来看通用能力,通用能力就是在我们团队,无论哪个岗位都需要具备的能力。一般我们认为包含以下四种能力:**沟通能力、解决问题能力、执行力、项目管理能力。**
|
||||
|
||||
### 沟通能力
|
||||
|
||||
用一句话来定义设计师的沟通能力就是,**能否有效传达设计方案。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/24/51/245606735feac2715e497f4bb2757551.jpg" alt="">
|
||||
|
||||
有了定义,有了分值,那我们怎么针对设计师在沟通能力方面,进行一个打分呢?
|
||||
|
||||
下面我举一个例子来说明沟通能力的评分。团队里分别有两个设计师,小A和小B。
|
||||
|
||||
小A每次讲设计方案的时候,开门见山直接讲设计方案,会说一些卡片式提高效率、风格国际化之类的词语,听起来很高大上,有时候也能够直接获得协作方的认可。
|
||||
|
||||
但是经常会有一些分歧,例如产品关注的是效率,如何提高当前页面的流量分发效率,而小A强调这样的布局体验更好,点击范围大之类的,经常出现沟通不同频的情况。
|
||||
|
||||
而设计师小B,他会从现有的产品问题开始说起,然后抛出自己的问题,设定一个设计目标,提出解决方案,并且给出验证解决方案有效性的指标。整个流程下来,不仅通俗易懂,而且给人的感觉,目的性也很明确,其中还不乏专业的视角和理解。
|
||||
|
||||
根据这些典型的表现,你觉得谁的沟通能力更强?是小B,小A只是做到了主动地传递设计意图,但是并没有站在客户或者用户的角度上,而小B显然是更关注实际问题。
|
||||
|
||||
最后,我们给的分值是小A在沟通能力的得分是3分,而小B的得分是8分。
|
||||
|
||||
### 解决问题能力
|
||||
|
||||
我们再来看通用能力的第二项:解决问题能力。我们同样用一句话来定义这种能力,就是**设计师能否发现并解决问题,解决的是哪种问题**。根据这个定义,我们同样可以得出一份评分表。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/6b/8f/6bae61e261939b1b609e86690e8a608f.jpg" alt="">
|
||||
|
||||
下面,我们还是以设计师小A和小B为例子,说明解决问题能力的评分。
|
||||
|
||||
设计师小A在工作中只能发现一些设计层面的小问题,例如没对齐、风格不符合规范,差个icon等等之类的视觉层面的问题,而且他也能够解决这些设计层面的小问题;
|
||||
|
||||
而小B,他往往能够发现一些关键流程背后的问题,例如小B就能够敏锐地找出某个页面的设计不符合整体规范。在解决这个问题的时候,他也并不是机械地按照规范调整页面。
|
||||
|
||||
他会思考这个页面不符合规范的原因是什么,是特殊场景的缘故还是由于设计师的失误,然后根据判断出来后的原因,再决定是直接调整本页面还是优化规范。
|
||||
|
||||
所以,能不能发现问题,并不足以证明一个设计师的能力,如果一名设计师能够找到关键问题所在,甚至是帮助产品和企业发展的方向性和战略性问题,才是更有实力的体现。
|
||||
|
||||
根据这些典型的表现,小A的得分是4分,而小B的得分是6分。
|
||||
|
||||
说完了沟通能力和解决问题能力,还有执行力和项目管理的能力,因为后两个比较容易理解,所以我就不做过多的展开,但是你可以对照我给出的评分表,评价自己其余两项能力的分数。
|
||||
|
||||
### 执行力
|
||||
|
||||
关于执行力,我们的定义是:**完成预定目标及任务的能力**,包含完成任务的意愿,完成任务的方式方法,完成任务的程度。我们又可以把完成任务分为完成个人任务和团队任务两种。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bc/b9/bc10ee138d02ae7c773254e088d883b9.jpg" alt="">
|
||||
|
||||
### 项目管理能力
|
||||
|
||||
项目管理能力的定义是,能否有效安排和合理分配时间,明确需求的轻重缓急,了解和关注项目内外合作人员的整体节奏,整体运用资源,达到解决问题的最大化性价比目标。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ea/19/eaa1fc5dfa8e92ab3a34c171fac95719.jpg" alt="">
|
||||
|
||||
## 专业技能
|
||||
|
||||
专业技能方面,我们会分为**设计定位、设计技能、设计实施、设计总结**四个能力。但是,因为设计师岗位不同,对能力的描述会有些许的不同。接下来,我们以交互设计师为例。
|
||||
|
||||
同样,我会重点拆解设计定位和设计技能两项能力,设计实施和设计总结部分我给了评分表。
|
||||
|
||||
### 设计定位
|
||||
|
||||
设计定位这一项能力,主要看的是**设计师能不能明确产品的商业目标定位**,拆分重点交互设计任务并制定设计目标,有商业化思维和成本控制意识,具备一定的业务大局观。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/aa/aa/aa86f1eaeacc619328aca40170eb9caa.jpg" alt="">
|
||||
|
||||
我们还是以交互设计师小A和小B为例子,进一步说明下怎样进行设计技能能力的评分。
|
||||
|
||||
交互设计师小A在工作中,非常熟悉业务的逻辑,面对一些不合理的需求也能够有效地与需求方进行讨论,并且推动这个需求的合理化。
|
||||
|
||||
在流程设计中,他能够串联起来前后端的多个关联系统,保证流程逻辑的完整性,对于他人交互设计稿的评审中,能够一眼就发现逻辑问题。他总是能够把产品需求、用户流程、页面设计等方面串联起来做有效的沟通,而需求方往往也会非常接受他在交互设计上的建议。
|
||||
|
||||
而交互设计师小B,他会遵照已有的流程规范完成对应的交互设计输出,但他在思考逻辑和流程的时候往往局限于一个具体的模块,缺乏一些全盘的项目视角。
|
||||
|
||||
根据这些典型的表现,你会怎样给交互设计师小A和小B打分呢?
|
||||
|
||||
我们给交互设计师小A的评分是6分,给小B的评分是4分。
|
||||
|
||||
### 设计技能
|
||||
|
||||
设计技能这块,你可能会认为是专业技能的能力项,比如说实际操作水平,但其实设计师和设计师之间的操作水平相差的不多,能力差异的背后主要是意识方面的差异。
|
||||
|
||||
比如说,是不是对产品所属行业/用户/场景有充分了解,能不能灵活运用交互设计和客户体验设计思想与方法达成设计任务,是不是具备一定的用研操作经验及交互表达能力。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/17/f4/177ac2f2c3255241b31447229f05d3f4.jpg" alt="">
|
||||
|
||||
下面,我们还是以交互设计师小A和小B为例子。
|
||||
|
||||
在我们的一个新产品签约的交互设计中,交互设计师小A会遵循之前存在的相关产品签约的交互规范,使用正确的控件、流程等,完成该模块的交互设计输出。
|
||||
|
||||
针对一些已有规范未覆盖的场景,小A也能够结合已有的规范进行相应的调整。
|
||||
|
||||
而交互设计师小B面对已有规范未覆盖的场景时,不但能够结合规范完成新场景的交互设计,还能把新出现的设计梳理成规范,并把新抽离的规范补充到已有规范中去,对其他模块形成复用。
|
||||
|
||||
最后,我们给交互设计师小A的评分是4分,给小B的评分是6分。
|
||||
|
||||
### 设计实施
|
||||
|
||||
设计实施比较容易理解,就是指设计师能否利用工具/方法/流程等,高效完成设计目标,甚至是达成商业目标,能否呈现设计带来的推动或结果影响,并有一定的交互设计创新能力。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f5/0c/f5f147cbaf96b146a826487efdbf410c.jpg" alt="">
|
||||
|
||||
### 设计总结
|
||||
|
||||
设计总结看的则是,设计师是否具备交互设计标准化思想,能否注重设计效率与统一性,能在工作中总结设计师项目过程,形成交互设计规范,包括组件,设计模版,可变模块以及流程效率优化等等,并有明确的应用方法与案例。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/0c/b2/0c663bc37117cab588d5bdabcdb8c9b2.jpg" alt="">
|
||||
|
||||
## 组织建设
|
||||
|
||||
我们来看最后一块组织建设能力,也被分为三个项:**知识沉淀**、**<strong>人才培养**</strong>、**工作态度**。
|
||||
|
||||
### 知识沉淀
|
||||
|
||||
和专业技能中的设计总结不同的是,知识沉淀针对的是更大范围、更抽象的理论梳理。
|
||||
|
||||
一个有知识沉淀的设计师不仅能够通过项目总结出相关设计经验或工作方法,并通过各种方式分享给团队,帮助团队成员的专业能力提升,还能够聚焦于行业内外的先进经验,充实自身。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/8a/3e/8a1523023d3cb21ab0bedcf66db0273e.jpg" alt="">
|
||||
|
||||
小A是我们团队中的一个特别乐于总结和分享的设计师。他经手的每个项目结束后,他都会做项目总结,同时结合业界内的优秀可复用的例子,以PPT的形式在团队中做分享。
|
||||
|
||||
他会把他在项目中遇到的困难、解决办法、设计思考、得出的可借鉴经验、学习的例子等,跟团队做一个很好的交流,并且团队的其他人每次听了他的分享后都会觉得收获颇多。
|
||||
|
||||
小B也是我们团队的一个优秀的设计师,但他就不太擅长做项目的总结和分享,他的设计输出是没有问题的,但你如果让他把在这个项目中的收获分享下,他只是会进行一些简单的设计结果的陈列,对于背后的思考却很难展示出来。
|
||||
|
||||
我们给设计师小A的评分是6分,给设计师小B的评分是3分。
|
||||
|
||||
### 人才培养
|
||||
|
||||
人才培养,从字面就很容易理解,指的是设计师在工作中会不会主动帮助他人提升专业能力或者提供发展机会,帮助他人的学习与进步。这项能力也很重要,决定了设计师能走多远,能否有晋升的空间,经验是否可以复用给他人。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a4/bc/a4b4966431fa2b1d74fd5b099d1a66bc.jpg" alt="">
|
||||
|
||||
小A和小B都是我们团队中的资深设计师,他们都各自带了一个项目组。
|
||||
|
||||
在平时的工作中,面对他人在项目中遇到的设计问题,小A通常的做法是直接给出设计方案的指导,直接指出他人在设计方案上的问题,帮助他人完成设计方案的正确输出。
|
||||
|
||||
而小B遇到这种问题,他不会直接给出设计的结果方案,而是会带着设计师回过头去分析这个项目的对应需求,看是不是在需求分析和切入点的选择上就出现了问题。
|
||||
|
||||
他们会一起先看设计背后的问题,再看设计方案的问题,而且在调整设计方案的时候,小B仅仅是给出思路,具体的方案还是由设计师自己来执行。
|
||||
|
||||
久而久之,我们就发现,相对于小A团队的设计师,小B团队的设计师能力提升的更快一点。
|
||||
|
||||
最终,我们给设计师小A的评分是4分,给设计师小B的评分是6分。
|
||||
|
||||
### 工作态度
|
||||
|
||||
工作态度,就是根据上级管理者的期望合理完成任务,包括能够站在项目视角看待工作任务,主动思考,主动推进,超出既定范围也会积极承担。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/45/92/45b3f14baca0cff9b5a74c6556002992.jpg" alt="">
|
||||
|
||||
根据上面的能力细项拆解以及分值的划分,我们初步可以把设计师分为5个等级。也就是从D1到D5,我们通过一个能力雷达图就可以非常直观地看到了。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/fd/69/fd61f77cce98bc987cd3ae1037501269.jpg" alt="">
|
||||
|
||||
按照这种方法,你就可以根据公司的**实际情况**对设计师的能力项进行一个分类、定义、拆解,多个维度的分值加在一起,给设计师所有级别应该有的能力项定义一个范围值,就可以得出当前设计师的设计级别。然后就可以对设计师的能力进行评估,给出更科学、合理的定级。
|
||||
|
||||
慢慢地,设计师的晋升通道也建立起来了。你定义好能力和级别的对应,设计师可以比照着进行自查,看看自己的能力项哪里需要补充,由此追问下去 ,这个能力项怎么补充?什么方式?一点一点的深挖,一点一点的进步,大家用自己看得见、能反馈的方式突飞猛进,于设计师自己与团队而言,都是特别好的事情。
|
||||
|
||||
到了年终考核,可以比照这个表格,做一条暗线 :业务贡献、专业贡献、团队贡献。倘若整个组织是一个强行政管理组织,我们可以根据每个级别定义一个基准分数,通过打分的方式,这样每个人会得到一个自己级别与基准分数的偏差值,这样就可以一键对整个团队进行绩效排名了。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/30/de/305325664abf9068169937d34850e0de.jpg" alt="">
|
||||
|
||||
## 业务对设计的诉求
|
||||
|
||||
这一块是我们设计师团队自我的要求,也是设计团队负责人管理设计团队时候的一个相对量化的依据。那业务方对我们的要求是什么?其实和上面的能力模型大同小异。
|
||||
|
||||
**首先,<strong><strong>是**</strong>高效的、高品质的出图</strong>!对于业务方来说,我们首先是一块资源。大部分的业务方对设计的“偏见”就是画图的,那么高效、高品质的出图就是我们能展开愉快合作的第一步。
|
||||
|
||||
**其次,是洞察**!能快速地get到业务的核心诉求,并能快速拆解业务流程,形成业务流程图,甚至在收到需求的第一时间就能在白板上生成关键页面。最好还能先于业务方洞察到用户的需求。
|
||||
|
||||
**最后,是好沟通**!技术类的设计师有自己的专业理想,会坚持自己设计的定义。从设计师层面上来说,是在坚持设计的理想,但是我们设计师并不直接对KPI负责。
|
||||
|
||||
本着谁担责谁决策的原则,我建议有分歧的时候,按照自己的想法出一个方案,按照业务方的需求出个方案,说清楚设计的逻辑,将决策权交给业务方。对方会觉得你好沟通,还一切为他着想。这样,未来的合作就会越来越顺。
|
||||
|
||||
最后,总的来说,初级和高级设计师最大的区别是什么?其实,如果单看输出图的话,初级和高级的差别没有特别大,**最大的区别<strong><strong>就**</strong>是思路,也就是拆解业务的思路</strong>。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b8/91/b892ac6501a6a7423c0a9c79cc8e9691.jpg" alt="">
|
||||
|
||||
高级设计师输出的东西也会左右反复,但是是有序地在往最优目标迭代进化;初级的就比较随机,思路比较混乱。给别人的感受是不稳定,可靠性有待提升。
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,我们对设计师能力进行了量化,提出了一个能力模型以及对应的能力象限图。我们把设计师的能力分为了三类,分别是**通用能力、专业技能和组织建设**。
|
||||
|
||||
其中,通用能力指的是每个岗位都要有的能力,像是沟通能力,解决问题能力、执行力和项目管理能力。可以说,不光是设计师,每一个“打工人”都要注重通用能力的培养。
|
||||
|
||||
而到了专业技能,则更多地指向设计师的本职专业,从设计定位、设计技能、设计实施到设计总结,在设计的每一个环节里,做事的细节和逻辑的差异就是设计师能力的不同。
|
||||
|
||||
另外,如果一名设计师的目光不止放在自身的岗位,他能够自觉地进行知识沉淀、人才培养,有一个好的工作态度,那么他的职场晋升之路就会越来越顺,空间会越来越大。
|
||||
|
||||
虽然每一项可能只有两三分的差异,但是积少成多,最终的总分就会拉开一定的差距,让设计师形成不同的等级。当然,排等级这件事不是为了搞排名,重要的是**通过量化的方式,认识到自己的不足,找到自己努力的方向,而不是一味地迷茫,踌躇不前**。
|
||||
|
||||
## 练习题
|
||||
|
||||
通过这一讲的学习,根据设计师的能力量化模型,你能评估一下你大概在什么级别吗?接下来,你打算往哪个方向努力呢?
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
200
极客时间专栏/体验设计案例课/量化的体验评估模型/12 | 如何用量化手段判断需求的优先级?.md
Normal file
200
极客时间专栏/体验设计案例课/量化的体验评估模型/12 | 如何用量化手段判断需求的优先级?.md
Normal file
@@ -0,0 +1,200 @@
|
||||
<audio id="audio" title="12 | 如何用量化手段判断需求的优先级?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c4/86/c43fefe0aa7fbcb42c74fa4eb1d51786.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
在你的设计师日常工作中,不知道你有没有听过下面这些话:
|
||||
|
||||
- “需求内容我已经澄清完了,你评估一下UE和UI的交付时间吧。一共4天?太长了吧!”
|
||||
- “你为什么不先处理我这个任务呢?不就是一个很简单的需求吗?”
|
||||
- “我这个需求很急,能帮忙赶紧安排一下吗,我看你们设计师人很多啊!
|
||||
- “昨天的需求设计稿做完了吗?还没有?还要内审?你们的效率也太低了吧!”
|
||||
|
||||
是不是很熟悉?而且每次听到这种话的时候,是不是心里都有“一团火在烧”。
|
||||
|
||||
在设计师的日常里,每天最疲于应对的是什么?是铺天盖地、源源不绝的并行**需求**,尤其是当我们面对多并发需求时,还没等开始处理,压力就已经产生了。
|
||||
|
||||
这不仅会影响我们的工作效率,还会让我们处于一种手忙脚乱的焦虑状态。上一个需求还没理清楚协作方是谁,下一个需求就来了。最后,To do list上一列又一列的待办事项,让人看着就心累。
|
||||
|
||||
所以,对于设计师的工作,我们有没有什么办法可以结构化的梳理需求?或者,我们该怎样判断需求的优先级,系统地从设计的角度去做我们的需求管理呢?
|
||||
|
||||
这一讲,我们就用**量化的手段**来解决这些问题。
|
||||
|
||||
## 想清楚再动手:需求评估
|
||||
|
||||
### 该不该做?——需求价值评估
|
||||
|
||||
想要管理好需求,第一步要做的就是**对需求进行评估**,想清楚需求要不要做,再动手。
|
||||
|
||||
还有不要做的需求吗?是的,不是每一个需求,都值得你耗费宝贵的时间和心力。我们要做,就要做那些有价值的需求,那什么样的需求才是有价值的需求呢?
|
||||
|
||||
我认为,需求是否有价值要看两方面,**一个是<strong><strong>商业价值**</strong>,另一个是用户价值</strong>。商业价值很好理解,就是可以为公司带来利润,而用户价值指的是,可以帮助到用户解决问题的需求。
|
||||
|
||||
接下来,我们可以利用“商业价值与用户价值象限图”来对需求的价值进行快速评估。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/92/7c/9268e0b1486ee17d6b62ddbfa898507c.png" alt="">
|
||||
|
||||
从这个图里,我们能看到,第一象限的需求,商业价值高、用户价值高,是明确可以做的。
|
||||
|
||||
第二象限的需求,有着一定的商业价值,但用户价值低,无法满足用户的价值,用户不使用的话,就不会带来商业价值。所以,是不建议马上做的,建议重新思考用户价值再着手。
|
||||
|
||||
比如说,新做一个App,这个App还没有建立标签系统,用户行为数据也是0。为了获取到更多的用户信息,在首次进入App时,就设定了一连串的内容让用户选择,且无法跳过。
|
||||
|
||||
虽然对企业来说,这些数据是很有价值的,但强制性的操作对用户而言是很反感的,且用户无法马上感受到利益点,用户对这个App失去了兴趣,对产品而言是更大的损失。
|
||||
|
||||
我们再来看第四象限的需求,有着很高的用户价值,但是商业价值很低,是需要谨慎考虑的。就像提供一个免费的功能给用户,但是需要投入30人/月,投入产出比是很低的。
|
||||
|
||||
最后,第三象限的需求,很显然,商业价值和用户价值都很低,这种需求就不需要做了。
|
||||
|
||||
做一个小总结,我们要学会通过价值维度来评估需求要不要做。高商业价值、高用户价值的需求必须做;高用户价值、低商业价值的需求要谨慎考虑;低用户价值、高商业价值的需求建议重新思考了再做;低商业价值、低用户价值的需求不要做。
|
||||
|
||||
有一种情况是你判断出这个需求低商业价值、低用户价值,但是老板坚持要做,而且还是打上**重要且紧急**的标签,做不做?还是那句话,**谁担责谁决策。**
|
||||
|
||||
### 先做什么?——需求清晰度评估
|
||||
|
||||
我们用“商业价值与用户价值象限图”评估了这个需求是否要做以后,一个来自灵魂的拷问就来了,“排除了一部分需求后,还是剩下很多。作为设计师,应该先做哪个需求呢?”
|
||||
|
||||
我的理解是设计师应该介入到需求的每个阶段。与其说先做哪个需求,我倒是觉得,我们可以反过来思考**在需求的每个阶段,设计师都应该做什么**。
|
||||
|
||||
当设计师知道在需求的每个阶段该做什么事情之后,就可以解决“我先做哪个,先做什么”这个问题了。那每个阶段,设计师应该做什么呢?首先,我们要先了解需求都有哪些阶段。
|
||||
|
||||
按照**需求的清晰度**来区分,分别是“从零开始的需求、沙子需求、板砖需求和钻石需求”。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/94/83/94e66388cc42798607f07697ebaa0f83.png" alt="">
|
||||
|
||||
我来逐一地解释一下
|
||||
|
||||
首先,**从零开始的需求**是指只有需求的意向,需求清晰度在25%以下。需求所涉及的具体功能模块、流程、边界都是空白的,这一切都是需要进一步详细讨论的。
|
||||
|
||||
在这个阶段,我们的重点工作是明确战略层与范围层的内容。也就是说,设计师要与产品/业务一同参与到需求的初期讨论与规划当中,了解战略层的目的,为范围层的内容提供意见。
|
||||
|
||||
这是需要一个需要**深度思考**的阶段,不是一时三刻就可以完成的事情。
|
||||
|
||||
比如说,公司决定要给企业手机银行做一个“记账”功能,你需要去了解这个记账功能的业务目的是什么?是为了吸引小微企业和个体工商户来提高新客数,还是为了获取小微企业的资金流向与经营情况以推出这类客群的贷款/理财产品呢?
|
||||
|
||||
然后基于业务目的再去拓展思考这个功能需要有什么,怎么用、谁用、怎么吸引别人来用等。
|
||||
|
||||
第二种是**沙子需求**。也就是已经有初稿需求,需求清晰度在26%-70%。这个阶段的重点工作是需要明确需求的结构层内容。设计师要做的是参与到需求的流程梳理当中。
|
||||
|
||||
在这个阶段,设计师也不需要着急于画图,可以结合前几节课我们说到的体验地图等工具来协助我们梳理需求的相关流程,包括产品地图 、业务流程、使用流程、系统流程。
|
||||
|
||||
比如说,我们要做一个语音转账的功能,我们就要先基于用户使用语音的场景梳理使用流程,梳理系统前端与后台、与语料库、与客服中心等系统的交互流程等。
|
||||
|
||||
第三种是**板砖需求**,是不是听起来很形象?板砖需求就是指需求的内容已经相对清晰,包括流程与功能,需求清晰度在71%-90%。这个阶段的重点工作是框架层的内容设计,是可以马上开展交互设计工作的(包括前后端交互流程、页面布局、页面跳转、交互细则等)。
|
||||
|
||||
比如说,我们要做一个保险产品,保险的细则和投保规则已经很明确了,那我们就可以动手设计前端的页面了,包括功能入口、保险产品的描述、投保填写流程、投保后查询保单的交互。
|
||||
|
||||
最后一种需求是**钻石需求**。也就是需求是在现有功能成熟的基础上做细节调整,需求清晰度在90%以上。这个阶段的重点工作是表现层的设计,例如增加提示语、调整表单内容顺序等。
|
||||
|
||||
这个阶段的设计工作内容是很轻的,职场新人就可以快速解决的,不需要长时间深度思考的。比如,把“账户余额”的功能修改成“查余额”,主要是做一些视觉方面的优化工作。
|
||||
|
||||
按照上面的四种程度需求,我们可以总结出两点:
|
||||
|
||||
- 需求清晰程度越低的需求,设计师需要投入的时间与精力是越长的,而且最好是整块的时间;
|
||||
- 需求清晰度越高的需求,设计师需要投入的时间与精力相对少,且可以并行。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/1d/d5/1d7b726f1c399a7c3e57bedabcd558d5.png" alt="">
|
||||
|
||||
也就是说,按照需求的清晰度和投入的程度来评估需求的优先级的话,我们要先快速解决“投入精力低和投入时间短”的需求,高效完成这个需求的设计交付,使需求进入下一个流程阶段。然后,我们再深度投入到“投入精力高和投入时间长”的需求当中。
|
||||
|
||||
当你完整地参与了一个需求的战略制定、业务范围框选、业务/产品流程梳理后,在后续的设计阶段,返工率就会有所减少,这也是一种很高效的工作办法。
|
||||
|
||||
## 怎么动手才高效:设计视角需求管理
|
||||
|
||||
我们探讨了以需求的价值、需求的清晰度来判断需求的优先级后,那么,在工作中,如果只按照这两点去执行的话,设计工作的执行与交付时效是不是就万事大吉了呢?
|
||||
|
||||
现实总是很残酷,即使我们明确了需求的优先级,先去做优先级高的、重要且紧急的需求,我们还是会收到其他关联协作方对设计交付的质疑。
|
||||
|
||||
- 为什么那么久?
|
||||
- 你们那么多人怎么交付这么慢?
|
||||
- 设计没给图 ,所以延期了。
|
||||
- ......
|
||||
|
||||
这是因为关联协作方并不懂设计,不清楚设计的流程、标准设计输出的交付时间、设计团队的人力安排等。
|
||||
|
||||
我们可以用“设计视角的需求管理”来解决这个问题。在确定了需求优先级的前提下,配合科学有依据的设计视角进行需求管理,就可以推动优先级高的需求的执行效率与有效落地。
|
||||
|
||||
下面我来给你说一下怎么通过“**拆解+量化+调配**”的方法来做设计需求管理。
|
||||
|
||||
### 拆解设计流程
|
||||
|
||||
在我们团队刚成立的时候,其他职能角色对设计师的工作流程与工作范围是一点都不了解的,全凭一个“猜”。为了让他们更深刻地了解设计师工作不是随意的,是科学的、可以量化评估的,我们细化了设计流程、透明化了设计进度管理。
|
||||
|
||||
传统的项目管理角度是这样安排的:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/53/36/538e94fdc59c5d3959cf7b6ac8bb2936.png" alt="">
|
||||
|
||||
而设计管理角度是这样安排的:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ab/5b/ab4c82ba07d2f6235b4065d74deb5b5b.png" alt="">
|
||||
|
||||
你可以对比着看一下,关键节点的差异在哪里。
|
||||
|
||||
其实,设计管理是基于项目管理角度的大基础上,对设计的流程进一步细分。作为设计师,我们都知道“设计并不是一步到位的”,但是,我们也要让其他角色的人都知道这个事情。
|
||||
|
||||
当其他职能认为这个需求已经很明确了,花一两个小时就可以搞定的时候,我们可以告诉他们,输出效率的确很重要,但**与效率并行的还有设计质量**。
|
||||
|
||||
我们把设计流程这样拆分,一方面正好说明了设计流程的严谨,也把设计流程的每个时间节点透明化于所有相关人,我们并没有在偷懒,也没有在拖延,我们只是专业且严谨。
|
||||
|
||||
接下来,我们再进行下一步,量化设计所需要的时长。
|
||||
|
||||
### 量化设计时长
|
||||
|
||||
就拿一个海报的设计来说,你评估过后需要2天时间,为什么会出现别人认为你不需要这么多时间呢?我认为最大的原因是,对方自身不是设计师,认为设计师的职责就只是画图,对设计工作的交付时间靠想象,觉得就是个图嘛,画两下就好。在不清楚情况的时候,没有客观评估设计所需时长。
|
||||
|
||||
那怎么来化解呢?我的方法是:**通过量化的方法把设计内容按照颗粒度预先进行时间评估,让对方有预知性,减少对方的猜测**。以下是我们基于运营设计的内容提前做好的一次交付时间量化:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2f/21/2f7c55f9f886f1f7a2aeaf5a0812c421.png" alt="">
|
||||
|
||||
同样地,我们也做了UE设计和UI设计的交付时间量化。别人一看,“哦~原来不同的设计内容是需要不同的设计时间的”,对于设计工作的评估,项目组内的其他成员也没有什么好质疑的了。
|
||||
|
||||
### 调配设计人力
|
||||
|
||||
设计的需求是源源不断的,需求的来源也是四面八方的,那么,如果一旦有了优先级很高的需求插入时,又应该怎么调配设计资源呢?
|
||||
|
||||
还是有办法的!我们会安排一张设计资源管理表,内容包括整个团队内,每个设计师在接下来一周的工作安排,即“设计师-哪天-做哪位产品经理的什么需求”。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/0d/aa/0d0d7082ff53b78a8050cd83b1a820aa.png" alt="">
|
||||
|
||||
通过上面的表格,我们就能很清晰地知道团队内的每一个设计师每天的需求内容,常规的需求我们也会按照这个规则一直排下去。
|
||||
|
||||
如果有优先级很高的需求插入时,我们会以这个表格为基础,结合“同一个版本所有需求的优先等级”+“设计师的专长能力”来进行调整。
|
||||
|
||||
还记得第11讲,设计师的能力怎么量化层级吗?结合设计师的能力,就知道这些需求应该安排给哪些设计师;
|
||||
|
||||
把优先级低的需求,暂时往后排;调配能力契合度高的设计师承接这份需求,以最合理的资源调配、最高效的效率完成优先级高的需求,提高设计人效,让设计资源最大化。
|
||||
|
||||
当然,我们会同步把关联的产品经理拉直进行沟通,多方达成一致在进行调整。
|
||||
|
||||
总结一下,**设计需求管理就是要学会拆解设计流程、量化设计时长,还要会调配设计的人力**。
|
||||
|
||||
是不是看起来有点像“军事化管理”?整个看起来就像是在排兵布阵一样。
|
||||
|
||||
这么严格,真的合适吗?其实,还是那句话,要看我们的目的是什么。我们的目的就是用量化的手段把设计流程、设计交付时间、设计人力安排做到清晰、可见、可控。
|
||||
|
||||
这样,是为了把控日常需求的设计交付时效,也能在优先级高的需求临时插入时,能更合理地安排与应对。而且,把设计需求管理做好,对于团队来说,可以更透明、更合理地安排和管理团队资源;对于外部,让关联协作方明白,原来做设计是如此科学、严谨又专业的一件事。
|
||||
|
||||
设计的质量和交付时间绝对不是拍脑袋说了算的,一切都是有理有据、合理的、有原则的。
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,我们探讨了一个每个设计师听到就会很“痛”的问题,怎么做好需求管理。
|
||||
|
||||
首先,接到需求时先不要着急动手,可以通过“**商业价值与用户价值象限图**”对需求进行价值评估。然后,我们再按照需求的清晰程度,把需求分个类,去衡量先做什么。
|
||||
|
||||
一共有四类,分别是“**从零开始的需求、沙子需求、板砖需求和钻石需求**”。我们要先快速解决“投入精力低和投入时间短”的需求,再深度投入到“投入精力高和投入时间长”的需求当中。
|
||||
|
||||
另外,在需求优先级已经明确的前提下,我们可以通过**拆解设计流程、量化设计交付时长、透明化人力情况**,采取灵活调配的方法来做设计视角的需求管理。
|
||||
|
||||
量化是一个很好的思维方式,在整个过程中,会助益我们做好设计师的需求管理。这不仅是为了自己、为了团队负责,更是为了向其他协作方证明设计师的专业和严谨。
|
||||
|
||||
对于生活,我们总是有一定的原则对事物进行分类、排序,目的就是让自己的日子更有秩序感、掌控感。在工作中,我们也同样需要这种掌控感,让自己的工作有条不紊,保质保量。
|
||||
|
||||
## 练习题
|
||||
|
||||
你最近做的需求是什么呢?可以用“商业价值与用户价值象限图”来评估这个需求的价值吗?这个需求是处于哪种需求清晰度呢?试着用我的方法来量化一下吧!
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
172
极客时间专栏/体验设计案例课/量化的体验评估模型/13 | 设计量化会把创意扼杀在摇篮里吗?.md
Normal file
172
极客时间专栏/体验设计案例课/量化的体验评估模型/13 | 设计量化会把创意扼杀在摇篮里吗?.md
Normal file
@@ -0,0 +1,172 @@
|
||||
<audio id="audio" title="13 | 设计量化会把创意扼杀在摇篮里吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ab/89/ab939210a0a305cec3a9c13f68940789.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
上一节课,我们探讨了用量化的手段去判断设计需求的优先级,以及如何用量化的方法科学地去做设计需求管理。今天,我们再次用量化来探讨另一个话题:**设计创意**。
|
||||
|
||||
在别人眼里,设计师是创意的爆发者,是自由的灵魂,是想象力十足的。但是每一个身处于商业环境中的设计师,总觉得自己的创意和灵感会受到限制,是带着枷锁跳舞,会服从于利润和效率优先的原则。
|
||||
|
||||
比如说,像上节课提到的需求管理、需求评估、设计流程、需求清晰度、交付时长量化,还有设计资源的有效利用等。这种规规矩矩的东西,是不是会限制设计师,把设计创意给扼杀掉呢?
|
||||
|
||||
创意,代表着情绪、主观,带有浪漫主义色彩,而数据、规范象征着理性、客观,充满了现实主义。好像自古以来,这二者就不可兼得,不能同时存在于一个舞台上。真的是这样吗?
|
||||
|
||||
别急,这一讲,我们一起来分析分析设计量化与设计创意之间,到底有没有矛盾。
|
||||
|
||||
## 什么是设计创意?
|
||||
|
||||
在分析这个问题之前,我们先思考一个问题,怎么理解设计创意?
|
||||
|
||||
可能每个人对创意的理解都不尽相同。我对设计创意的理解是:**新颖<strong><strong>又**</strong>实用的解决问题思路</strong>。
|
||||
|
||||
如果只能解决问题,但是丝毫不新颖,叫作老调重弹;但是,只有创意和想法,却不能落地,只能算作天马行空,**唯有真正落地的创意才叫作创新**。
|
||||
|
||||
在同时满足“新颖”与“实用”的两个基础条件上,创新又可以分成两个大类,一类是颠覆式创新,另一类是基于现有产品/服务的微创新。
|
||||
|
||||
### 颠覆式创新
|
||||
|
||||
颠覆式创新就是那些从来没出现过的新东西或者服务,带有革命性的变化,会改变人的习惯。
|
||||
|
||||
比如说,当年iPhone 3G的面世就是一个颠覆式的创新,是对手机的一个革命性变化,因为它重新定义了智能手机。作为一款触屏手机,它打破了持续了很长时间的手机形态规则,同时它还重新定义了手机的未来发展方向,掀起了智能手机的行业浪潮。
|
||||
|
||||
它既满足了人们的实用需求,又让人们惊呼,原来手机还能这样。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/9c/0b/9c5322752c14515129109332aa56670b.jpg" alt="">
|
||||
|
||||
iPhone 3G的惊艳除了乔布斯本身对手机产品的思考,当然也得益于技术的发展、3G网络的发展。就是这样刚刚好,网络更快了,人们更有钱了,触摸屏也就发展起来了。
|
||||
|
||||
颠覆式创新在满足实用的基础上,在产品形态、使用方式、或者服务模式方面会有很大的不同。但是,你也发现了,这种创新通常来说,可遇不可求,必须有天时地利人和。
|
||||
|
||||
### 基于现有产品/服务的微创新
|
||||
|
||||
什么是基于现有产品/服务的微创新呢?就是一些有趣的、实用的优化方案。
|
||||
|
||||
我们现实工作中更多接触到的也是这一类的创新方案。大多是基于某个成熟的产品的微创新,在腾讯每个季度就有一个微创新奖,专门用来奖励那些小小的有创意的点子或者有趣的方案。有的能落地到产品上,不能落地的就当成创新案例库积攒起来,等有需要的时候用。
|
||||
|
||||
这一类的创新听起来好像不够霸气,感觉跟设计师那蓬勃的、躁动的革命性创新形象不太契合。但其实,也并不是这样,微创新中的“微”代表的只是微小的改动,并不是微小的效果。
|
||||
|
||||
之前在银行就有一次项目的微创新经历。当时,银行业务中有很多功能是用户需要自己填写表单的,不仅仅要填写各种表单,还要上传影像资料。内容范围非常广,包括公司的名称、统一信用代码、营业执照、法人身份证、经办人身份证、手机号、房产信息等。
|
||||
|
||||
一连串的资料填写与上传给用户带来的体验很不好,用户可能会因为填写太多信息,上传太多零散的资料,临时中断或者放弃使用我们的产品,带来的后果就是直接影响到了业务绩效。
|
||||
|
||||
为了帮助业务绩效的提升,我们针对填写表单的功能,从交互上提供了一些创意点。
|
||||
|
||||
第一点,合并上传影像资料与填写资料的行为。即如果填写的资料是上传的影像资料中含有的信息,则用户不需要填写,只需要上传影像资料就可以了,上传完成后页面会反显文字信息。本来用户需要上传三个影像资料,填写八项信息,现在只要上传三个影像资料就可以了。
|
||||
|
||||
第二点,减少证件号等长串字符的手动输入。通过OCR的引入,用户只需要用摄像头拍下想要填写的字符串,系统就可以帮忙自动填写了,用户只需要确认就好。这一个小的改变,不但提高了用户的填写效率,还降低了用户手动输入的错误率。
|
||||
|
||||
我们还给这个方案取了个微创新的名字,叫作“智能填单”。
|
||||
|
||||
这个case,虽说不是什么惊天动地、前无古人后无来者的革命性创新点子,但是这小小的优化改动给产品的使用带来了很大的变化。提升了用户体验,减少了用户的流失率,带来了肉眼可见的业务价值。
|
||||
|
||||
也就是说,基于现有产品/服务的微创新虽小,但无论是对于产品的体验,还是给业务带来的价值。于两者而言,都是实用的,并且有效的。
|
||||
|
||||
说完了对创新的理解,我们回到今天的主题“量化会把设计创意扼杀掉吗?”
|
||||
|
||||
## 量化会扼杀设计创意吗?
|
||||
|
||||
在日常工作中,与设计创意和灵感相悖的是什么呢?应该就是“**数据反馈**”和“**设计规范**”这两种量化了吧!纵然你的创意再好,别的协作方也会让你拿数据说话,或者拿设计规范压你。
|
||||
|
||||
那么,接下来,我们就从这两个方向来寻求问题的答案吧。
|
||||
|
||||
### 设计创意VS数据反馈
|
||||
|
||||
听到数据这个词,是不是一下子就瑟瑟发抖了?甚至还会想,设计为什么需要为指标负责呢?
|
||||
|
||||
因为在大部分设计师眼里,数据更多可能只是一个KPI的考核指标,是一个硬性要求。有时,为了达到类似拉新、活跃类似这样的KPI指标,我们可能会做很多不太友好的产品设计。
|
||||
|
||||
就比如说,最常见的App启动页广告,它是一个比较好的提高产品商业KPI指标的工具,能在用户打开App的第一时间,就抓住用户的视觉关注点,而且还能带来一定的KPI价值。
|
||||
|
||||
但是这对于用户来讲,疯狂地看到不需要的广告是很反感的、不友好的,用户追求的是快速地启动App,看到想看到的内容,而不是看广告,而且有的时候还会不小心误点广告。
|
||||
|
||||
说个我之前项目中的小例子。我们有一款新的贷款产品,KPI指标是月申请人数达500人。
|
||||
|
||||
刚开始,我们把这款贷款产品投放在了App首页这个金刚位。这个贷款产品投放了2个月后,从数据来看,这款贷款产品的点击率仅占首页PV的3%,这个数据完全达不到我们预期的8%。是申请流程繁琐吗?交互流程不友好吗?还是App系统出问题了,有闪退的现象?
|
||||
|
||||
我们就开始深入分析数据,查了这款贷款产品的漏斗模型。我们发现从产品入口到申请成功的转化率是86%,也就是说,造成功能入口点击率低的原因并不是申请流程出了问题。
|
||||
|
||||
因此,我们就盯上了“功能入口”。
|
||||
|
||||
虽然这款产品申请处于首页的金刚位,但金刚位包含着8个功能的入口icon。也就是说,这8个功能放在一起,要发现这个贷款产品是有一定难度的。基于这个问题,我们把App入口的icon从静态改成了动态,并且加上了极具吸引的文案“**秒贷20万**”。
|
||||
|
||||
1个月后,从数据反馈来看,入口的点击率提升到了10%。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d3/75/d3ebbf3e3f8c5e7f428d9838b4dfca75.png" alt="">
|
||||
|
||||
从上面的例子可以看出,产品数据的反馈并不会扼杀设计创意。
|
||||
|
||||
相反地,数据反馈对设计师而言,也并不是一个硬性的KPI考核指标,它甚至可以帮助我们在设计时,获得创意的切入点,为设计创意提供依据、启发和机会。
|
||||
|
||||
所以,结论就是,虽然设计人不直接为指标负责,但是好的设计都是需要通过数据来证明价值的。不然,**再好的设计作品,不能获得市场的认可,也都只是在自嗨而已**。
|
||||
|
||||
### 设计创意VS设计规范
|
||||
|
||||
除了数据之外,很多小伙伴还会觉得,规范会限制自己的创意发挥。比如说:
|
||||
|
||||
- 为什么列表的信息一定要有分割线,如果不要分割线是不是会更透气?
|
||||
- 为什么入口icon一定要线性风格,如果我用C4D的立体风格是不是更酷一点,更潮流一些?
|
||||
- 为什么成功提示一定要用弹窗表示,如果用Toast提示是不是更轻量化一些?
|
||||
- ......
|
||||
|
||||
我最近面试了不少的同学,大家的作品也集中放了一些设计规范的相关内容。但是,当我问及他们对设计规范的看法时,部分同学会觉得设计规范对自己的工作有一定程度的限制,感觉自己每天的工作就是堆积木,限制了设计创意的发挥,设计师的价值在慢慢变弱,甚至消失。
|
||||
|
||||
虽然这么说有点残酷,但是我想说,这样的想法是比较小格局的。
|
||||
|
||||
当你有了类似的想法,可能是因为你并没有想清楚设计规范的意义。
|
||||
|
||||
**设计规范是一个产品的设计语言,是搭建设计体系的基础**。设计规范的存在,可以保持产品的统一性,在众多设计人员合作的产品中,可以保证小伙伴间做出的产品有高度的统一性。
|
||||
|
||||
不光如此,设计规范还能提高团队的效率。针对同样的组件,我们只需要设计一次,设计阶段就可以直接复用,同样地,开发也不需要重复开发。**我们不能只停留在自身<strong><strong>闪光点的呈现**</strong>,要从更高的维度去衡量</strong>,例如产品价值、业务价值、产品效率、团队成长等。
|
||||
|
||||
你有试想过一个没有设计规范的产品是怎样的吗?
|
||||
|
||||
曾经,我们团队的产品就经历过没有设计规范的阶段,那简直是花样百出,令人乍舌。
|
||||
|
||||
当时,我们团队负责的是一个对公的门户App。在产品初期,要对接外部第三方的功能和内容,为了能够让功能快速上线面客,我们直接调用了对方的H5,也就是说,我们直接复用了对方的页面流程与样式,只在我们的产品增加了一个“功能入口”。
|
||||
|
||||
由于直接复用了别人的页面,导致了我们的部分相似功能在同一个App上呈现了两种完全不一样的交互与视觉样式。对用户而言,这产品的打开方式有点神奇,东一下,西一下,感觉不是在同一个产品里,给用户的体验十分不好,还带来了额外的学习成本。
|
||||
|
||||
这个产品还会给人的感觉简直是一个大杂汇。设计语言没有统一性,会导致用户对产品的品牌没有感知,很难记住你这个产品,还会感觉你们根本就不用心。
|
||||
|
||||
再说回贷款产品,我们的平台会承接不同的贷款产品,每个贷款产品的申请流程大同小异。
|
||||
|
||||
前期,每个贷款产品的交互、视觉、以及开发都是独立执行的,也就是每一个新的贷款产品都需要重新做一遍。无论是项目组还是设计师,我们都意识到了这部分重复性的工作,浪费了不少时间与人力。所以,我们决定把贷款流程做成规范化的、可复用的控件。
|
||||
|
||||
首先,我们汇集了现有全部贷款产品的申请流程,把申请流程进行拆分,分别是:**产品介绍环节、填写资料环节、身份验证环节、申请反馈环节**。然后,基于共性与个性的梳理,我们把贷款申请流程梳理成了一个标准的申请流程。后续如果有新的贷款产品,我们就以这个标准的申请流程作为基线,再按照对应产品的差异化进行调整。
|
||||
|
||||
无论业务梳理、还是设计、开发,效率提升了不止一点点。原来需要投入4天的设计时间,现在只需要2天就行,大大提高了效率。还保证了在同一个平台上,类似产品的操作流程几乎是保持一致的。对用户而言,即使是不同的贷款产品,但在整体申请流程上都是一致的,是熟悉的。
|
||||
|
||||
你看,有了设计规范后,设计师减少了一部分重复性工作的投入,设计师有了更多的时间和精力放在创新思考上,比如说如何激励用户来贷款,如何让转账用户产生理财操作等。
|
||||
|
||||
所以说,设计规范并没有限制设计师的自由,相反,对于一些已经形成固定用户习惯的元素,设计规范能够更好地保持用户体验的一致性,并且提升设计师在处理大量相似性设计的效率,**让设计师可以节省出大量的时间去投入到对设计创意的研究上**。
|
||||
|
||||
在这里,我再说一个之前发生在我们团队的故事。
|
||||
|
||||
在我们团队初期还没有设计规范的时候,有位小伙伴参与的需求都是比较类似的。这些需求的一个共同点就是“表单”,差异就在于表单内容的多与少,还有顺序。长时间的重复性工作让这位同学失去了工作的激情,也很容易暴躁,觉得自己作为设计师没有价值。
|
||||
|
||||
但随着这个产品设计规范的建立,这个小伙伴的重复性工作得到了释放,有更多的时间去思考产品的深度优化,以及行业内的创新点。他把平时积累的设计创意形成创新产品方案,然后去参加银行内的年度创新大赛,有两个方案都入围到了前20%,还获得了丰厚的奖金。
|
||||
|
||||
从上面这两个设计规范和流程规范的例子来看,规范性的东西不但不会扼杀掉设计师的创意,反而会释放设计师重复性工作的精力,为思考设计创意提供更多的时间和机会。
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,我们探讨了一个在每个设计师心里,都曾有过疑虑的问题,那就是设计量化到底会不会扼杀掉设计创意呢?答案是不仅不会,还会帮助我们在创意这条路上,走得更远。
|
||||
|
||||
首先,我们分析了什么是创新,可以分为颠覆性创新和基于现有产品/服务的微创新。无论是哪种,它们都有两个共同点,**一个是新颖,一个是实用**,是有一定的产品价值和业务价值的。
|
||||
|
||||
虽然颠覆式创新很难做到,但我们完全可以做一些微创新,“微”在于行动,并不在于效果。
|
||||
|
||||
接下来,我们基于工作中的一些微创新案例,从“数据反馈”和“设计规范”两个方面出发,分析量化对于设计创意的影响。量化不会扼杀设计创意,反而是一个辅助设计找到体验优化点的利器,一个帮助我们验证设计创新的有效价值的证据。
|
||||
|
||||
同时,设计规范层面的量化不仅可以满足用户的一些习惯的体验,还可以释放设计师重复性工作的精力,为设计师思考设计创意提供更大的空间。
|
||||
|
||||
所以,我们要让设计量化助力我们的创意想法和行为,而不是一味地投反对票。
|
||||
|
||||
## 练习题
|
||||
|
||||
你能尝试利用数据反馈,去寻找一下你现在所做产品/功能的创意启发点和切入点吗?或者是关于设计规范,你有怎样的理解与体会?来分享一下吧!
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
155
极客时间专栏/体验设计案例课/量化的体验评估模型/14 | 如何用量化的方式讲清设计价值?.md
Normal file
155
极客时间专栏/体验设计案例课/量化的体验评估模型/14 | 如何用量化的方式讲清设计价值?.md
Normal file
@@ -0,0 +1,155 @@
|
||||
<audio id="audio" title="14 | 如何用量化的方式讲清设计价值?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/04/89/040949613c016e508314a7f14e519e89.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
不知道你有没有这种感受,在设计师的工作中,有些时候,如果让你把设计方案做好,可能是一件相对简单的事情,但如果让你描述一下自己的设计能给项目带来多少价值,反而很难。
|
||||
|
||||
但是,问你设计重要吗,你心里又觉得,在现代社会,设计肯定会越来越重要呀!但是具体有多重要,你可能还是说不太清楚。这很正常,即便是领导发问,我们的设计可以给公司带来多少价值?
|
||||
|
||||
我们可能也不知道该从何说起,该说哪方面,是创意还是技法?是利润还是变革?
|
||||
|
||||
所以,在接下来的内容中,我会结合我在工作中的一些实际项目,给你分享一些用设计量化来正确描述价值的方法,帮助你讲清设计的价值,在工作中获得别人更多的认可。
|
||||
|
||||
## 设计价值,该怎么讲?
|
||||
|
||||
在分析如何讲清设计价值之前,我先来给你举一个例子,让你也当一次裁判。
|
||||
|
||||
前不久,我们的一个改版项目要做一次总结会议。其中有两名设计师的总结性描述非常具有代表性,我大概还原一下两位设计师当时的描述,你来判断一下谁在项目中起到的作用更大一点。
|
||||
|
||||
设计师小A是这样描述的:
|
||||
|
||||
在改版项目中,视觉上采用了更有创意、更符合审美潮流的C4D立体风格,视觉风格焕然一新;还优化了用户填写信息的流程,减少了用户手工填写的项目,提升了填写效率和用户体验。
|
||||
|
||||
对于小A的描述,你有没有觉得有点似曾相识?好像和工作中经常听到的差不多。我们再来听一下小C是怎么描述的,他先说了这样一句话,在这个改版项目中,我们主要做了两方面事情:
|
||||
|
||||
第一是整合项目流程,用户的操作步骤由原来的**5步<strong><strong>减少**</strong>到2步</strong>。通过增加一些自动化填写的方式,用户手工填写的信息也由原来的**10项减少到了4项**,用户操作的平均时长**减少了50%**;
|
||||
|
||||
第二是采用全新视觉风格,在视觉层面,塑造与竞品间的差异性。我们利用更具互联网视觉语言的C4D立体潮流风格,整体时尚、前卫,质感更轻量化,既契合了产品的便捷、轻量的诉求,又打造了产品清晰的品牌辨识度。
|
||||
|
||||
是不是设计师小C的描述更能让你明确地感受到设计带来的价值呢?因为他用了一些具体的数据,还完整地告诉了你,这些设计会产生怎样具象的实际效果。
|
||||
|
||||
这也是本讲的重点,**如何<strong><strong>整理归纳设计的价值,并且尽**</strong>量**<strong>用数字化的方式给别人讲清**</strong>楚。</strong>
|
||||
|
||||
可是,设计效果那么多,说不清道不明的,真的可以用数字来表示吗?怎样才能有条理地给别人讲清楚呢?下面,我将带你走进**三个实际项目**里,帮助你找到用量化方式讲清设计价值的技巧。
|
||||
|
||||
## 项目一:从成本视角讲设计价值
|
||||
|
||||
先来看第一个项目,是要给产品新增一个“产品签约”的功能。
|
||||
|
||||
当时,我们在业务部门组织了第一次的需求评审,技术部门做了一个整体评估,评估工作量是40人/月。按照当时的20个人来看,需要两个月的时间,才能完成开发。
|
||||
|
||||
但是,业务部门站出来说,等不了那么久,一个半月后就要开始使用这项业务,要是晚半个月上线的话,会影响到业务部门的业绩。所以,我们决定重新梳理一下业务需求。
|
||||
|
||||
然后,我们突然发现“产品签约“这个功能和我们之前做过的“综合签约”功能很相似。
|
||||
|
||||
现在“产品签约”功能业务想要的大致流程是:
|
||||
|
||||
>
|
||||
填写信息——远程核查——发起审批——预约网点——办理签约
|
||||
|
||||
|
||||
而已有的“综合签约”功能业务的大致流程是:
|
||||
|
||||
>
|
||||
填写信息——发起审批——远程核查——办理签约
|
||||
|
||||
|
||||
如果只关注大的流程节点,有两项业务非常相似。于是,我们就结合已有的“综合签约“的功能,把“产品签约”的大流程改成了先发起审批,再远程核查。
|
||||
|
||||
这样,就最大程度上复用了“综合签约”的相关功能模块。
|
||||
|
||||
重新设计流程后,我也找了对应的业务部门去做了一轮的沟通。他们也很认同我的方案,然后就按照我的方案又找了一下对应的技术同事,做了新的一轮需求评审。
|
||||
|
||||
按照这个修改后的方案,技术的评估是20人/月,这样的话,一个月就能搞定上线了。比业务要求的一个半月时间还能减少半个月,而且节约的这半个月给了业务部门更多的准备时间。
|
||||
|
||||
现在,如果让你跟协作方讲一下设计这次所作的贡献,你会怎么说呢?
|
||||
|
||||
通常地,我们会说,我们这次改了一下设计的流程,完成了一次输出。
|
||||
|
||||
但是,这样说根本体现不出我们的价值。协作方看到的可能只是设计表面上的工作输出,他们可能会忽略掉设计提出修改流程后,降低了整个项目人力和时间的成本。因为,你不主动说,别人是不会发现你做了什么、有多大效果的,而且别人也没有那么多精力去了解。
|
||||
|
||||
所以,你可以这样说,正是由于设计对业务的流程做了优化,把项目的人力成本由40人/月缩减到了20人/月。在现有项目组人力配置的情况下,上线周期才从预估的两个月缩减到了一个月,提前半个月完成了功能上线,为业务团队额外赢了半个月的准备时间。
|
||||
|
||||
职场都是算成本的,假设一个人一个月要2w,那我们为公司减少20人/月,是不是直接给公司节省了40w?上线周期变短,留住了核心客户,这个隐形收益又是多少?
|
||||
|
||||
你看,如果你进一步利用量化的方式这样表述“给项目整体节约了40W的成本,把上线周期缩短了50%”。这两点讲出来,而不是笼统地说“设计优化了流程,提高了项目落地的效率”。
|
||||
|
||||
这样,协作方是不是更能够认识到设计带来的价值呢?
|
||||
|
||||
## 项目二:从用户视角讲业务价值
|
||||
|
||||
第二个项目是一个对已有产品改版优化的项目。为什么要发起这次改版呢?最大原因就是我们收到了很多用户的投诉,大家吐槽说这个产品的线上申请很麻烦,而且很浪费时间。
|
||||
|
||||
为了得到更多、更详细的信息,我们还组织了一场用户可用性测试。在这次测试中,用户的平均满意度只有3.5分(7分满分),这种满意度可以说是非常低的了。
|
||||
|
||||
基于这些信息,我们对这个贷款产品的交互设计进行了两点比较大的改变:
|
||||
|
||||
- 一是舍弃掉原来流程中的一些不必要信息,把用户的步骤由原来的13步减少到6步;
|
||||
- 二是帮助用户自动填写已有信息,把需要手动填写的信息项由原来的23项减少到10项。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/61/81/617467424ac1f375aaaae56d41f88b81.jpg" alt="">
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f4/da/f4d5677ce974e9b7224806c2fb15f4da.jpg" alt="">
|
||||
|
||||
关于这个改版项目,如果你只是和协作方讲,“设计优化了整个产品的申请流程,降低了用户成本,让用户操作更加便捷”,这样别人反而对于设计的价值没有明确的感知。
|
||||
|
||||
其实在这个改版项目中,我们有很多能够明确展示用户行为的量化数据可以拿来使用。
|
||||
|
||||
- 用户的操作步骤由原来的13步减少到6步;
|
||||
- 手动填写的信息项由原来的23项减少到10项;
|
||||
- 这两项改变可以减少用户至少两分钟的操作时间;
|
||||
- ......
|
||||
|
||||
改版后,我们又做了一轮用户的可用性测试。改版后的测试结果显示,用户的满意度从原来的3.5分提升到了5.5分,比改版前提高了2分。这就是对设计价值的最有力的体现。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/90/80/9064f8351e01710e403ae43356276680.jpg" alt="">
|
||||
|
||||
## 项目三:从业务视角讲设计价值
|
||||
|
||||
接下来,我们来看最后一个项目,是一个单纯的视觉层面优化的项目,具体情况是这样的:
|
||||
|
||||
这是一款新上线的理财产品,在首页增加入口后,连续四周,该理财产品主页的周UV基本都在10w~11w之间。业务部门经常找我讨论,看怎样通过一些设计手法,进一步提升用户的访问量。
|
||||
|
||||
经过内部沟通了解到,这款理财产品最大的竞争优势是收益高达6.8%且随时可赎回。抓到这个点后,我们打算修改入口方案,把“收益6.8%以及随时可赎回”的关键信息在入口表现出来。
|
||||
|
||||
这样,在用户浏览首页的时候,就可以快速抓住目标用户的焦点,帮助用户快速做决策。
|
||||
|
||||
在新的入口方案替换上去之后,该理财产品的主页周UV就达到了13W+,比上周提升了18%。拿到数据后,我也第一时间询问了业务部门,看他们同期是否有在进行推广活动为该产品引流。
|
||||
|
||||
他们说,同期没有特别的推广活动,都是自然流量,这完全是设计层面的改动带来的数据提升。业务部门对这次设计的改动所带来的数据提升,大为赞赏,也打从心里认同了设计师的专业性。
|
||||
|
||||
当然,直接的设计改动带来的业务数据提升,是附加在产品竞争力之上的。如果没有产品的关键竞争力,入口设计的再酷炫也很难带来数据的提升。
|
||||
|
||||
**设计的价值一定是<strong><strong>通过**</strong>实现**<strong>业务价值**</strong>来成就的。</strong>
|
||||
|
||||
在这个项目中,我们直接用了设计修改前后的业务数据对比来证明了设计价值,这种业务数据的对比,往往是最直接、最粗暴的展示设计价值的方式。
|
||||
|
||||
但是在拿到直观业务数据的时候,你也有一点需要注意。你需要判别在业务数据提升的背后,其他协作方是不是有关联的动作,比如说重点功能迭代、运营推广活动、性能优化动作等。
|
||||
|
||||
如果他们有这些关联动作,你需要对数据的提升进行更细一步的拆解。还记得“[05 | 你会巧妙利用数据这个神助攻吗?](https://time.geekbang.org/column/article/334200)”吗?那节课中提到的GSM模型就可以帮助我们详细地拆解指标。
|
||||
|
||||
为什么这样做?很简单,功劳全部算在设计头上,其他职能方会觉得设计好大喜功,且过于不懂事儿了。另一方面,也是让我们清楚地感知到每一处优化带来的真实改变。
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,我们通过三个实际项目的案例,总结了可以帮你讲清设计价值的三个关键技巧。
|
||||
|
||||
第一,从项目**成本视角**出发,提取数据来证明设计价值,比如说设计对流程的优化、降低了多少项目的人力成本、缩短了多长时间的上线周期;
|
||||
|
||||
第二,提取一些**用户视角**的数据来证明设计价值,比如说获取用户成本的降低、用户学习成本的降低、操作效率的提升等,这些都是用户行为的表现;
|
||||
|
||||
第三,从**业务视角**入手,在一些能够直接拿到用户数据或业务数据的项目中,可以直接利用产生的数据来证明设计价值,同时要能够表达出设计和数据的直接关联性。
|
||||
|
||||
总的来说,就是不要只简单地描述设计做了什么,而是结合数据的方式,去把设计带来的结果展示出来,这样才能更好地讲清楚设计的价值。其实,我相信你也一定发现了,这三种视角不仅是我们讲清设计价值的三个切入点,更是我们提高设计价值、展示设计专业性的三个切入点。
|
||||
|
||||
从这三点出发,我们可以向其他协作方和leader证明,设计师不只是一个作图机器和出图工具。
|
||||
|
||||
## 练习题
|
||||
|
||||
除了我讲的这三种视角,你还有没有可以向别人证明设计价值的一些方法?欢迎你分享给我。
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
202
极客时间专栏/体验设计案例课/量化的体验评估模型/15 | 如何建立设计方案的验证模型?.md
Normal file
202
极客时间专栏/体验设计案例课/量化的体验评估模型/15 | 如何建立设计方案的验证模型?.md
Normal file
@@ -0,0 +1,202 @@
|
||||
<audio id="audio" title="15 | 如何建立设计方案的验证模型?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/68/cf/684b1yy5c6d28d3911419db63c8763cf.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
你有思考过这样的问题吗?作为一名设计师,你在公司的职责是什么?或者是,你认为设计师的任务到哪一步才可以算是完成了?在一个项目里,设计师究竟要对哪一环节负主要责任?
|
||||
|
||||
很多人认为设计师只是公司的一个画图员,只需要把设计任务完成并输出设计稿就可以了。
|
||||
|
||||
可是,这个设计方案有没有用呢?能达成业务的目标吗?能给业务带来多大的影响?而且,这个设计方案真的满足用户的需要吗?**设计师可能会觉得,这些好像都不关他的事**。
|
||||
|
||||
你觉得这样想,真的对吗?
|
||||
|
||||
在我看来,作为一名设计师,我是不太认同设计师的责任是只需要完成设计稿的交付的,这是一个不负责任的说法。设计师在企业内部属于资源项,服务于商业化的设计。职责就是要**赋能业务,达成业务指标**。同时还要承担着平衡商业与用户的责任,是需要为用户体验负责的。
|
||||
|
||||
所以,今天我要讲的就是,除了设计一个方案出来,你还要懂得**验证自己方案的合理性**。
|
||||
|
||||
## 为什么要验证设计方案?
|
||||
|
||||
那么,问题就来了,我们为什么要验证设计方案的合理性呢?我觉得可以分为两点。
|
||||
|
||||
**第一,为了给业务和用户带来价值。**
|
||||
|
||||
作为设计方案的输出者,你完全有责任去验证设计方案给业务和用户带来的价值。
|
||||
|
||||
更直白一点说,设计师应该要去验证设计方案有没有达成业务目标,为其他协同方高效又有效地解决问题;有没有满足用户诉求,为用户自然又舒适地解决问题。
|
||||
|
||||
那要是我们抛开设计验证,只是一直地做设计,会造成什么样子的后果呢?
|
||||
|
||||
我举一个类比。假设,我现在开了一家餐馆,但我只负责把食材放在一起炒熟给你吃。不管你对这道菜的评价是好吃还是难吃、卖相吸引不吸引、分量够不够饱......我就这么做,你爱吃不吃。
|
||||
|
||||
你也知道,这肯定是一个没未来的餐厅。厨师做出来的食物不能让食客满意,会导致餐厅没有生意;没有生意,餐厅就没有收入来源;没有收入,只有支出,餐厅迟早会经营不下去。
|
||||
|
||||
如果你是餐厅老板,你是不是会听取食客的意见,调整配方、优化菜品,来满足食客的预期?
|
||||
|
||||
设计也是同理。我们不能光一味地搞输出,还要适时地去收集用户的意见和建议,验证自己的设计方案,优化该优化的地方,确保我们的设计方案是真的可以帮助到用户。
|
||||
|
||||
如果仅仅是做了设计方案就算完了,不进一步地跟进我们的方式有没有效果,这种行为就是耍流氓,就像我在开篇词中说到的:“不解决实际问题的用户体验设计都是耍流氓”。
|
||||
|
||||
当我们满足了用户的需要,用户喜欢用、习惯用,产品自然也就有了更多的业务价值。
|
||||
|
||||
**第二,为了提高设计师的专业能力。**
|
||||
|
||||
这一点不用展开讲,你也懂。一个会去验证设计方案的设计师一定比一个只作图的设计师有更多的话语权,更了解市场的情况等,久而久之,他就会成长得更快,变得更加专业。
|
||||
|
||||
## 怎样去验证设计方案?
|
||||
|
||||
那我们该怎样去验证设计方案的合理性呢?这个合理性有没有什么可量化的标准呢?既然设计师要对业务和用户体验负责,那设计方案的验证主要就是验证两个目标:
|
||||
|
||||
- 验证设计方案有没有达成业务目标;
|
||||
- 验证设计方案有没有满足用户需求。
|
||||
|
||||
接下来,我会以工作上的一些项目为例,来跟你聊聊怎么去验证设计方案是否满足这两个目标。
|
||||
|
||||
### 用数据验证是否达成业务目标
|
||||
|
||||
一提到“验证”这件事,不知道你的脑海里第一时间出现的是什么?我的脑海里马上就飘过了“数据”这个词语。是的,没错,数据是目前来讲比较客观的检验和验证方式。
|
||||
|
||||
在平时的工作中,我们设计师会经常听说的数据指标也有很多,例如PV、UV、平均停留时长、新用户留存数、用户流失率、页面跳出率、完成率、转化率等等。
|
||||
|
||||
问题又来了,在这些数据指标里,哪些是和业务目标相关联的?换句话说,哪些数据指标对于我们来说,才是更有价值的?是每一项指标都要关注吗?当然不是。
|
||||
|
||||
**针对业务目标,要选择对应的关键数据,才是借用数据验证的正确打开方式**。下面,我就结合之前做过的一次运营活动,分享一下,该怎样选择数据指标来验证设计方案。
|
||||
|
||||
这个运营活动的背景是这样的:**为了给我们的A<strong><strong>pp**</strong>拉取更多的新用户</strong>,业务部门发起了一个“注册就送888元免息券”的活动。他们希望用这种利息减免的方式吸引更多新用户,并且让这些用户申请我们的贷款产品。一句话总结就是,**拉<strong><strong>新客、引贷款**</strong>。</strong>
|
||||
|
||||
在这个运营活动中,主要有两个节点:
|
||||
|
||||
- 一是用户只要注册就能够领取888元的免息券;
|
||||
- 二是想使用这个免息券,用户必须签约贷款产品才能使用。
|
||||
|
||||
根据这个流程的拆解,那我们现在知道了,对于业务侧来说,先让用户领取免息券,如果要使用券就需要先注册成新用户,但如果新用户不使用免息券贷款申请贷款,那这个新用户是没有贡献业务营收的;所以,只有用户使用了免息券进行贷款,业务才会有营收数据。
|
||||
|
||||
因此,对于我们设计师来说,我们的设计方案不但要考虑用户领取免息券的流程,同时也要考虑怎样刺激和引导用户去使用免息券去签约贷款产品。一个完整的活动流程是这样的:
|
||||
|
||||
>
|
||||
赠送888免息券给用户——用户领取成功——成为新用户——去申请贷款并使用
|
||||
|
||||
|
||||
通过这个梳理,我们发现,这个活动的初级目的是“拉新”,但**让新用户使用免息券进行贷款才是<strong><strong>最终**</strong>的目的</strong>。因为领券只帮我们拉来了新用户,用券才能给我们带来实际的业务营收。
|
||||
|
||||
所以,针对这次活动的设计方案的效果验证上,我们不仅仅要看活动点击数和免息券的领取数,同时还要看申请贷款产品的用户数。因为最终申请贷款的数据,才是本次运营活动的业务目标,也是验证我们的设计方案在贷款签约转化上是否有效的核心数据指标。
|
||||
|
||||
结合本次运营活动的业务目标,我们就构建了一个设计方案效果的指标验证模型:
|
||||
|
||||
>
|
||||
活动点击数>免息券领取数>注册的新用户数>申请贷款产品的用户数
|
||||
|
||||
|
||||
在完成设计方案,并投放了一周后,我们提取了一些关键数据,具体如下:
|
||||
|
||||
- 活动点击数是2813;
|
||||
- 免息券领取数是1769;
|
||||
- 新注册用户数是622;
|
||||
- 通过这个链接申请贷款产品的用户数是421。
|
||||
|
||||
通过上面的数据,我们可以初步分析得知,这个运营活动带来的新客用户数占领取免息券人数的35.1%,且仅仅占活动点击率的21.9%;这个活动申请贷款的用户数占领取免息券人数的23.7%。
|
||||
|
||||
因为这个活动的业务目标是“拉新+引贷款”,我们要同时关注新注册用户数、申请贷款用户数。
|
||||
|
||||
虽然业务之前定的拉新目标是30%,申请贷款目标是25%。现在35%的拉新率也算是达成了业务目标的,但是申请贷款的用户数还没有达标,也就是我们的设计方案任务还不算顺利完成。
|
||||
|
||||
那到底是什么原因导致贷款申请用户数这么低呢?基于这一点,我们又分析了申请贷款的交互流程,发现申请流程比较繁琐且系统不稳定,所以,我们针对贷款申请的流程做了一些优化。
|
||||
|
||||
优化上线的一周后,我们又提取了关键数据,看看拉新的数据有没有提升:
|
||||
|
||||
- 活动点击数是4128;
|
||||
- 免息券领取数是3298;
|
||||
- 新注册用户数是2973;
|
||||
- 通过这个链接申请贷款产品的用户数是1286。
|
||||
|
||||
现在,这个活动的拉新率从35%提升到了72%,申请贷款人数从23.7%提升到了39%。
|
||||
|
||||
你看,在本次运营活动的设计中,我们并没有简单把活动页的点击数和免息券的领取数当成验证模型,而是结合本次运营活动的目标,统计与业务目标强相关的数据作为验证,并通过数据反馈对设计方案加以调整,这样的验证模型才有意义。
|
||||
|
||||
### 用数据验证是否满足用户需求
|
||||
|
||||
讲完借用数据验证是否达成业务目标后,我们更不能忘了要验证是否满足用户需求。还记得我们在[第05讲](https://time.geekbang.org/column/article/334200),关于利用数据助攻我们的设计中说到的“转账优化项目”吗?
|
||||
|
||||
在整个优化思路中,我们提取了旧方案各类转账入口的点击率、从功能入口到转账信息录入页的转化率,对转账的功能入口做了整合、对转账信息录入的流程做了简化,减少了非必要性页面和干扰信息。
|
||||
|
||||
那我们是怎样验证我们合并转账功能入口以及优化的流程是符合用户需求的呢?首先来看一下关于转账入口合并的验证。
|
||||
|
||||
因为做了各类转账类型的入口合并,我们担心用户找不到被合并的转账类型。因此,我们借用了以下数据并做了统计:被合并的转账类型交易数、所有转账类型的交易数,同时我们再与优化前的被合并的转账类型交易占比做对比。
|
||||
|
||||
>
|
||||
即:优化前“小额转账”的交易占所有转账类型交易的7.2%;优化方案上线后,被合并的转账类型是“小额转账”交易数是32/天,所有转账类型交易数是472/天,占比是6.7%;
|
||||
|
||||
|
||||
也就是说,转账入口的合并没有影响用户对于被合并类型转账的使用,用户是能通过优化后的方案完成交易的,且与优化前无差。
|
||||
|
||||
其次,我们再来看一下关于简化转账信息录入流程的验证。
|
||||
|
||||
转账信息录入的优化目的是提高用户转账的成功率,以及提升转账流程的效率。所以,我们提取了从转账入口到转账成功页整个流程每个页面的PV,并制成漏斗模型,计算从功能入口到转账成功的转化率,然后再跟优化前的方案对比。
|
||||
|
||||
>
|
||||
即:功能入口PV是122237,选择转账类型PV是109854,信息录入页PV是76864,转账成功结果页是76212,转账率达62.3%,比优化前提升了30%;
|
||||
|
||||
|
||||
另外,我们也提取了“信息录入页”的停留时长,对比新旧方案用户在该页面所花费的时间。
|
||||
|
||||
>
|
||||
优化前信息录入页平均停留时长是42秒,优化后平均停留时长是28秒。
|
||||
|
||||
|
||||
通过这两个例子,不知道你有没有发现,为了验证是否达成业务目标和用户需求,我们都可以通过数据来进行验证。但是验证不同的内容,我们需要灵活借用不同的数据,这些数据不局限于业务数据、用户行为数据等。
|
||||
|
||||
有数据作为验证参考当然是个好事,那如果没有数据时,我们又该怎么去做设计验证呢?
|
||||
|
||||
### 巧妙采用可用性测试做设计验证
|
||||
|
||||
在新产品/功能上线前,大多数是没有用户数据的。这个时候,我们最经常用的就是可用性测试这个工具了。通过用户可用性测试的验证更偏向于验证“是否满足用户需求”。
|
||||
|
||||
我还是结合我做过的一个项目来给你讲一下。
|
||||
|
||||
当时做了一个PC平台的改版,这个平台已经三年没有优化过了。通过三年的功能添加,平台上的功能菜单非常的多,堆积现象很严重。当新用户来使用这个平台,就跟我们客服反馈经常找不到要用的功能入口。据客服部门反馈,**客户的40%问题都是跟找不到功能<strong><strong>入口**</strong>相关的</strong>。
|
||||
|
||||
所以,这次改版的一个核心任务就是对菜单进行再分类与排序,设计师按照自己对每个菜单内容的了解进行了业务属性的分类。菜单分类排序调整后,设计师就有了一个困扰“这是我对平台菜单内容的理解,跟用户对菜单内容的理解一致吗?”
|
||||
|
||||
为了验证新分类与排序是否符合用户的预期,我们直接邀请了几位用户来到现场测试,这次,我们不再是用惯用的demo进行验证,而是利用“卡片分类”来邀请用户一起参与到设计当中。
|
||||
|
||||
我们把所有的功能菜单写在了小卡片上,让用户自己理解菜单名称内容,并加以分类;通过3-4个用户的分类,再对比用户与我们的设计方案对比,把差异性大的分类与排序进行了调整。
|
||||
|
||||
这是一个快速又比较准确验证是否满足用户需求的方法,可以在没有数据的情况下完成设计验证。
|
||||
|
||||
当然,可用性测试的方法有很多,例如我们常用的用户访谈、问卷、Demo随机测试等。你可以根据项目的内容、需求紧急程度以及资源、预算等来调整可用性测试的方法。如果你对可用性测试的方法不是很深刻的话,可以回头再翻翻我们的“[08 | 你一个人怎么搞定可用性测试?](https://time.geekbang.org/column/article/336704)”。
|
||||
|
||||
我们可以借助数据、可以采用可用性测试,这些都是做设计验证的其中一些方法。在实际工作中,我们是可以根据项目所需而灵活变通的,根据实际情况采用一些合适的工具和方法,希望我的案例和采用的方法能给你带来参考价值。
|
||||
|
||||
最后,有一个问题,你可以思考一下。作为设计师的我们,看数据和产品经理以及运营经理看数据有什么不同呢?其实看的数据源都是一样的,只是关注点不太一样。
|
||||
|
||||
设计师看数据,主要为了验证**体验指标**的完成,验证当前版本用户跑出来的数据,是否符合设计目标,判断设计方案的有效性。
|
||||
|
||||
举个例子,如果把增强视觉效果作为提高banner位点击率的策略之一,那么banner的色彩搭配是否协调、构图是否巧妙、文案是否精准表达且有趣撩人,就成了验证策略的关键因素。
|
||||
|
||||
要记住,一个设计方案如果没被用户的行为跑出数据,那都是在自嗨。
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,我们探讨了关于设计方案验证的问题。
|
||||
|
||||
首先,从职责范围的角度来说,设计验证是设计师的本职责任,不做设计验证的设计方案不是一个完整的方案。设计验证主要也是为了验证是否达成业务目标、是否满足用户需求。
|
||||
|
||||
所以,我们验证设计方案,也要从业务目标和用户需求两个方面出发:
|
||||
|
||||
- 明确业务目标,不同的业务目标借助不同的关键数据来做设计方案;
|
||||
- 分析用户行为数据,借助用户在使用产品过程中的数据来验证是否满足用户需求。
|
||||
|
||||
这两种方法都是以数据作为工具,那要是没有用户数据呢?我们可以巧妙利用可用性测试,在没有数据时或产品上线前,通过可用性测试的结果反馈,来验证我们的设计方案。
|
||||
|
||||
总的来说,就是以数据或者测试反馈等意见为工具,以业务和用户为核心,来验证当前设计方案的合理性。持续地精进和打磨优化现有的方案设计,给产品增色。
|
||||
|
||||
希望今天的内容可以帮助你对设计方案给业务、给用户带来的价值做更深度的思考和探索。
|
||||
|
||||
## 课后题
|
||||
|
||||
你最近做的一个优化性需求功能是什么呢?试着分析业务目标,以及借助数据来验证一下这个设计方案是否达成业务目标,是否能帮用户解决问题。
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
165
极客时间专栏/体验设计案例课/量化的体验评估模型/16 | 产品体验的评估也可以量化吗?.md
Normal file
165
极客时间专栏/体验设计案例课/量化的体验评估模型/16 | 产品体验的评估也可以量化吗?.md
Normal file
@@ -0,0 +1,165 @@
|
||||
<audio id="audio" title="16 | 产品体验的评估也可以量化吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d9/b7/d9051d448918eeaa00fa5556e2f4f0b7.mp3"></audio>
|
||||
|
||||
你好,我是炒炒
|
||||
|
||||
在我之前与其他部门的一次协作中,我公司的CTO问了我很多问题:
|
||||
|
||||
>
|
||||
我是个典型理工男,不太懂你们这个体验专业,但我习惯用数据来判断。我经常听你们说产品体验好,为什么好呢?可以打几分?这种体验好可以用数据衡量吗?最好的是什么样的?可以打100分吗?我投入多少个体验人员是最划算的?如何评估这个投入产出多少价值?
|
||||
|
||||
|
||||
之所以我印象这么深刻,是因为我第一次被CTO提了这么多的问题。其实,他问的这些问题总结来说,就是在问一件事,**是否可以用量化的数据来评估产品的体验好坏**。
|
||||
|
||||
世界的万事万物都是可以被度量和评估的,我们的用户体验领域自然也不例外。
|
||||
|
||||
我们在学习“[08 | 怎样搞定一场可用性测试?](https://time.geekbang.org/column/article/336704)”的时候曾讲过,我们可以通过用户的可用性测试,使用相对量化的数据来帮助我们发现产品的问题,对产品进行迭代和优化。
|
||||
|
||||
这种可用性测试的方法是从**产品视角**,关注用户使用产品能否成功完成某些任务。
|
||||
|
||||
而用户体验度量是从**用户视角**,衡量用户使用产品或系统时的个人体验。它是一个更宏观的概念,强调的是用户与产品之间的整体交互,以及交互中形成的想法、感受和感知。
|
||||
|
||||
那么这种抽象的东西,真的可以度量吗?如何度量呢?
|
||||
|
||||
## 体验能度量吗?
|
||||
|
||||
我先给你举两个小例子。
|
||||
|
||||
当你用盒马下单后,系统会让你给骑手进行评分。评分体系包含速度、态度、时效等这样的指标,这个其实就是对体验的一个打分收集。打分的人多了,就会生成一个服务评分。平台通过服务评分,就可以知道这个骑手服务哪里好、哪里不好,如何进行结构性优化或者激励。
|
||||
|
||||
这个就是体验的量化拆解在日常行为中的一个应用。所以,体验是可以评分的、可以度量的。
|
||||
|
||||
大厂一般会有一个组织,专门负责给公司的所有产品进行产品体验的打分,用以帮助该产品进行体验优化。我们一般会从**可用性、<strong><strong>易用性**</strong>、满意度</strong>三个方面去打分,我称之为打分模型。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f4/6f/f4a6536cde4b16681c4e7b59f36ef36f.jpg" alt="">
|
||||
|
||||
一般来说,可用性看的是产品的基础功能是否过关,如果不过关的话,很有可能会影响到用户对产品的第一体验;而易用性更多地代表一个产品好,好到什么程度,差的话,又差成什么样子。
|
||||
|
||||
而满意度偏向于用户个人主观的一个感受,代表的是一种整体上给用户带来的感觉。这三个维度共同决定了一个产品给用户带来的体验的好坏。
|
||||
|
||||
那么,具体该如何利用打分模型去度量体验呢?主要分为五个步骤。
|
||||
|
||||
## 如何度量体验?
|
||||
|
||||
### 第一步:定范围
|
||||
|
||||
之前我有说过,我最近两年一直在做B端产品,所以C端的那种大范围随机发调研问卷或者走廊测试这样的搞法,对B端来说,性价比不是很高。B端系统大、复杂度高、模块多、岗位角色多 ,所以一般会先定范围。
|
||||
|
||||
就拿我们之前的企业网银这款产品来说,这个企业网银集合了五大业务中心的业务,相关功能模块有400个左右,涉及到的页面有3000多个。如果我们要对整个企业网银进行整体打分,那这个工作量太大了,而且还要协同不同的业务中心,整体推进起来的速度也会非常缓慢。
|
||||
|
||||
所以,我们根据不同的业务属性划分成了不同的范围,比如说转账、资金池、票据管理、跨境中心、理财等。
|
||||
|
||||
### 第二步:选竞品
|
||||
|
||||
这里你可以回忆一下我们的“[04 | 为什么你的竞品分析看起来像拼接抄袭?](https://time.geekbang.org/column/article/332325)”中讲到的,我们选竞品的方法。基于现有的目的,我们一般选**直接竞品**就可以了。比如说,我们要评估的是财资系统,我们会直接挑选行业里做的最好的财资系统,来进行模块的详细对比。
|
||||
|
||||
结合我们在上面提到的打分模型,我们可以把可用性、易用性和满意度对应我们的产品,做一个拆分。比如说,可用性分为是否满足用户需求、流畅性怎样、文案描述是否准确等等。
|
||||
|
||||
### 第三步:定规则
|
||||
|
||||
接下来,对于每个细项指标的评分,你可以采用五级量表的10分制评分。你可以根据自己的操作体验,给每一个细项进行评分。比如说,评分对应规则如下:非常不同意(1、2分)、不同意(3、4分)、一般同意(5、6分)、比较同意(7、8分)、非常同意(9、10分)。
|
||||
|
||||
比如说,如果你要转账,结果使出了吃奶的力气,转账都完成不了,那这个明显是“非常不同意”,1分都觉得多了,对吗?所以,就拿“满足用户需求”这个指标来衡量的话:
|
||||
|
||||
- 如果你觉得该产品提供的相关功能基本都能够满足你的需求,那你就可以选择“同意”或者“非常同意”对应的分值;
|
||||
- 如果这个产品只是满足了你的部分需求,你对该产品的态度既不喜欢,也不排斥,那你可以选“一般”这个分值;
|
||||
- 如果这个产品比较糟糕,不能够满足你的核心需求,那你就可以选择“非常不同意”或“不同意”对应的分值;
|
||||
|
||||
举个例子,假设你现在需要在app上进行转账,结果使出了吃奶的力气,转账都完成不了,那这个操作体验在“满足用户需求”这个指标上,明显是“非常不同意”,1分都觉得多了,对吗?
|
||||
|
||||
我总结了一个表格,给你列举了一下我在最近的一个项目中用到的产品体验分评估指标。这个表格针对的是一个金融类的B端产品,应该会给你一些更具象的参考。
|
||||
|
||||
当然,在工作中,你需要根据你所服务产品的实际情况不同进行指标的增减。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/58/0f/58e5231dd29e1552c10269164a3fb40f.jpg" alt="">
|
||||
|
||||
你可以根据自己的产品情况,设计自己的体验打分表。
|
||||
|
||||
### 第四步:走查打分
|
||||
|
||||
接下来,我们一般的做法,就是根据标准分模块,按照业务流程去走查打分。
|
||||
|
||||
为了保证最终打分的合理性,我们会在打分前给各位打分人**做一次宣讲**,把打分规则详细地讲一遍,如果有疑问的地方让大家现场讨论,这样可以使各位打分人对规则的理解更趋于一致。
|
||||
|
||||
对齐打分规则后,打分人对本次需要打分的模块进行依次打分,且彼此之间互不影响。比如,本次划定的打分范围是模块A、模块B、模块C三个模块,则每个打分人需要依次完成对这三个模块的打分。
|
||||
|
||||
这里要求走查的人员**对业务要很熟悉**,也就是需要基于懂业务的体验走查。不然发现的问题都是很浅层次的视觉问题。倘若发现的都是这样的问题,对于一个业务系统来说,就是**形式大于逻辑**了,收获不到对体验提升有决定影响力的、特别有价值的信息。
|
||||
|
||||
举个例子,我们最近做某财资平台的体验打分,发现所有的打分都是视觉表现层的一些扣分项,例如像素没对齐,弹框样式不统一这样的不疼不痒的问题,这对产品的体验优化起不了决定性的帮助,同时也显得体验问题都集中在视觉层面,应该由视觉设计师对体验问题负责。
|
||||
|
||||
溯源原因,就是因为走查打分的人员里没有加入业务人员,大家不懂业务流程,所以只能按照产品说明书点击,很难走进产品真实的使用场景里面去,很难发现产品真实的体验问题。
|
||||
|
||||
### 第五步:输出体验分值与建议
|
||||
|
||||
最后一步,就是输出体验分值和建议
|
||||
|
||||
通过以上流程的打分,我们就能看到每个评分指标的得分,那么怎么计算一个最终的体验分呢?
|
||||
|
||||
我们的计算逻辑是这样的:先把每个评分指标的分数相加,再除以评分指标个数,就能得到单个用户对该模块的体验分;然后把每个用户对该模块的评分相加,再除以参与评分的用户数,就得到了该模块的体验分。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/07/51/075f24e7511cf415e6b8878a35b8d051.jpg" alt="">
|
||||
|
||||
计算出来了体验分,你可能会有一个疑惑,在我们列举的打分指标中,为什么易用性的权重这么大,占了8个指标,满意度却只有1个指标?
|
||||
|
||||
这也是我正要提醒你的,我列举的这个表是针对我们自己的B端产品使用的评分表的局部,我们在体验评估中更偏重产品的易用性,所以会把易用性的指标权重设置的大一点。
|
||||
|
||||
在实际工作中,你可以结合产品的实际情况去调节可用性、易用性、满意度三个维度的权重,这样得出的体验分才更符合产品的需要。
|
||||
|
||||
当然,除了看总体的体验分,我们还可以对比看单一维度的体验分,比如可用性或易用性的体验分。数就是这么些数据,我们可以根据我们的需要灵活运用。
|
||||
|
||||
当每个模块的体验分计算出来后,我们又该怎样去对比分析呢?
|
||||
|
||||
通常情况下,我们会参考两个标准进行对比:**行业标准**和**自我标准。**
|
||||
|
||||
先来看行业标准,对于很多B端的产品来讲,可能你在市场上找不到比较通用的行业标准。那怎么办呢?你还记得在第二步中讲到的选竞品吗?假设我们选了两个竞品,那么参与评分的用户,同时会对竞品进行评分,这样,我们也用同样的逻辑计算出竞品的体验分。
|
||||
|
||||
再计算两个竞品的平均分,我们就可以简单粗暴地把两个竞品的平均分定义为行业标准。这样,我们就可以跟行业标准对比。倘若低于行业标准,那说明我们做的太烂了,需要深度优化产品的体验。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/0f/7c/0fd25fb5508f722c4e3e071b7dc72b7c.jpg" alt="">
|
||||
|
||||
再来看一下自我标准。互联网产品追求的是每一次都有进步,而不是完美。这就要求我们的团队要不断地对产品进行迭代优化。所以,这个体验度量的工作不是一次性的,也是迭代的。
|
||||
|
||||
那么,我们可以跟上个季度比,看看我们的分值有升高吗?没有升高的话也需要反思,是哪个模块的哪个要素分值特别低,我们就可以有针对性地进行优化。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/69/b4/692d6b6baa5d6ec0e899fbe69c724fb4.jpg" alt="">
|
||||
|
||||
通过体验分值来辅助产品进行优化决策,这样的决策才更有方向性和目标性。
|
||||
|
||||
## 体验度量的价值
|
||||
|
||||
通过度量,我们可以量化地知道,产品的体验好不好,好在哪儿?不好在哪儿?跟行业相比,我们是处于领先地位还是追赶者地位?用户体验度量的最终目标不在于度量本身,度量只是一种途径或方法,可以帮助你获取更多信息,以便做出更好的决策。
|
||||
|
||||
用户体验度量可以回答很多对组织来说至关重要的问题,以及其他方法回答不了的问题。比如:
|
||||
|
||||
- 用户会非常认同我们产品吗?
|
||||
- 这个新产品的使用效率会高于当前的产品吗?
|
||||
- 与竞品相比,这个产品的用户体验如何?
|
||||
- 这个产品中最明显的可用性问题是什么?
|
||||
- ……
|
||||
|
||||
有了体验度量,我们可以确定很多抽象的问题,比如说,一个简单的改变可以带来多少具体的价值、从哪个方向降低完成客户服务任务所需要的时间、增加每天处理的多少交易量,可以使未完成的客户订单量减少多少、如何提升客户满意度和增加交易等等。
|
||||
|
||||
当我们的评估**从总体上给企业带来收入上的增加**时,体验度量就有了价值。
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天我们讲到了产品体验的评估问题,讨论了是否可以利用量化的手段给体验评分。
|
||||
|
||||
首先,我们确定了,产品体验是可以评估和度量的。我们在对产品进行用户体验度量的时候,可以从可用性、易用性、满意度三个大的维度去评估,建立我们的打分模型。
|
||||
|
||||
第一步,先划定好范围。我们的打分对象可以是针对一个完整的产品,也可以是产品中的某个相对独立的功能模块;第二步,按照我们之前所学,选择好我们的直接竞品;
|
||||
|
||||
第三步,结合产品属性和评分目标,进一步细化打分指标,每个细项指标的打分规则可以采用五级量表10分制的模式;第四步,打分的时候,要保证评分人的独立评分,并且要确保打分的人熟悉业务场景,尤其是针对B端的产品,在熟悉业务场景的基础上,进行打分会更有客观业务价值;
|
||||
|
||||
最后,在对体验分的结果进行分析对比的时候,我们可以根据需要,从行业标准和自我标准两个层面来对比分析。体验度量的价值并不是打分,而是通过评出的体验分让产品的关联方对产品的体验有更客观的认知,同时帮助产品更有效地完成迭代优化,带来业务上的增长。
|
||||
|
||||
希望通过本节课的讲解,帮助你在工作中更客观地评估产品的用户体验。
|
||||
|
||||
## 课后题
|
||||
|
||||
请结合课程中讲的详细评分维度,给你现在服务的产品或者重点功能进行一个评分吧。
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
195
极客时间专栏/体验设计案例课/量化的体验评估模型/17 | 如何轻松应对不同产品阶段的设计量化?.md
Normal file
195
极客时间专栏/体验设计案例课/量化的体验评估模型/17 | 如何轻松应对不同产品阶段的设计量化?.md
Normal file
@@ -0,0 +1,195 @@
|
||||
<audio id="audio" title="17 | 如何轻松应对不同产品阶段的设计量化?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b6/e8/b629bcf99bd163ffae2a277f68ddcce8.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
在之前的讲解和学习中,我给你分享了很多量化产品体验的小技巧,有设计创意、设计价值、设计评估等,我们全方位地研究了一个产品的设计着力点,那么,这就足够了吗?
|
||||
|
||||
对于想要走得更远的设计师来说,可能是不太够的。
|
||||
|
||||
因为,我们不仅要横向地研究一个产品的方方面面,还要纵向地去研究它的完整生命周期。在行业里,我们有一个比较通用的划分产品阶段的方式——根据产品的生命周期,可以把产品的发展阶段大致划分为以下四个阶段:**初创<strong><strong>期、 发展期、成熟期**</strong>和衰退期</strong>。
|
||||
|
||||
那么,产品在不同阶段会有怎样的特点?面对不同特点,我们如何调整量化手段来应对呢?以及B端和C端的产品在不同的生命周期,有哪些区别呢?
|
||||
|
||||
今天,我们就来好好地探讨一下这些问题。
|
||||
|
||||
## 不同阶段的B端和C端特点
|
||||
|
||||
首先,在本节课中,我们会主要围绕**初创期、发展期和成熟期三个阶段**来讲体验量化。
|
||||
|
||||
为什么不讲衰退期?因为衰退期是产品生老病死的最后一个阶段。此时的产品通常没有了新生的可能性,除非彻底变更商业模式或产品战略。要不然,再多的体验设计投入都是徒劳的。
|
||||
|
||||
接下来,我们就先来分析一下在生命周期的不同阶段,B端和C端产品各有什么特点。
|
||||
|
||||
说到生命周期这个词,你可能会有疑问了,通常我们说的一个产品的生命周期不是针对C端产品吗?B端的产品也有这种生命周期吗?一样的,只是**B端产品的生命周期会更长一些**。
|
||||
|
||||
但是,在同样的产品阶段,B端产品和C端产品的体验指标关注点会有一些细微差异。以我曾经做过的一个产品为例,我列举下B端和C端的区别,给你作个参考。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b0/8a/b0469ef920d80c0465285581ef4a358a.jpg" alt="">
|
||||
|
||||
在接下来的内容中,我会结合之前的一个B端App产品的案例,进一步拆解在不同的产品阶段中,我们怎样利用**设计量化的思维方式去逐步完善产品的设计和体验**。当你掌握了B端这个例子,C端产品你只要对照表格内容,就可以做到举一反三。
|
||||
|
||||
为了让你对这个项目有个大致了解,我给你简单地介绍一下产品的背景。
|
||||
|
||||
这个App的对象是银行公司业务的客户经理,他们的主要工作涵盖以下四个方面:
|
||||
|
||||
- 协助企业客户进行相关金融业务的办理;
|
||||
- 维护自己名下客户的存贷款情况;
|
||||
- 拓展更多的公司客户;
|
||||
- 查询个人业绩。
|
||||
|
||||
为了提高对公客户经理在移动办公场景的效率,这个App就被提上了日程。
|
||||
|
||||
## 初创期:主客观数据结合,优先满足用户需求
|
||||
|
||||
先来看初创期,我先问你一个问题,你对初创期怎样理解?
|
||||
|
||||
你可能觉得,初创期不就是刚创建产品的阶段吗?其实,不一定指一个全新又完整的App。如果是一个全新的功能,也可以拎出来以初创期来对待。因为对于原项目来说,它是个新东西。
|
||||
|
||||
对于我们的App,在初创期,我们计划优先上线两种类型的功能:
|
||||
|
||||
- 一是客户明确提出的功能;
|
||||
- 二是能明显提升业务效率和用户效率的功能。
|
||||
|
||||
客户明确提出的功能,还比较好理解。那么,我们怎样理解**业务效率和用户效率**呢?接下来,我用两个实际的功能来进一步给你说明一下。
|
||||
|
||||
我们先来看业务效率。在银行对公领域的业务场景中,有一项工作叫尽职调查,就是说企业来银行开户后,银行需要进一步去核实企业是否真实存在、是否有真实的办公场地、是不是空壳公司等这些信息,这通常都需要客户经理去企业实地调查。
|
||||
|
||||
在没有App的时候,客户经理的工作流程是这样的:
|
||||
|
||||
先去企业的经营场地,然后拍一些办公场景和补充的材料照片。回到公司后,再通过电脑上传到系统,提交到审核部门。这样一个流程下来,至少是大半天甚至是一天的时间。
|
||||
|
||||
倘若审核不通过,那客户经理还需要再跑一趟。
|
||||
|
||||
而App上线后,客户经理在企业经营场地拍完照片后,通过App就可以直接上传并提交到审核部门。十分钟内,审核就完成了。他还可以在手机上看是在哪个流程审核,如果审批不通过,是哪里存在问题,当场就可以修改提交,让客户经理只跑一次现场,就可以完成尽职调查。
|
||||
|
||||
这大大地节约了客户经理完成尽职调查的时间成本。
|
||||
|
||||
最后,通过数据的统计,我们发现,在App上线前,1位客户经理平均完成1家企业尽职调查的时间大概是四小时左右,而App上线后,这个时间缩短到了一个小时,平均效率提升了4倍。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/74/e8/744c8b57d7d6267f6420c83835d403e8.jpg" alt="">
|
||||
|
||||
接下来,**用户效率**层面,我们优先上线了一些用户高频使用的功能。比如资金变动提醒功能。
|
||||
|
||||
对于客户经理来说,其名下客户的存款、贷款直接关系到了他的业绩和奖金,所以他们会经常看自己名下客户的存贷款情况。在没有App的时候,客户经理都是通过电脑查看这些信息,而且他们对于一些资金的变动也不能够及时地掌握。
|
||||
|
||||
但是,在App上线后,客户经理就可以通过App,随时随地查看自己名下客户的存贷款情况,对于一些资金变动,系统还会主动推送;与客户存贷款情况相契合的营销产品,系统也会主动把商机推送给业务经理,帮助他们及时调整优化自己的工作计划。
|
||||
|
||||
在我们的App1.0版的第一个月的试运行结束后,为了评估1.0的版本是否能够真正地对客户经理的工作产生帮助,我们从**主观态度和客观数据**两个层面进行了验证。
|
||||
|
||||
在**主观态度**层面。我们借鉴了“[16 | 产品体验的评估也可以量化吗?](https://time.geekbang.org/column/article/343763)”其中说到的体验分评估模型,我们做了一次线上问卷调研,看一下现有的产品功能是否能够满足客户的需求。
|
||||
|
||||
我们筛选了350名用户做了问卷推送,回收的有效问卷大概是300份左右。通过对这300份问卷的评分计算,我们得出了App1.0版本的满意度是8.5分,对应的等级是非常满意。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/82/c4/82832c01cbf31bb2b223801ec89940c4.jpg" alt="">
|
||||
|
||||
再看**客观数据**层面,我们观察了周活跃率这个指标。试运行最后一周的周活跃率是77%,周活跃用户数是2766人。在这里,我们给周活跃的定义标准是每周使用App的次数大于5次。
|
||||
|
||||
结合主观态度和客观数据的初步结果,可以看出我们的App切实地给客户经理的工作带来了很大的帮助。这里我们找的主观和客观体验指标分别是:**满意度、<strong><strong>周**</strong>活跃率</strong>。
|
||||
|
||||
## 发展期:聚焦用户活跃率,覆盖更多业务场景
|
||||
|
||||
到了产品的发展期,阶段变了,核心任务也就变了。此时,我们更应该关注**用户的活跃率**。用户的活跃率才能够反映出来我们的产品是否能够真正对用户的工作有帮助。
|
||||
|
||||
再回到我们上面所说的例子。
|
||||
|
||||
差不多过了半年时间,相关的主要功能已经基本都上线了。但通过对数据的跟进,我们发现,与试运行相比,我们的周活跃率却一直是一个下降趋势,半年的时间已经下降到了65%左右。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2c/b0/2c1c8f26c5018da701e6f2e486e142b0.png" alt="">
|
||||
|
||||
为了解决活跃用户数量持续下降的问题,我们和产品经理一起开展了一场用户调研。
|
||||
|
||||
我们安排了两组调研人员,每组1个设计师、1个产品经理。还联系了一些分行的客户经理,让调研小组跟着客户经理去工作一周,包括每日站会、周会、拜访客户、柜台协作客户办业务等。
|
||||
|
||||
通过一周的调研,我们发现了一些App功能没有覆盖到的工作场景。
|
||||
|
||||
比如说,对于一些大客户,客户经理都会定期拜访,维护好客户关系;每天的站会和周会,一个组的客户经理都需要互相对齐下拜访客户的情况;在拓展一个新客户或新业务的时候,客户经理会互相打听其他分行有没有做过类似的客户或业务,提前找一些经验参考。
|
||||
|
||||
基于这些细分工作场景的掌握情况,我们又找到了一些**新的设计机会点**。
|
||||
|
||||
比如说,升级原有的客户拜访功能,帮助客户经理更轻松、全面地掌握客户信息;增加知识库功能,让客户经理在手机上就可以学习其他分行的经验知识……
|
||||
|
||||
接下来,我来给你具体地拆解一个客户拜访功能的优化例子,讲一下整个升级优化中的设计思路,希望能给你带来更多的启发。
|
||||
|
||||
原来的客户拜访功能只有定位打卡和拍照上传,这个设计最初的出发点是杜绝客户经理假拜访来刷自己的拜访数据。功能比较单一,每次客户经理到了客户那打个卡,拍张自己和公司前台以及公司法人、公司经营执照的合影,几秒钟完成。之后,客户经理就再没有打开过我们的App了。
|
||||
|
||||
但其实在拜访客户的实际工作场景中,他们还有很多工作要做:记录拜访客户的信息(时间、拜访了谁、哪些重点事情、需要跟进的事项……)、每天还要邮件汇总拜访客户的情况给小组长、有待办事项的还要另外记到备忘录上等等。
|
||||
|
||||
既然客户经理还有这么多工作要做,我们为什么不能够让他们在App上完成整个拜访客户的工作流呢?是不是就不用他们综合使用邮件、本子、其他App才能完成整个工作流了?
|
||||
|
||||
所以,针对客户拜访功能的升级,我们有针对性地完善了几个功能:
|
||||
|
||||
- 拜访笔记功能
|
||||
|
||||
客户经理可以把拜访时间、拜访对象、重点事情等关键信息直接记录在该客户名下,而且会用时间轴的方式帮客户经理做一个拜访记录的汇总。这样,客户经理就可以非常清晰地看到自己拜访每个客户的情况。
|
||||
|
||||
- 自动生成日报和周报
|
||||
|
||||
根据客户经理的每次拜访笔记,系统自动生成拜访日报和周报,同时一键同步到小组长那里。这样,每次开会前,客户经理就不用再以邮件的方式重新汇总一次材料,而小组长也能够提前了解到客户经理的总体拜访情况,提高每日站会和周会的效率。
|
||||
|
||||
- 增加待办事项功能。
|
||||
|
||||
对于那些拜访后产生待办事情的场景,客户经理可以在App里直接录入,系统会自动同步到手机日历上,避免客户经理忘记此项待办。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a1/3a/a1a4bef21b16daa83d92f1af4f9fd23a.png" alt="">
|
||||
|
||||
这些细分工作场景的覆盖,让客户经理有了更多的动机来使用我们的App。
|
||||
|
||||
随着这些优化功能的逐步上线,我们发现App的周活跃率逐步上升到了85%左右,同时,周页面浏览次数也同步提升到了205,396次,比六周前的数据提升了28.9%。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/6d/96/6d2aa25bfb67881b6bd7494d0b0b9c96.jpg" alt="">
|
||||
|
||||
这个阶段,我们看的体验指标是:**周<strong><strong>活跃率、周页面浏览次数**</strong>。</strong>
|
||||
|
||||
## 成熟期:完善基础功能配置,定制特殊化功能
|
||||
|
||||
对于我们的产品来讲,想要**批量去获得更多客户**是一件非常不容易的事情。
|
||||
|
||||
因为我们产品最初的出发点往往是基于我们企业的工作场景设计的,其他企业的工作场景跟我们的并不完全一样。所以,我们的产品做批量获取新客户会有一些先天局限性,但这并不是说明我们的产品做不到。
|
||||
|
||||
那么,我们的产品是怎样去批量获取新客户呢?答案就是**基础功能配置化+特殊功能定制化**。还是以上面的App为例子,跟你分享一下我们在这个阶段是怎么做的。
|
||||
|
||||
在我们集团的其他子公司,也有一大批客户经理进行公司相关的金融业务,与我们这边的客户经理的工作场景很相似。所以,集团从上往下推,将我们的App拓展到了它的子公司。
|
||||
|
||||
但是在前期试运行阶段,该子公司每周新增客户数非常少,活跃率也很低,与当时我们试运行期间的活跃率相差很大。为了搞清楚活跃率低的原因,我们组织了一次客户访谈。
|
||||
|
||||
通过访谈,我们了解到一个关键信息:我们的App提供的功能,他们只会用到一部分,而另外一部分,他们完全用不到;还有另外一些他们需要的功能,我们却没有。
|
||||
|
||||
了解到这个信息后,我们就制定了把**拆分基础功能做配置**和**针对特殊功能做定制**两个思路。
|
||||
|
||||
什么意思呢?就是一边把他们需要的的基础功能提取出来,做成配置化的功能模块,他们需要什么功能,就配置什么功能;一边再去安排人去对接定制化的特殊功能。
|
||||
|
||||
最后,在这个优化的版本中,我们实现了个人业绩查看、知识库、营销推送、客户拜访等基础功能的上线,另外还完善了每日一图、多角色切换等针对该子公司的定制化功能。
|
||||
|
||||
这样,App上的功能就基本覆盖了该子公司的全部工作场景。
|
||||
|
||||
在优化的版本上线后,我们同样持续观察了该子公司的周新增客户数和活跃率,发现两个指标都有在稳步提升。两个月后,周新增客户数由原来的15个增加到了53个,周活跃率由优化前的43.6%增加到了78.5%。这也为我们获取更多新客户开了一个好头。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a1/3a/a1a4bef21b16daa83d92f1af4f9fd23a.png" alt="">
|
||||
|
||||
我们又把同样的逻辑,也就是基础功能配置化+特殊功能定制化,快速地推到了其他子公司。这个阶段,我们看的体验指标是:**周活跃率**、**周新增客户数。**
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,在本节课中,我用了一个工作中的B端App产品为例子,跟你分享了一下在产品的初创期、发展期、成熟期的设计量化的使用方法,我们再一起回顾一下。
|
||||
|
||||
首先,在初创期,我们优先上线了客户明确提出的功能,还有明显提升业务效率和用户效率的功能,用来满足客户的主要工作需求。这个阶段,我们主要使用的体验指标是**满意度和周活跃率**;
|
||||
|
||||
其次,在发展期,为了让更多的客户活跃起来,我们逐步上线了一些客户没有明确提出,但在工作中会用到的功能。通过对更多业务场景的覆盖,提高用户的使用意愿。
|
||||
|
||||
在这个阶段,我们主要使用的体验指标是**周活跃率和周页面浏览数。**
|
||||
|
||||
最后,在成熟期,为了提高我们的产品批量获取更多新客户的能力,我们采用了**基础功能配置化+特殊功能定制化**的思路,也顺利地把我们的产品推广到了更多的子公司。在这个阶段,我们主要使用的体验指标是**周活跃率和周新增客户数**。
|
||||
|
||||
以上,就是我们在产品的不同发展阶段的设计量化思路,你应该发现了,主要使用的就是**不同的体验指标**。选用体验指标的思路,就是选用和产品的属性相关联的指标。
|
||||
|
||||
因为,和产品属性相关联才是解决实际问题的最好的切入点。
|
||||
|
||||
## 课后题
|
||||
|
||||
针对本节课中说到的客户经理拜访客户的场景,你还能够挖掘出更多的细分场景吗?
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
139
极客时间专栏/体验设计案例课/量化的体验评估模型/18 | 怎样用量化的方式帮助设计成长?.md
Normal file
139
极客时间专栏/体验设计案例课/量化的体验评估模型/18 | 怎样用量化的方式帮助设计成长?.md
Normal file
@@ -0,0 +1,139 @@
|
||||
<audio id="audio" title="18 | 怎样用量化的方式帮助设计成长?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/75/4d/75f12c5ce63653dc0775bd6646106b4d.mp3"></audio>
|
||||
|
||||
你好,我是炒炒。
|
||||
|
||||
到目前为止,我已经给你分享了七节关于设计量化的课程,不知道你对量化这件事,是不是有了一个全新的认识呢?那么,这一讲,我们又要了解哪方面设计量化的内容呢?
|
||||
|
||||
在前面的几讲中,大部分的量化知识点都是运用在具体设计过程中的。设计做好了,那关于设计师的能力成长,你有想过也是可以利用“量化”这个方式来做成长指引的吗?
|
||||
|
||||
当然是可以的。而且,量化的方式会让你更清晰、更明确地找到自己的成长路径。
|
||||
|
||||
这节课,我就给你分享一下怎样用量化的方式,有效帮助设计师完成个人设计能力的成长。我把这方面的内容归纳成了三个关键点。首先,我们来看第一个关键点。
|
||||
|
||||
## 评估能力,选择提升方向
|
||||
|
||||
在“[11 | 设计师的能力水平可以量化吗?](https://time.geekbang.org/column/article/339363)”中,我给你讲了怎样量化和评估设计师能力水平的相关知识,你可以按照那节课中提到的思路,完成自我评估,**确定自己目前能力所属的等级**。
|
||||
|
||||
毕竟,客观、准确的自我认知是提升自己的前提条件。
|
||||
|
||||
使用能力模型对自己进行评估后,你可能会列出很多项需要提升的能力。那么,问题来了,面对这么多待提升的能力项,到底该优先提升哪一项,才是最有效果的呢?
|
||||
|
||||
接下来,我就结合我团队里的一个设计师的成长历程,以他作为本节课的例子,带你看一下,他是怎样选择能力提升方向的。现在,我们假设,他叫小A。
|
||||
|
||||
小A刚来我团队的时候,已经工作了一年多,是一名初级交互设计师。他的特点就是学习意愿很高、自驱力很强,这也是我选择他进入我团队的原因之一。
|
||||
|
||||
在我的团队中,设计师入职后,我都会进行一次成长面谈,和入职前的面试有很大不同。
|
||||
|
||||
我会进一步了解一下,他们对于现有工作的具体想法、职业规划、对行业趋势的见解等,并结合他们自己的意愿和团队的能力要求,以及项目计划,帮他们一起规划接下来的工作方向和进阶计划。
|
||||
|
||||
小A上一份工作是在一家小公司,所以他对自己的能力项、未来的职业方向也都比较模糊。所以,我先用设计能力量化模型,对照分析他的能力,让他对自己的能力有个清晰的认知。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b6/f6/b6d0dab66e5935e288f2fa7286f7e3f6.jpg" alt="">
|
||||
|
||||
[第11讲](https://time.geekbang.org/column/article/339363)的时候,我们提到过,在交互设计师的能力模型中,总共有11个能力项。
|
||||
|
||||
这些能力项又可以分为专业能力、通用能力和组织建设能力三大类。对于设计师来说,**专业能力是基础,通用能力和组织建设能力都是杠杆**。只有基础扎实,杠杆才能起作用。
|
||||
|
||||
接下来,我们针对小A的能力项得分进行分析,我们发现,他在专业能力上的得分不算太高,而他的通用能力和组织建设能力的相关项得分却还算可以。
|
||||
|
||||
因此,针对小A这种初级阶段的设计师来讲,**打好地基,强化专业能力**才是这个阶段的重点。因为专业能力会直接影响到工作中的**设计输出效率和质量**,对设计师的**绩效**产生直接影响。如果设计输出的效率和质量不达标,就算你其他方面的能力再不错,估计也很难在团队中立足。
|
||||
|
||||
所以,还是初级设计师的小A,也把自己现阶段的提升方向放在了专业能力上。差不多过了半年的时间,团队的其他人都明显地感觉到了小A在专业能力方面的进步。连经常合作的产品经理也跟我表扬,说小A的设计输出比刚来那会专业多了,而且效率也高了很多。
|
||||
|
||||
那你可能会好奇了,小A在选择和确定了提升专业能力这个方向后,究竟做了哪些事情,才有了这样的进步呢?
|
||||
|
||||
接下来,一起来看看,我们是如何帮助小A提升和蜕变的。
|
||||
|
||||
## 结合方向,设定有效目标
|
||||
|
||||
其实,这第二步,就是结合要提升的方向,**设定有效的目标**。
|
||||
|
||||
说到目标,我先来给你举一些描述目标的例子。有一些人是这样描述目标的,“我要提升我的审美能力”“我要提高我的产品思维”“我要提高我的交互设计能力”“我要加强锻炼身体”……
|
||||
|
||||
还有一些人会这样描述自己的目标,“明年晋升为一名高级设计师”“每两周做一个产品分析报告,坚持半年”“坚持锻炼身体,每周慢跑三次,每次一小时”……
|
||||
|
||||
你应该发现了,上面两类人关于目标的描述,是不是觉得第二类人关于目标的描述更靠谱、更实际?你是不是也发现了这些靠谱目标的共同点,就是**可量化、贴合实际。**
|
||||
|
||||
那么,为了提升自己的专业能力,小A给自己设定了什么目标呢?
|
||||
|
||||
通过成长面谈,小A对自己的能力有了一个客观的认知。他结合我们团队的设计师能力指标量化,给自己设定了第一个阶段性的目标:**利用<strong><strong>一**</strong>年的时间,让专业能力达到D2级别</strong>。
|
||||
|
||||
对小A现阶段来说,这个目标就是一个有效的目标。
|
||||
|
||||
第一,这个目标是可量化的,一个可量化的目标,就不能用一些模糊的词组来描述目标。
|
||||
|
||||
第二,这个目标是符合实际情况的。一般情况下通过努力就够得着。但是,假如小A说要用一年时间让专业能力达到D5级别,虽然这个目标是可量化的,但可能有点不太符合实际情况。
|
||||
|
||||
毕竟,专业能力达到D5级别的人,基本都在设计领域工作八年以上,且在行业有一定的影响力。小A才工作一年多,无论是专业能力还是对设计的感悟,离这个目标看起来,都需要大量时间和项目的深度打磨。
|
||||
|
||||
现在,我们知道第二个关键点了,就是设定好可量化、贴合实际的有效目标。那我们通过怎样的执行方式才能更好地达到目标呢?我们一起来看一下第三个关键点。
|
||||
|
||||
## 拆解目标,量化落地事项
|
||||
|
||||
为了达成一个目标,我们通常会把这个目标拆解成可以落地的几件事情。当我们把这些事情都完成了之后,目标或许就能够达成了。小A的目标是利用一年时间,让专业能力达到D2级别。
|
||||
|
||||
于是,我们帮助小A制定了一个为期一年的学习计划,这个学习计划大概分为了三个主要事项。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/78/d2/78e92283fd4750cb24dc6c69ca362dd2.jpg" alt="">
|
||||
|
||||
通过这份计划表可以看出,他并不是简单地把事项列出来就完了,而是把每件事情进一步拆解,有事项、有达成标准、还有明确的推进时间。这样,事情拆分得越明确,目标达成的可能性就越高。如果仅仅简单地只写出要做什么事情,那这件事情大概率的结果就是无疾而终。
|
||||
|
||||
接下来我再展开分享一下小A的这些计划事项的落地细节,希望能够给你带来更多的启发。
|
||||
|
||||
我们先来看第一件事——头部优秀交互设计案例拆解计划。
|
||||
|
||||
这件事主要是帮助他学习到一些优秀的交互设计思路和方法,保持自己交互思维的敏感性。
|
||||
|
||||
他计划每七天分析1个优秀的交互方式,但是,这个练习并不是下一个优秀的头部产品看一看、点一点,然后觉得这个交互好就完事了,而是要对交互方式进行流程分解,去思考这个交互好在哪里;如果是自己的话,会怎样处理,有没有更好的处理方式;另外,有没有一些可以优化的点,如果要优化,自己的方案是什么。
|
||||
|
||||
为了督促自己每日一练,他还参加了一个打卡群,用这种方式来督促自己完成每天的目标,避免目标被莫名地遗忘。他还给自己设定了一个小的惩罚机制,就是如果哪天没有做,就在打卡群里发一个30块钱的红包。这种小小的惩罚机制也反向督促了他目标的执行。
|
||||
|
||||
第二件事——读书计划。
|
||||
|
||||
小A结合别人的推荐,筛选了基本和专业能力层面联系度较高的书籍,用书籍中的理论知识进一步完善自己的知识体系。但是,读书也并不是翻一遍书就完事了。
|
||||
|
||||
每读完一本书,他都会把书中的核心知识点用脑图的方式梳理出来。另外,他还会把自己在读书过程中的一些思考以读书笔记的方式记录出来。**从输入到输出**,能把知识用自己的语言讲出来,才是真正的掌握。我记得小A还在内部的分享会上分享了他的《微交互》的读书笔记。
|
||||
|
||||
看完小A的读书方式,你可以回想一下,自己是怎样看书的呢?是像小A这样会形成知识点脑图和读书笔记,还是翻完就算读完了呢?
|
||||
|
||||
第三件事——对一些优秀产品进行交互设计的Redesign。
|
||||
|
||||
**先学习,<strong><strong>再**</strong>优化</strong>。通过虚拟项目的方式,可以实践和验证一下自己在交互上的一些思考。
|
||||
|
||||
他选择了三个自己喜欢的产品,做交互设计的Redesign,每两个月做1个。同样地,Redesign这件事也并不是简单地把页面做出来就万事大吉了,而是要对现有产品的用户场景、交互流程、优劣点做进一步的思考,然后再输出页面设计方案。
|
||||
|
||||
在最终输出的Redesign材料中,要包含用户、场景、流程逻辑、设计切入点、方案页面设计等完整的思考过程的呈现。如果只是输出最后的页面设计,没有中间的思考过程,那么这个Redesign就不算是完成。
|
||||
|
||||
以上就是小A在事项落地上的一些细节,不知道有没有给你带来一点启发。
|
||||
|
||||
最后,通过这些计划的逐步执行落地,小A到了下一年能力评估的时候,他的专业能力基本达到了D2级别,而且到了年底的绩效评估,他也理所当然地进入到了升职加薪的名单内。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/4a/b9/4a5537c35da256387e72d533668e13b9.jpg" alt="">
|
||||
|
||||
## 炒炒总结
|
||||
|
||||
今天,我们通过设计师小A成功晋升的例子,get了用量化的方式帮助自己成长的秘诀。
|
||||
|
||||
主要有三个关键点,我们来总结一下。
|
||||
|
||||
第一,先用量化评估的方式,客观评估自己的能力,选择自己的努力方向。在能力模型里,专业能力是基础,通用能力和组织建设能力是杠杆。基础扎实了,杠杆才能发挥作用。
|
||||
|
||||
所以,对于初级阶段设计师来讲,优先打好基础会更有效果。
|
||||
|
||||
第二,结合提升的方向,设定有效的目标。有效包含两个必要条件:可量化、贴合实际情况。
|
||||
|
||||
第三,拆解目标,形成待办事项,并且用量化的方式进一步拆分这些待办事项。需要注意,量化的待办事项一定要明确什么时间、做哪些事情、输出什么结果。而且在每一项的落地时,不能只做单一的、重复性的工作,为了完成任务而做,要有自己的思考在里面。
|
||||
|
||||
另外,你还可以通过设定打卡、小小的惩罚机制来督促这些事项的落地。
|
||||
|
||||
最后,希望这种量化的方式也能够给你一些帮助,助你完成能力进阶,升职加薪。
|
||||
|
||||
## 课后题
|
||||
|
||||
请你尝试着确定一下自己的提升方向,并根据这个方向,设定出一个有效目标。试着拆解一下目标,简单地列出2~3项可以落地和量化的事项。
|
||||
|
||||
记得在留言区和我讨论、交流你的想法,每一次思考都会成为你进步的基石。
|
||||
|
||||
如果你喜欢今天的内容,也欢迎你把这一讲分享给你的朋友。
|
||||
|
||||
感谢你的阅读,我们下一讲再见。
|
||||
Reference in New Issue
Block a user