|
|
# 15 | 如何建立设计方案的验证模型？
|
|
|
|
|
|
你好，我是炒炒。
|
|
|
|
|
|
你有思考过这样的问题吗？作为一名设计师，你在公司的职责是什么？或者是，你认为设计师的任务到哪一步才可以算是完成了？在一个项目里，设计师究竟要对哪一环节负主要责任？
|
|
|
|
|
|
很多人认为设计师只是公司的一个画图员，只需要把设计任务完成并输出设计稿就可以了。
|
|
|
|
|
|
可是，这个设计方案有没有用呢？能达成业务的目标吗？能给业务带来多大的影响？而且，这个设计方案真的满足用户的需要吗？**设计师可能会觉得，这些好像都不关他的事**。
|
|
|
|
|
|
你觉得这样想，真的对吗？
|
|
|
|
|
|
在我看来，作为一名设计师，我是不太认同设计师的责任是只需要完成设计稿的交付的，这是一个不负责任的说法。设计师在企业内部属于资源项，服务于商业化的设计。职责就是要**赋能业务，达成业务指标**。同时还要承担着平衡商业与用户的责任，是需要为用户体验负责的。
|
|
|
|
|
|
所以，今天我要讲的就是，除了设计一个方案出来，你还要懂得**验证自己方案的合理性**。
|
|
|
|
|
|
## 为什么要验证设计方案？
|
|
|
|
|
|
那么，问题就来了，我们为什么要验证设计方案的合理性呢？我觉得可以分为两点。
|
|
|
|
|
|
**第一，为了给业务和用户带来价值。**
|
|
|
|
|
|
作为设计方案的输出者，你完全有责任去验证设计方案给业务和用户带来的价值。
|
|
|
|
|
|
更直白一点说，设计师应该要去验证设计方案有没有达成业务目标，为其他协同方高效又有效地解决问题；有没有满足用户诉求，为用户自然又舒适地解决问题。
|
|
|
|
|
|
那要是我们抛开设计验证，只是一直地做设计，会造成什么样子的后果呢？
|
|
|
|
|
|
我举一个类比。假设，我现在开了一家餐馆，但我只负责把食材放在一起炒熟给你吃。不管你对这道菜的评价是好吃还是难吃、卖相吸引不吸引、分量够不够饱......我就这么做，你爱吃不吃。
|
|
|
|
|
|
你也知道，这肯定是一个没未来的餐厅。厨师做出来的食物不能让食客满意，会导致餐厅没有生意；没有生意，餐厅就没有收入来源；没有收入，只有支出，餐厅迟早会经营不下去。
|
|
|
|
|
|
如果你是餐厅老板，你是不是会听取食客的意见，调整配方、优化菜品，来满足食客的预期？
|
|
|
|
|
|
设计也是同理。我们不能光一味地搞输出，还要适时地去收集用户的意见和建议，验证自己的设计方案，优化该优化的地方，确保我们的设计方案是真的可以帮助到用户。
|
|
|
|
|
|
如果仅仅是做了设计方案就算完了，不进一步地跟进我们的方式有没有效果，这种行为就是耍流氓，就像我在开篇词中说到的：“不解决实际问题的用户体验设计都是耍流氓”。
|
|
|
|
|
|
当我们满足了用户的需要，用户喜欢用、习惯用，产品自然也就有了更多的业务价值。
|
|
|
|
|
|
**第二，为了提高设计师的专业能力。**
|
|
|
|
|
|
这一点不用展开讲，你也懂。一个会去验证设计方案的设计师一定比一个只作图的设计师有更多的话语权，更了解市场的情况等，久而久之，他就会成长得更快，变得更加专业。
|
|
|
|
|
|
## 怎样去验证设计方案？
|
|
|
|
|
|
那我们该怎样去验证设计方案的合理性呢？这个合理性有没有什么可量化的标准呢？既然设计师要对业务和用户体验负责，那设计方案的验证主要就是验证两个目标：
|
|
|
|
|
|
* 验证设计方案有没有达成业务目标；
|
|
|
* 验证设计方案有没有满足用户需求。
|
|
|
|
|
|
接下来，我会以工作上的一些项目为例，来跟你聊聊怎么去验证设计方案是否满足这两个目标。
|
|
|
|
|
|
### 用数据验证是否达成业务目标
|
|
|
|
|
|
一提到“验证”这件事，不知道你的脑海里第一时间出现的是什么？我的脑海里马上就飘过了“数据”这个词语。是的，没错，数据是目前来讲比较客观的检验和验证方式。
|
|
|
|
|
|
在平时的工作中，我们设计师会经常听说的数据指标也有很多，例如PV、UV、平均停留时长、新用户留存数、用户流失率、页面跳出率、完成率、转化率等等。
|
|
|
|
|
|
问题又来了，在这些数据指标里，哪些是和业务目标相关联的？换句话说，哪些数据指标对于我们来说，才是更有价值的？是每一项指标都要关注吗？当然不是。
|
|
|
|
|
|
**针对业务目标，要选择对应的关键数据，才是借用数据验证的正确打开方式**。下面，我就结合之前做过的一次运营活动，分享一下，该怎样选择数据指标来验证设计方案。
|
|
|
|
|
|
这个运营活动的背景是这样的：**为了给我们的A****pp****拉取更多的新用户**，业务部门发起了一个“注册就送888元免息券”的活动。他们希望用这种利息减免的方式吸引更多新用户，并且让这些用户申请我们的贷款产品。一句话总结就是，**拉****新客、引贷款****。**
|
|
|
|
|
|
在这个运营活动中，主要有两个节点：
|
|
|
|
|
|
* 一是用户只要注册就能够领取888元的免息券；
|
|
|
* 二是想使用这个免息券，用户必须签约贷款产品才能使用。
|
|
|
|
|
|
根据这个流程的拆解，那我们现在知道了，对于业务侧来说，先让用户领取免息券，如果要使用券就需要先注册成新用户，但如果新用户不使用免息券贷款申请贷款，那这个新用户是没有贡献业务营收的；所以，只有用户使用了免息券进行贷款，业务才会有营收数据。
|
|
|
|
|
|
因此，对于我们设计师来说，我们的设计方案不但要考虑用户领取免息券的流程，同时也要考虑怎样刺激和引导用户去使用免息券去签约贷款产品。一个完整的活动流程是这样的：
|
|
|
|
|
|
> 赠送888免息券给用户——用户领取成功——成为新用户——去申请贷款并使用
|
|
|
|
|
|
通过这个梳理，我们发现，这个活动的初级目的是“拉新”，但**让新用户使用免息券进行贷款才是****最终****的目的**。因为领券只帮我们拉来了新用户，用券才能给我们带来实际的业务营收。
|
|
|
|
|
|
所以，针对这次活动的设计方案的效果验证上，我们不仅仅要看活动点击数和免息券的领取数，同时还要看申请贷款产品的用户数。因为最终申请贷款的数据，才是本次运营活动的业务目标，也是验证我们的设计方案在贷款签约转化上是否有效的核心数据指标。
|
|
|
|
|
|
结合本次运营活动的业务目标，我们就构建了一个设计方案效果的指标验证模型：
|
|
|
|
|
|
> 活动点击数>免息券领取数>注册的新用户数>申请贷款产品的用户数
|
|
|
|
|
|
在完成设计方案，并投放了一周后，我们提取了一些关键数据，具体如下：
|
|
|
|
|
|
* 活动点击数是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%问题都是跟找不到功能****入口****相关的**。
|
|
|
|
|
|
所以，这次改版的一个核心任务就是对菜单进行再分类与排序，设计师按照自己对每个菜单内容的了解进行了业务属性的分类。菜单分类排序调整后，设计师就有了一个困扰“这是我对平台菜单内容的理解，跟用户对菜单内容的理解一致吗？”
|
|
|
|
|
|
为了验证新分类与排序是否符合用户的预期，我们直接邀请了几位用户来到现场测试，这次，我们不再是用惯用的demo进行验证，而是利用“卡片分类”来邀请用户一起参与到设计当中。
|
|
|
|
|
|
我们把所有的功能菜单写在了小卡片上，让用户自己理解菜单名称内容，并加以分类；通过3-4个用户的分类，再对比用户与我们的设计方案对比，把差异性大的分类与排序进行了调整。
|
|
|
|
|
|
这是一个快速又比较准确验证是否满足用户需求的方法，可以在没有数据的情况下完成设计验证。
|
|
|
|
|
|
当然，可用性测试的方法有很多，例如我们常用的用户访谈、问卷、Demo随机测试等。你可以根据项目的内容、需求紧急程度以及资源、预算等来调整可用性测试的方法。如果你对可用性测试的方法不是很深刻的话，可以回头再翻翻我们的“[08 | 你一个人怎么搞定可用性测试？](https://time.geekbang.org/column/article/336704)”。
|
|
|
|
|
|
我们可以借助数据、可以采用可用性测试，这些都是做设计验证的其中一些方法。在实际工作中，我们是可以根据项目所需而灵活变通的，根据实际情况采用一些合适的工具和方法，希望我的案例和采用的方法能给你带来参考价值。
|
|
|
|
|
|
最后，有一个问题，你可以思考一下。作为设计师的我们，看数据和产品经理以及运营经理看数据有什么不同呢？其实看的数据源都是一样的，只是关注点不太一样。
|
|
|
|
|
|
设计师看数据，主要为了验证**体验指标**的完成，验证当前版本用户跑出来的数据，是否符合设计目标，判断设计方案的有效性。
|
|
|
|
|
|
举个例子，如果把增强视觉效果作为提高banner位点击率的策略之一，那么banner的色彩搭配是否协调、构图是否巧妙、文案是否精准表达且有趣撩人，就成了验证策略的关键因素。
|
|
|
|
|
|
要记住，一个设计方案如果没被用户的行为跑出数据，那都是在自嗨。
|
|
|
|
|
|
## 炒炒总结
|
|
|
|
|
|
今天，我们探讨了关于设计方案验证的问题。
|
|
|
|
|
|
首先，从职责范围的角度来说，设计验证是设计师的本职责任，不做设计验证的设计方案不是一个完整的方案。设计验证主要也是为了验证是否达成业务目标、是否满足用户需求。
|
|
|
|
|
|
所以，我们验证设计方案，也要从业务目标和用户需求两个方面出发：
|
|
|
|
|
|
* 明确业务目标，不同的业务目标借助不同的关键数据来做设计方案；
|
|
|
* 分析用户行为数据，借助用户在使用产品过程中的数据来验证是否满足用户需求。
|
|
|
|
|
|
这两种方法都是以数据作为工具，那要是没有用户数据呢？我们可以巧妙利用可用性测试，在没有数据时或产品上线前，通过可用性测试的结果反馈，来验证我们的设计方案。
|
|
|
|
|
|
总的来说，就是以数据或者测试反馈等意见为工具，以业务和用户为核心，来验证当前设计方案的合理性。持续地精进和打磨优化现有的方案设计，给产品增色。
|
|
|
|
|
|
希望今天的内容可以帮助你对设计方案给业务、给用户带来的价值做更深度的思考和探索。
|
|
|
|
|
|
## 课后题
|
|
|
|
|
|
你最近做的一个优化性需求功能是什么呢？试着分析业务目标，以及借助数据来验证一下这个设计方案是否达成业务目标，是否能帮用户解决问题。
|
|
|
|
|
|
记得在留言区和我讨论、交流你的想法，每一次思考都会成为你进步的基石。
|
|
|
|
|
|
如果你喜欢今天的内容，也欢迎你把这一讲分享给你的朋友。
|
|
|
|
|
|
感谢你的阅读，我们下一讲再见。
|
|
|
|