在做产品设计时，我们经常听到「场景」这个词，比如「用户场景」、「使用场景」等，这个词如何理解？这篇文章，作者尝试给我们一些解答。

任何理论成立都是有其前提的。

• 经典力学如此；
• 量子力学也如此；
• 狭义相对论同样如此；
• 广义相对论还是如此；

概莫能外。

这句话听起来像是一句正确的废话，对达到一定认知的人已然是常识；

但如果认知还没达到，就可能属于是见识；

理论不会无缘无故产生，它一定是在实践中总结并反过来指导实践。理论其实是用来帮助创造理论的人达到一定目的，解决某些真实问题的。没有脱离实践的理论，但实践是可以脱离理论的，这个时候就全凭经验，这是人类在起源的时候，面向的真实场景。因此，先有实践，后有理论，再有理论指导的实践，最后有实践检验总结复盘之后对场景中的问题解释力更强的理论，如此反复。

那么到底什么是场景？

场景是指需求产生的某种条件，这个条件包括但不限于环境，时间，地点，空间等，只有条件满足，这个需求才能成立。

https://zhuanlan.zhihu.com/p/77320824

这些条件存在于多个维度，可能是一些要素，或者要素之间的关系。

从这个定义中隐隐约约可以看出来，场景的定义有点像是基于”任何理论成立都是有其前提的。”这句话的推论，但又不不准确，改下提法“任何需求产生都是有其条件的”，这个条件可能是充分不必要的，也有可能是必要不充分，还有可能是充分必要的，不充分也不必要就不在这个讨论的范畴之内了。

场景定义了人、事、物、规则和边界。

理解场景的边界太重要了，因为边界决定了目标，资源，参与者和规则。

关于边界的理解，引用谭云杰老师《大象——Thinking in UML》这本经典的一句话：

边界本质上是面向对象方法的一个很重要的概念，与封装的概念师出同源。面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道，而对象内部则是一个禁区。我们把边界放大了看，这个世界上任何一种东西我们都不可能知道它本质上是什么，而只能通过它的行为、外观、性质来描述它是一个什么东西。行为也好，外观也罢，这就是这个东西的一个边界，我们是通过边界来认识事物的。

面向对象中，对象和场景笔者理解是一个对立统一的辩证关系。对象和对象外部一定范围构成一个场景，这个是一个相对宏观的场景；而对象内部实际也是一个场景，是一个相对微观的场景。首先对象和场景是满足对立性的，即对象是场景里的对象，场景是对象所在的场景；其次，对象和场景又满足同一性，因为对象其实也是一个场景，场景在更大的场景里又可以作为一个对象。对象和场景基于不同的范围，可以相互转化。

举个简单的例子：人作为一个对象在人类社会这个大场景里，而人类社会相对动物，动物相对有机生命体，有机体生命体相对世间万物，一层一层往上，就是对象和场景的不断转化，特别有趣儿。这么看人类是真的很渺小，这就是为什么“人类一思考，上帝就发笑”，完全是两个相差很多层级的物种。

有了对象和场景的理解，就很容易去收集需求，并做问题陈述了。

1. 先确定场景是什么？
2. 再确定场景的目标是什么？
3. 场景中的利益相关方都有谁，分别关注什么，需要做什么？
4. 目标实现方式是什么？
5. 当前实现方式的痛点有哪些？

有了对这些问题的精准把握，出合理的解决方案差不多就有个七七八八了。

结合工作的一些案例来运用：

在做一个软件功能时，我们确定的需求场景通常是一个正常流程的场景。那假如出现了异常场景是不是还是使用这个功能去解决呢？通常来讲，还真不一定，大多数情况下完全不是。因为正常流程和异常流程分别解决的是正常场景和异常场景的问题。两个场景类似一个硬币的两面，抛起来落地后同一时刻仅有可能一面朝上，不可能两面朝上。这个说法当然也是有前提的，就是定义了什么是上，什么是下。

那通常什么情况下会产生异常场景，通常是NO ZUO NO DIE。系统功能本来是基于最佳实践而形成流程固化，人在场景中没有按照规范去操作，最根本的解决办法就是继续做一次，直到做对，否则就无法实现目标。通常人的行为没有对错之分，而是向着目标，确定哪个达到后经过路径更短，花费的成本更低而已。

而规范参与者的行为，还得通过管理培训去做，让参与者感受到按照规范产生价值，违规操作产生成本，从而产生规范操作的意愿。再通过参与者培训和赋能，提升参与者在这块的能力。过程中可以通过绩效考核指标去衡量，通过总结复盘反映出到底哪些地方不规范，从而给出针对性的解决方案。

通过案例可以看出，解决问题前必须要先看场景。

为什么光读书没用，就是因为读的书中的理论成立的场景和咱们自己的场景不一样。纸上得来终觉浅，绝知此事要躬行。

没有场景，就不会有实践；

没有场景，就不会有产品；

没有场景，就不会有服务；

没有场景，就不会有价值。

以上