(转）面向场景而非功能进行设计

原文：https://mp.weixin.qq.com/s/ZsKRDcsaQexfmjYaMcnS5w

前段时间看到过老黄（三节课联合创始人黄有璨）关于共享经济的一篇文章，里面提到了一个用来判断是否为伪共享的模型，即自然流量+随机消费，满足这两个条件则可看作“伪共享”。

 

在这个模型中，前者指的是与传统行业一样看天吃饭，纯粹依赖自然流量，没有办法很好的将需求端和供给端集中起来，后者指的是随机性的需求，即用户本来没有这个需求，是在某个环境中被激发出来的。

 

其实这个模型用来判断很多项目都是成立，满足不了前者说明没有办法很好的解决用户的问题，也就没有办法很好的形成需求闭环，满足不了后者，说明这个需求没有特定的场景，很有可能需求本身就是个伪需求。

 

这篇文章重点谈论的是后半句，也就是非随机需求，即用户在特定场景下的具体需求。没有场景，何谈需求，没有需求，何来解决方案，何谈产品价值与用户价值。

 

做产品的本质就在于通过解决供需问题来创造新价值，进而打破旧的利益平衡，让己方在新的利益平衡中占据有利的地位。

 

先来说个很烂的老梗，福特与马的故事，用户总是会告诉你需要一匹马，一匹更快的马。那用户是在什么情况需要这匹马的呢？是在两座城市之间奔波时，是在赛场上，还是说在耕地的时候？

 

这三种不同场景下对应的需求可能都是更快，但是对应的解决方案可能千差万别，在城市之间奔波时用户需要的可能是汽车，在赛马场上用户需要的可能就是一匹更快的马，而在耕地的时候可能用户需要的其实是个拖拉机…

 

你看需求的场景如此重要，会导致失之毫厘，谬之千里。那场景到底是个什么东西呢？

 

场景是什么

 

先来看一个锤子发布会上他们产品经理分享的一个案例， 今年锤子发布会上介绍了一个伪装来电的新功能，这个功能是提前设定好时间，然后在特定的时间会有电话打进来，并且可提前设置好打进电话的内容和语言种类（诸如各地方言、普通话之类）。

 

当时锤子的产品经理朱萧木分享了这个功能拍板的过程，最开始这个功能没有确定要做，因为锤子的另外一个产品经理觉得这个功能没有对应的场景，没必要做，所以两个人就争执不下。

 

后来朱萧木就拉着另外一个产品经理开会，说不讨论出来一个结果两个人就不出来。结果几个小时之后，另外一个产品经理说我好希望有个人能打电话进来，于是后来就有了这个伪装来电的功能…

 

最开始锤子的另外一个产品经理觉得没有实际场景，不需要做这个功能，然后朱萧木就拉着他开会，这个时候另外一个产品经理就深切感受到这个场景原来是真切存在的。

 

那么问题来了，场景究竟到底是什么，如何来定义呢？

 

网上有很多关于场景的定义，感兴趣的话可以自行搜索下，个人觉得用记叙文的六要素来概括最为恰当，既涵盖了所有的部分，又容易记忆。这六要素分别就是时间、地点、人物、起因、经过、结果，即在什么时间，什么地点下，什么人因为什么原因产生了什么欲望，最终通过什么手段来满足这种欲望。

 

这六要素能够构成一个完整的用户故事，在这个用户故事中，我们可以看看有哪些是用户的欲望没有很好满足的，有哪些是用户很不爽、有负面情绪的，或者有哪些方式是能够帮助用户更好的满足欲望的，一旦发现了这些，可能就发现了一个新的机会点…

 

接上文的案例，用六要素展开来看的话：

 

时间不详，地点是在会议室，人物是朱萧木和另一个产品经理，起因是两个人希望把需求定下来，不讨论出来结果就不出来，经过是在一段时间的讨论之后另一个产品经理觉得自己想脱身，但是又没有办法脱身，结果是觉得这个伪装来电的功能是有必要的。

 

从自身的角度来看，这个场景是成立的，那在其他用户身上这个场景是成立的么？确定了场景的真实性，之后就是基于用户量、出现频次以及重要紧急程度来进行后续的判断了。

 

为什么要面向场景设计

 

上一节中我们提到了什么是场景，核心要素就在于时间、地点、人物以及起因、经过、结果。那我们为什么要面向场景来进行设计呢？除了在引言部分提到的不同场景下相同的需求的解决方案是不同的，主要还有以下几个方面，只为抛砖引玉，因为肯定还有其他的原因…

避免伪需求的坑

 

之前的文章中提到过一个需求三角的理论模型，即缺乏感+目标物+消费能力。放到具体的场景里就是，因为环境激发了某种缺乏感，然后基于环境和个人因素产生了某种目标物，从而产生了获取这种目标物的动机，这种行动的动机减去用户需要付出的成本后，最后构成了用户的行动欲望。感兴趣的话可以去看下之前的文章…

 

如果连真实的场景都找不到，那也就很难激发这种缺乏感，没有需求的源头，也就不会有后续的环节。产品归根到底是需要满足特定用户的某些需求的，而需求产生的动机就是因为在某个场景下被激发出了某种缺乏感，连特定的场景都没有，那这个需求本身很有可能就是一个伪需求…

 

牢记我们不是目标用户

 

慢慢的也算入行了，也越来越不敢随便分析/评论一款产品了。原因很简单，因为我既不是产品的目标用户，又不清楚产品背后的决策环境，甚至都不知道这个功能出现的场景是什么，要解决什么问题，连管中窥豹都谈不上，又怎么敢随便评论。

 

在设计我们自己的产品的时候也应该时刻牢记，我们不是产品的目标用户（如果是也需要注意设计者思维与使用者思维的差异），而且我们也不清楚用户在处理任务时的心理和行为是怎样的。通过场景分析，我们可以通过讲故事的方式来模拟用户可能遇到的问题，从而发现用户的心理、行为变化。

 

不要忽略真实场景

 

记不清之前在哪本书里提到过这样的一个案例，说是哪家便携式设备厂商为一些户外爱好者开发了一些便携式设备。然而销量并不好，因为这些户外爱好者去的很多地方根本就没有信号…

 

很多时候我们产出设计方案的时候都是在舒适且网络环境良好的办公室，而我们的目标用户可能面临着各种各样的问题，比如网络信号不好、任务随时可能会被中断、经常需要单手操作等等…面向场景能更好的模拟用户的真实使用场景，进而更好的处理这些异常问题。

 

用户之所以选择使用某个产品都是因为这个产品能够满足Ta的某些需求，而用户使用产品也是基于某个特定任务的。所以我们在添加新功能时也需要清楚这个功能解决了什么人在什么场景下的什么问题，而不仅仅是为了功能而功能。

 

如何面向场景设计

 

上文中也提到了，产品是为了解决某些人在某些场景下的某个问题的，而我们的目标用户肯定是真实存在的，也就是说这个场景肯定能映射到现实世界中一个具体的人身上的。换句话说就是，一个人，一个问题，一个方案。

 

场景列举

 

现在的场景大致可以分为三类，一类是原先在线下的场景，目前尚未实现在线化，也就是原生场景，一类是纯粹线上场景，也就是网生场景，还有一类就是线上与线下结合的场景，也就是混合场景。这些是大的场景，之后才是小场景，各场景的图谱可参考下面的图片。

小场景指的就是用户使用产品完成任务的主线流程，以共享单车为例，这是一个混合场景，需要线上与线下相结合，解决的是上班族或者校园学生半径一公里范围内的出行问题。整体的主线流程可分为找车→开锁→骑行→还车，这几个小场景都是需要与产品发生交互的环节。

 

场景分析

 

明确了场景之后，就需要能够对场景进行更深入的分析了，分析的主要目的是明确这个场景中用户可能会遇到的问题，并且需要明确用户要完成哪些任务，进而为用户提供一些必要的帮助信息，从而帮助用户更好的完成任务。

 

在整个分析的过程中尤其需要关注用户情绪的变化，因为这是用户的需求没有被很好满足的信号，也就意味着新的机会点。

 

接上文共享单车的案例，在找车这个小场景下用户的主要任务是发现单车，所以产品需要解决的问题就是让用户知道车在哪，并且引导用户去找到车。所以摩拜给出的解决方案就是利用GPS定位来帮助用户发现单车，同时利用地图导航来引导用户去找到车。

 

场景里面的其他要素会延伸出一些其他的问题，比如天太黑光线不好怎么办（时间），有其他的人把单车骑走了怎么办（人物），车坏了怎么办（结果）。这些都是问题，发现了问题，也就比较容易找到对应的解决方案了。

 

场景设计

 

场景设计就是基于场景分析中发现的问题来给出合适的解决方案，在此过程中需要考虑多方面的因素，一方面需要基于用户的任务流程来考虑，需要能够为用户提供合理的帮助和必要的信息，从而让用户更好的完成任务。

 

另一方面还需要平衡用户目标与我们的目标，比如用户的目标是能够方便的出行，最好性价比高，当然免费更好。而共享单车企业的目标肯定是占据更大的市场份额，并且能够盈利，这两者之间的目标可能是冲突的，这就需要去做合理的平衡了。

 

此外解决方案还需要考虑优先级与性价比，资源肯定是有限的，而且对于用户而言，核心的场景和任务肯定只有那么几个，所以核心场景下的问题肯定需要优先解决。比如ofo早期的大黄车虽然造型不美观，而且也不太好骑，但是依然有很多人在用，因为对于出行这个场景而言，有用是第一位的，其次才是好不好用…

 

性价比涉及到另外一个问题，那就是成本与收益，成本高收益低而且没有上升空间的话，那这个方案就需要慎重考虑了。ofo从最早期的机械锁到现在的单向密码锁，一方面是出于保证开锁率的考虑，另一方面很有可能就是基于性价比的考虑。

 

以上就是本文的主要内容，从一个模型过渡到场景这个话题，然后从场景是什么、为什么要面向场景设计以及如何面向场景设计这几部分来展开，欢迎斧正、指点、拍砖…