我们是不是经常思考这样一个问题，就是一个设计方案出来，我们应该如何验证设计方案的合理性

所谓验证合理性就是需要我们将设计赋能业务，达成业务指标

为什么要验证设计方案呢？这里我们可以分为两点

第一，是为了给业务和用户带来价值

毕竟我们作为设计方案的输出者，是完全有这个责任跟义务去验证设计方案给业务和用户带来的价值的

更直白点就是，设计师应该要去了解设计方案有没有达成业务目标，为其他协同方高效又有效地解决问题；有没有满足用户诉求、需求，为用户自然又舒适的解决问题

就比如我们举一个例子，我们开了一家饭店，但是我只负责把饭菜做熟，并不会去考虑色香味俱全等等，我就这水平，你爱吃不吃

我们也可以看出来，这很明显就是一个没有未来的餐厅，菜品满不满意另说，咸淡你不在乎，口感你不在乎，这样一来二往就没有了生意，没有了收入，迟早得去捡瓶子维持生计

如果你是这家饭店的老板，会不会听取用户的意见，各种可适用方案，去想办法优化来满足用户的预期

设计也是同理，我们不能凭借以为的搞输出，还要实时去了解去收集用户的意见和建议，验证自己的设计方案落地可行，优化该优化的地方，确保设计方案真正的可以帮助用户解决想解决的问题

当然，如果仅仅是设计完了不跟进落地效果就是在耍流氓，好比那句话「不解决实际问题的设计都是耍流氓」

当我们满足了用户的需要，用户喜欢用、习惯用，产品自然就有了更多的业务价值

第二，为了提高设计师的专业能力

这个当然我们都懂，一个回去验证方案落地性的设计师是一定会有一定的话语权的，只有深入洞察，了解市场情况，才会更合理的解决问题，也会更加专业，成长也会更快

如何去验证设计方案？

那我们该怎样去验证设计方案的合理性呢？这个合理性有没有可量化的标准呢？既然设计师要对业务和用户体验负责，那设计方案的验证主要就是验证两个目标：

  • 验证设计方案有没有达成业务目标
  • 验证设计方案有没有满足用户需求

用数据验证是否达成业务目标

**

针对业务目标，要选择对应的关键数据，才是借用数据验证的正确打开方式

就比如我们在做一个引流活动，就单纯的是为我们的平台拉取更多的新用户进来，那我们肯定就要想一个痒点，来刺激用户来下载使用

首先我们想到的就是新用户返现，因为返现金这种方式是平台拉新最简单的最直白的一个方式，就是我设定一个金额，你拉好友进来我给你多少钱返现，到了一定金额后可提现，简单来说就是，我给钱你找人。然后再通过平台其他营销活动进行留存。这样就会让用户有一个最基础的步骤：

拉好友-注册-给予一定的优惠券-促进消费下单-领取返现

通过这个步骤我们就可以发现，我们此次活动的目的就是拉新，只要能够刺激用户消费，痒点刺激到位，就可以完成我们想要达到的这个业务目标，当然这只是一个简单引流的方式，我们后续肯定还会去想如何去让用户留下来，去进行更多的消费

结合本次运营活动的业务目标，我们就构建了一个设计方案效果的指标验证模型如下：

app下载次数-注册用户-成功领券用户-下单用户

确定并完成设计方案后，并投放市场，小范围投放一周后我们收到信息反馈如下：

-下载次数为3000
-实际注册用户为800
-成功领券的用户为300
-成功下单的用户为50

经数据验证了解到，我们此次实际拉新人数为800，实际下单人数为50，也就是我们的实际转化率为6.25%，很明显这个转化率是有点低的，因为按照我们的风险承担的一个心理反应来讲的话，打破用户下载的这层壁垒后，只要优惠力度够高，是很容易引起用户去消费的，即使在还没有建立信任关系的时候，也会有部分用户会去尝试薅羊毛，所以，明显我们的这个转化率是有点低的，我们这个时候就需要去同运营、产品跟市场方面去一同了解是哪儿个环节导致的用户下单不流畅，从而进行提升用户满意度，促使用户进行下单

我们在做运营设计的时候肯定会根据需求方的需求来定制其设计方案，以达到商业化目的，并且我们需要实时跟进并迭代需求，以更理想的达到我们的业务目标

用数据验证时是否满足用户需求

**

最简单最少的操作才是用户想要的，我们都知道，我们在进行一个活动或者一个新功能上线的时候，我们都是需要去适当的教育「引导」用户来进入我们刚刚发布的活动或者功能场景的**

这个时候我们就需要用数据埋点来进行统计

数据埋点：对应用程序特定的流程，进行数据采集，以便于分析用户的使用状态，给运营，技术，产品提供数据支持

事件：
具体行为、点击事件、停留时间事件、曝光事件「刷新/下一页/上一页」
**

指标「量化数据」：
PV 访问量
UV 访客数 24h内同一客户端
退出率
跳出率
转化率

以上是关于数据埋点的一些tips内容

我们可以通过给到的数据来去跟产品一起去进行相应的一些优化

巧妙采用可能性测试做设计验证

在新产品/功能上线前，大多数是没有用户数据的。这个是时候我们最经常用的就是可用性测试这个工具了。通过用户可用性测试的验证更偏向于验证「是否满足用户需求」

为验证新的功能及优化方案是否符合用户的预期，我们直接让市场部随机邀请了几名使用者进行测试，我们直接采用的是录屏的方式以及录像的方式进行采集，通过卡片分类的方式邀请用户参与到设计当中「虽然这个成本是有点大的，但是一定大程度上可以解决落地性的问题」

理论上讲这是一个快速又比较准确是否满足用户需求的方法，可以在没有数据的情况下完成设计验证

当然，可用性测试的方法有很多，例如我们常用的用户访谈、问卷、demo随机测试等，你可以根据项目的内容、需求紧急程度以及资源、预算等来调整可用性测试等方法。

我们可以借助数据、可以采用可用性测试，这些都是做设计验证的其中一些方法。在实际工作中，我们是可以根据项目所需而灵活变通的，根据实际情况采用一些合适的工具和方法

总结

**

首先，从职责范围的角度来说，设计验证是设计师的本职责任，不做设计验证的设计方案是一个不完整的方案。设计验证主要也是为了验证是否达成业务目标、是否满足用户需求

所以，我们验证设计方案，也要从业务目标和用户需求两个方面出发：

  • 明确业务目标，不同的业务目标借助不同的关键数据来做设计方案；
  • 分析用户行为数据，借助用户在使用产品过程中的数据来验证是否满足用户需求

这两种方法都是以数据为工具，那要是没有用户数据呢？我们可以巧妙利用可用性测试，在没有数据时或产品上线前，通过可用性测试的结果反馈，来验证我们的设计方案

总的来说，就是以数据或者测试反馈等意见为工具，以业务和用户为核心，来验证当前设计方案等合理性。持续地精进和打磨优化现有的方案设计，给产品增色