正文
当我们将它挪到一个具体的产品使用场景中，问题就出现了：
-
在产品设计中对于用户的信息告知与操作请求有好多种展现形式，我当前的这个需求应该选哪一个？
-
有两个类似的 pop layer 设计形式，第一个能点击空白区域关闭，第二个不能，我应该选哪一个？
-
现有的设计形式都不满足我的这个需求，我是不是再增加一个？
这些在日常设计工作中的问题还会给我们带来更多实际的影响，各种不同的设计让用户每次都需要一定的学习成本，开发团队也在不停的为新功能重新开发一遍，设计师、工程师、用户都会很难受。
有经验的同学在这里可能已经发现，上面这些现状的出现可能其实并不在需求本身，而是对应支持的这部分底层设计并没有一个清晰的逻辑和通用解决方案。
所以想要真正的解决这个问题，我们还需要先回到最开始，先去找寻问题的本质。
识别问题本质
我们在之前有提到过，Pattern 是一系列 Components 或 Patterns 的组合，为一系列问题提供全局通用的解决方案。
所以这里所提到的问题本质并不是业务上的某个具体需求，而是基于它们进行抽象所得出的问题本质。
我们先找一个真实的情境进行一次还原。当我们需要银行办理业务时，我们会与柜台上的工作人员有一次沟通。
