作为交互设计师的你有没有遇到过如下情况：1. 产品迭代交付前，测试的同事经常火急火燎地跑到你办公位说：“这个创建按钮点击之后是不是少了一个校验呀？” 2. 上线之后，用户在使用某个特殊场景时，突然发现此路不通？ 3. 某个输入框的特殊字符忘记限制，导致任务执行失败的情况。我保证99.9%的交互设计师基本上都遇到过类似的情况，给自己留点余地，不排除还是有那么0.1%的牛人的。笔者在工作过程中也时常为这类没想到的场景捶胸顿足，经常被测试、开发、用户拿着千奇百怪的场景、逻辑漏洞戳脊梁骨。这迫使笔者开始思考一个关乎设计水平，设计师颜面的终极问题：设计师应该拿什么葵花宝典来抵挡这来自场景、逻辑的枪林弹雨？以下是作者这么久以来的积累的一些避坑防雷的小方法，希望各位同行在设计进阶大道上少些 没想到、多些 想得到；少些窘迫愧疚，多些淡定从容；本文展开的前提是当需求场景相对明确的情况下，交互设计师可采用什么方法，使产品尽可能的场景、逻辑闭环，交互文档尽可能的完善，避免等到测试阶段或者上线后出现大的漏洞，导致项目延期、给项目组织带来不必要的损失。下文记录的是笔者在日常工作中的一些小思考，若有不足，还望各位观者不吝赐教；如果发现业界或者学界已经有相关的理论研究，烦请告知我一声，大家一起学习成长呀！ ;）
本文的大致内容基本上可以用下图来概括了，为了方便行文，笔者暂定义下图为场景漏斗模型。通过基本流程场景、复杂流程场景和基础检查项的三部曲基本涵盖所有的场景，每过滤一层，我们遗漏的场景将会少一些，叫所有场景无所遁行，直至设计方案至臻完善。
01 基本流程场景
基本流程场景一般涵盖的是业务的主要核心场景和一些细分场景，一般对应需求的核心功能点。按流程分类，笔者把它定义为两大类：核心场景和分支场景。可以说基本流程场景为所有交互设计师工作的重头大戏，基本上占整个交互设计工作比重的70%。所以需要放在第一阶段来完成。
· 核心场景流程
核心场景流程一般对应产品的核心功能，给用户带来的主要价值，企业的核心目标。因此核心场景的确定基本上为产品定性了。一般一个平台的核心业务场景不会很多，淘宝等购物平台的核心场景基本上都围绕用户购买商品这一主题展开、微信等社交类平台的核心场景为都是为支持用户沟通交流而产生的。
如果从场景、流程的闭环角度出发，可以给核心场景再分个类：正向场景流程和逆向场景流程。正向流程一般指的是从出发点到终点，从上至下所经历的过程。逆向流程与正向流程刚好相反，它一般指的是从终点返回出发点，从下至上的一个过程，与正向流程产生相反的一个结果。从交互设计角度讲两种流程均是为了完成某个特定任务，用户需要经历的步骤，但是两者产生的结果是恰好相反的 。举几个例子：用户在网站购买商品的动作就为正向流程，买的不满意了需要退货所经历的流程就为逆向流程；用户新增某个条目为正向流程，删除某个条目就是逆向流程。这种有来有回，有增有减的过程恰好完成了一个流程的闭环。因此我们在梳理核心场景或者设计核心流程的时候，可以按照这种正向、逆向流程进行分类设计。为了更方便大家理解，以经典的购物场景为例：
任务1：用户需要在网站/app完成一次购物。那他经历的正向流程如下图1所示。
任务2：用户因发现购买产品地址填写错误需要退货。他经历的逆向流程如下图2所示。
· 分支场景流程
分支流程顾名思义，就是非核心场景流程，为了方便用户更好的达成某个目标，是在完成主流程场景的过程中派生出来的一些小点。主要用于满足一些小的场景。这种虽然不如核心场景流程那么重要，但是也是设计过程中不可忽视的一部分，出错的往往就是这写不起眼的分支场景。仍然以购物场景举例，用户在选择商品的时候不着急买，因此就先将其加入购物车或者添加进收藏夹，等需要时再购买，因此该购买的流程就发生了如下的转变。
02 复杂场景分析
复杂场景之所以复杂的原因在于，它受多重因素影响。只有设计考虑到位了，用户在真实使用过程中才不会遇到此路不通的困扰。如何保证设计师能够过五关斩六将，将这复杂的流程场景条分缕析的排列清楚？还要做到一个场景不落？笔者曾咨询过一些设计同行，他们大多数的第一反应是靠经验，多思考。笔者私下仔细琢磨了一下，发现还是可以将这些流程场景进行一定的梳理归类的。我们只需要找到影响因子和因子的关联关系基本上这个场景梳理工作就完成了。简而言之就是先将项目所有相关的影响因子罗列出来，进行排列组合的关联，剔除非关联项，梳理出关联项，然后根据情况想交互方案。
复杂流程场景的影响因子大致可以分两类：客观影响因子和业务相关因子。客观因子指的是非业务本身的一些外在因素，相对来说比较微观的影响有：人、网络、硬件设备、操作系统、多平台，等等。大一点扩展到宏观的就有：政策、文化、宗教等相关因素。 业务相关因子指的是业务本身的因素，主要指业务的功能点。例如创建条目、删除条目、修改条目、查看详情等都算作业务本身的因素。
· 客观影响因子
因宏观的因素相对比较固定，本文仅聚焦在微观层面的影响因素的探讨。
微观的影响扩展开来讲大致有以下几种：1. 人的影响：此处的人主要指的是不同角色、类型的人，卖家和买家看到的内容和对应的场景是不一样的；领导层有的权限，普通员工不一定有；会员用户与非会员用户享受的内容是有差异的；不同文化的人的语言、思考方式都是所有区别的。因此设计前需要将用户分好角色或分好类，这是设计方案展开的前提。 2.网络因素的影响：这个是所有网络设备的普遍影响因素，所以在设计时需要考虑到网络相关的影响，例如网络不好的时候，给出“网络不佳，影响xxxx操作”之类的提示信息会是比较好的体验。 3.硬件设备的影响：有的平台是电脑端，移动端都支持，还有些是物联网相关的设备，不同操作设备的交互方式，屏幕大小分辨率都千差万别，因此硬件设备的信息也是在设计前期沟通中必不可少的沟通项。 4.操作系统，目前主流的操作系统有IOS、Windows等，不同的操作系统，同一个系统不同版本要求的规范、交互方式差别也很大。5.多平台指的是该平台上架的第三方平台，可能是app store、可能是浏览器，可能是微信小程序，可能只是一个h5页面，这些平台的会对你产品的内容，形式、版本等作出相应的规定，这些都会对设计的形式产生很大的影响。
· 业务相关因子
业务相关因子是围绕业务的本身功能，看功能间有啥关联关系和限制条件。不同业务对应的因子也大不相同，所以业务相关因子的梳理要结合业务，需求、功能点。例如：音乐类app大的因子分类可能有：操作、状态、歌单、收藏；社交类app的影响因子可能有：添加好友、发送消息、撤回消息、语音通话等等。
影响因子好找，但是关联关系如何建立呢，笔者想了一个办法，就是数学里面的排列组合方法。在此文的应用，就是将所有的客观与业务相关影响因子罗列出来之后，通过排列组合方法，互相连线，找到相互之间产生影响的组合，去掉彼此间不产生反应的组合。具体步骤如下所示。
· 关联分析三部曲
第一步：找关联因子，列出关联组
尽可能多的罗列出对我们交互设计产生影响的客观影响因子和业务相关因子，彼此连线看产生不产生关联反应。有则保留，无则擦除。注意第一步的因子可以是较粗的粒度，可以是一个大类。这样做的目的是方便我们快速筛选，可避免因过早梳理细节，导致场景缺漏或者理不清的情况发生。
为了尽可能的包含更多场景，因此连线可以分为：客观影响因子内部彼此之间的连线、业务相关影响因子内部彼此之间的连线、客观和业务相关因子的交叉连线。他们的大致示意图见下图，有联系使用绿色对勾表示，无联系的使用红色差号表示。
第二步：找子关联因子，列出子关联组
将第一级有关联反应的一组因子分别下钻至下一级（有则下钻，无则不需要），再给他进行一个排列组合的连线，将组合之后产生关联的一组因子圈出来。擦掉无反应的组合因子。若业务本身非常复杂，纵向支持继续下钻很多级，直到层级穷尽。篇幅有限，本文仅展示最小单元（两级）来做示意。从上图三个关联表中挑选第二个“业务相关因子内部彼此关联”作为示例。从上表中可以看出因子A与因子C存在关联关系，因此将两个因子下钻出子因子“因子A-1、A-2、A-3”、“因子C-1、C-2、C-3”出来，子因子互相连线，剔除彼此不相干的因子组，留下有关联的因子组。可能分析完，可以梳理出“因子A-1”和“因子C-1”、“因子A-2“和“因子…”两个关联组。
第三步：梳理交互方案
根据圈出来的组合，判断是否需要出交互方案。因有的场景是较为特殊的，如果不做相应处理，可能会影响体验或者用户使用，因此需要设计师出交互设计方案。但有些组合场景虽然彼此间有关联，但是可能是一些系统的，自动处理的，无需设计师关注的，因此无需出解决方案。例如：点击购买商品的时候，商品突然售罄了，此时设计师需要考虑此场景的处理，弹窗告知用户还是购买按钮置灰处理。用户在线上安装一个插件，点击之后需要等待一段时间才能完成安装，这个状态显示是需要设计师考虑的场景。
为了方便理解，我们可以对3个关联的场景按照步骤进行一个举例。看他们经过3步关联操作之后，得出什么样的关联场景，因子之间是有哪些限制，如何协作的。以及交互设计对应的解决方案。
· 客观影响因子内部彼此关联举例
下图客观影响因子内部彼此关联的示例。我们随机挑选客观影响因子中的人、网络和操作系统三个因子。
· 业务相关因子内部彼此关联举例
第二个为业务相关因子内部彼此关联的示例。我们以一个场景来举例，也是笔者近期在做的项目。我们平台支持对用户的电脑主机进行管理，主要任务是机器的一个创建、监控等。它的业务相关因子有：创建人、创建时间、所属团队、机器状态、开关机操作等等。
· 客观影响因子与业务相关因子的交叉关联
第三个为客观影响因子与业务相关因子的交叉关联，我们随机挑选“人”、“网络”作为客观影响因子；业务相关因子的背景假设是一个工单管理平台，我们挑选几个业务相关因子：所属团队、状态、操作。
03 基础检查项
刨去上文分析的，基础检查项是设计过程中极其容易遗漏疏忽的。以笔者的经验，大致有：前端组件相关的、交互动效相关的、表单相关的，图片相关的。这一般需要整理成交互评审前的检查项，因其细碎、繁琐及其容易被疏漏。
前端组件相关的报错的大致有：输入框的字符校验、为空校验、字符长度检验、默认提示或者默认值；对于名称相关的是否需要重名校验；对于账号密码相关的需要星号隐藏展示、密码输入错误次数是否需要上限限制；下拉选择框的内容是否需要根据所属人/团队做过滤展示，下拉框默认加载多少条数据；过滤是否需要保留数据，下次进入默认过滤；
交互动效相关的：点击、悬停、双击、不可点击等交互状态需要规定清楚；输入框的正常状态、输入时的状态、输入错误报错状态、无法输入状态均需要作出清晰的说明。
表单相关的：是否支持表头过滤，排序；每页默认显示数量、翻页、跳转页；空页面；列表搜索是按名称字段搜索还是按照其他的；
图片相关的：头像类的是否提供默认选项；图片的排序按创建时间还是热度等；图片的屏幕适配限制；内容过期、不可用等状态的标记；图片上传的大小、尺寸等限制；图片加载时间过长如何处理等等。
大家可以根据自己工作的情况，去完善补充基础检查项场景的内容。
以上方法是笔者在设计的日常工作中总结出的一些经验和方法，不一定完全科学和适用，大家在使用的时候可以结合自己的实际情况灵活运用。在强调一下本文的出发点：“希望各位同行在设计进阶大道上少些 没想到、多些 想得到”，“不求尽善尽美，但求有所启发”。在文章整理过程中从很多设计同行分享的文章里得到很多帮助。文章末尾会附上链接，大家感兴趣也可以一并参阅。
参考资料
1. https://m.zcool.com.cn/article/ZMTAzNTU3Mg==.html
2. https://zhuanlan.zhihu.com/p/54499141