正文
前段时间正好就有一个真实案例，某位同学需要为产品中一个新增功能进行设计。第一次的设计 review 基本都在疲于回答产品、开发同学提出的各个疑问。整个过程显得混乱无序，设计方案也受到了很多的质疑。
纵观整个 review 的过程，设计阶段主要存在有 3 个问题：
-
没有清晰的梳理可能存在的 user flow，导致大家在 review 的过程中会在多条 flow 中跳来跳去，相应的设计也暴露出不少没有考虑到的问题；
-
问题本质没有进行拆分，导致开发同学对于关注的模块化功能的设计存有疑问；
-
缺乏对分拆问题的深入研究，导致大家对每个设计节点有不同看法但又无法合理解释。
第一个问题我们在之前的周刊其实已经聊过多次，这里就不重复了，近期的主题中我们会更多的关注后面两条。
就像我们对数据库的操作都是建立在增删改查上一样，我们在日常工作所面对的设计问题大部分是可以被抽象出来的，而这部分内容则是我们设计师在专业能力方面不能忽视的一个重要部分。
再回到 Pattern 部分我们最核心关注的是两个部分，一个是 Pattern 应该如何划分，这与我们对问题的拆分思路有很大的关系。
另一个则是如何去定义每一个 Pattern 的信息以及解决方案，这对构建产品（或个人）的设计理念有着很强的关联。这里我们先来聊聊 Pattern 的划分。
Patterns 应该如何划分
最近还有一位会员问到为什么将 List 列表页在很多其他的 System 中的定义是 Component，而在上周的期刊我将它成为了一个 Pattern？
没错，确实大多数的 System 都会将 List 列表页划分为 Components ，不过定义上是有差异的。
