这六点无论是对产品新人还是有经验的PD都是很重要的，按照整个流程可以避免很多问题，也会让我们的工作变得有节奏，而不至于丢三落四，确实对产品的把握。
这个问题有很多种答案，在我所有项目中，交互框架的确定是非常重要，非常费时费力的，但是实际中又很容易被忽略，被轻视，入行的新人特别容易陷入到细节自我陶醉，而忘记产品的宏观建设。
这是很危险的。
回答这个问题我们首先谈一谈最熟悉的三个文档——MRD、BRD、PRD。三者可以完整的概括一个产品从想法到雏形的历程，每个人对三个文档都不陌生，但是写得好又是另外一回事了。产品的交互框架就在这三个文档中，但是却不够独立和尊重，往往被忽略和轻视，无法将骨头从肉里清晰的剔除出来，总是零零散散。
三个文档比较抽象，一般人驾驭不了，也就更无法剔出骨头了。我今天介绍一个新的方法流程，这样的流程才是做产品本质的精髓，而三个文档只是漂浮在这个精髓上面的肥油罢了，不会写也没关系。
一个产品从一个灵感到真正可操作使用的实体，需要经过的流程很多，我们今天只谈到产品设计环节的细分步骤。
1. 定义形式要素、姿态和输入方法
形式要素指：web、移动端、pc端、ipad、智能硬件产品等；公共场所还是私人领域、光线充足还是比较暗、小巧轻便还是功能为先。这些产品的使用环境要素需要我们结合人物模型和使用场景提炼出来。
姿态是指用户在和产品交互时，付出多大的精力和时间，以及用户的姿势等信息，例如PC端一般放在桌子上，用户坐在椅子上比较常见，也会放在腿上，坐在沙发上。姿态决定了用户对产品的定位和喜好，为我们对产品的使用场景提供参考依据。
2. 定义功能性和数据元素
很好理解，功能性是用户希望通过某产品获得什么样的服务，转化成我们得设计语言就是功能。功能是一个抽象的概念，它以功能元素为载体而真实存在。功能元素包括数据元素操作工具、数据视觉和结构化管理方式（交互设计精髓4-100），例如，我们在设计产品时，用户可以点击某个按钮删除某条信息，可以点击某个空间切换页面布局。
数据元素更方便理解一些，就是我们需要在产品中呈现给用户的具体信息，包括文本、图片等所有可见的独立数据。难点在于，我们需要在设计产品时为数据分类，将实现模型中的数据元素转化为用户日常界面的表现语言来描述，并根据数据间的优先等级决定是否展示（一定要考虑数据之间的关系）。注意：数据元素的集合也就构成了技术开发中的搭建数据库，需要对数据自上而下进行拆分，能够整合而不至于散乱。
3. 确定功能组和层级
经过之前的功能性和数据元素的系统整理，我们需要将这些根据需求定义出来的功能和数据进行分类分组，以便梳理产品的架构，由微观到宏观。简单点讲就是讲产品的所有数据和功能打包分组，划分到每个一级板块，对产品的基本架构尤其更清晰的认知。这一步骤需要注意不同功能和数据的对接，数据和功能横向上的层次比较。
一个产品有很多功能，按照重要性可以分为核心功能、次要功能、辅助功能、补充功能。那么不同的功能也具备不同的层级和属性，将同类别的功能打包在同一个功能组，并按照重要性和产品场景划分层级，哪些放在首页，哪些显示，哪些隐藏，功能之间的逻辑顺序；一般情况下，功能是否属于同类别是根据数据是否相关来决定的。
4. 勾画交互框架
经过对功能和数据的分组，我们可以大体在心里对产品的架构样式有了感性的认识，那么勾画简图是很快的。我们在这里需要注意的是，将所需要组合的功能组合层级，通过块状的元素描画出来，不要做过多修饰，简图更多承担着初审的任务，付出过多的细节工作影响了对框架的理解，也会由于过早牵涉细节缺乏产品的统一性。
在这一板块，我们更多地需要尝试，这种尝试必须尊重交互原则和模式，并且是经过验证或者有根据的，而不是随心所欲，那样会使得产品脱离现实，变得迷茫或者低劣。多绘制几个方案，比对优劣，选取，然后定稿。只有对所有的框架都进行了反复修改后，产品的交互框架才算基本定型——不要妄图一次成稿，不修改。
5. 构建关键线路情景剧本
我们首先定义一下什么是关键路线——结合使用场景，针对每个功能理想状态下的路径，这种路径一定具备高频、精魄、重要三个标志属性。那么接下来我们讲一下关键路线的使用方法和作用
关键路线就是，结合人物模型+场景+数据和功能元素，以任务为依托，使得最初设定的人物模型和交互架构产生充分、反复、频繁的接触，并最终通过磨合，发现不合理的设计，并对产品的架构产生更加深刻清晰的认知。对关键路线图的使用越频繁，越能够对产品的细节问题进行深刻考量。这和我们在可用性测试中提到的任务走查很像，只是后者更侧重对产品测试，而我们是在架构完善过程中对该方法的运用。
6. 通过验证性的场景来检查设计
既然是验证性的场景，那么这里提到的场景一般都是针对当前设计中遗漏、丢弃、新增和次要的场景，由于设计过程的不完美性，因此我们必须对已经完成的架构采用这场验证性场景进行回归检测。
1）替代场景
替代场景是人物模型决策过程中，关键节点的可替代选择，包括例外情形、不常使用的工具和试图和次要人物模型的部分用例以及变体。
2）必须使用的场景
有些场景是必须使用的，而它出现的频次和场景又很不普通，例如恢复出厂设置，清空数据，这些都是周期很长，频次很低的操作，但又是针对这一类需求必然进行的场景步骤。因此，设计中经常遗漏。
3）边缘情形场景
这里提到的就是异常情况处理。我之前在一片文章中提到将产品设计在功能上分为正常功能和异常处理。那么这里就是提到的异常处理。异常处理也成为边缘情形场景，例如，打电话突然断电，聊天突然断网，打字手机没有收录该字。这类场景不是设计的主要场景，也不应该付出极大的精力，但是由于涉及到系统稳定性和产品的可用性，一般在开发过程中经常出现，我们需要对这类情形进行统计汇总，并和开发对接，避免开发中BUG的频次，也满足用户的异常需求。
关于交互设计框架，就讲这些；这六点也来自交互设计精髓4（106），结合了我自己的理解。这六点无论是对产品新人还是有经验的PD都是很重要的，按照整个流程可以避免很多问题，也会让我们的工作变得有节奏，而不至于丢三落四，确实对产品的把握。
