在画线框图前，需要做什么准备

“kyo，当你拿到一个需求，都是怎么做交互的啊？”今天公司一个开发跑来跟我交流技术，问到一个交互设计师都是怎么开展工作。在大部分开发眼中，交互和UI的区别是，交互输出黑白灰线框图，UI输出七彩视觉稿（少年，这槽点甚多啊，就不怕被追着打吗）。为了团队和谐，我牺牲了宝贵的午休时间，向开发科普了一波交互设计，顺便也写篇文章总结日常工作中进行交互设计的主要流程。

提到交互设计，不得不提到交互最常见的输出物——线框图。然而很多人都有一个误解，觉得交互设计的工作就是画线框图，但其实线框图只是一个结果，并不是交互设计的主要过程。实际交互设计的主要工作恰恰是思考分析怎么画线框图，画一个框简单，难的是知道为什么要画这个框，怎么画这个框才是最恰当的。

1、目标是什么

开始设计时，首先要思考的是，目标是什么。整个设计流程都将围绕目标展开，如果在目标不清晰的情况下就埋头画交互稿，就可能出现离题万丈的情况，白白做了苦功却没有得到有益的结果。

1.1产品目标

产品目标是做事情的真正动机，是内在的一个驱动。多数情况下产品目标都是“成为某某行业领先/第一/最大的xxx企业”，用更通俗易懂的方式来说，就是——赚钱。包括B端和C端产品，核心的产品目标都是赚钱，或者说，赚更多的钱。

1.2业务需求

业务需求＝业务目标＋业务目的

业务目的——是一个抽象概念，可以理解为一个对产品有益的方向。例如提高用户粘性，提升企业工作效率等。

业务目标——通常是一个可衡量、可数据化的结果和指标，通常也是管理层和产品经理比较关注的一个指标。例如增加注册用户数，缩短审批等待时间等。

对于业务目标，通常用GSM模型将目标转化为一个可见动作，这样可以将业务需求、产品界面、用户行为联系在一起

业务需求分析表格

所以当老板或者产品经理提出一个业务需求，将需求拆解并且具体到一个与用户行为相关的衡量指标上，如果业务需求过于模糊或者不合理，务必与PM确认这个需求背后的业务目标，避免做无用功。

1.3用户需求

用户需求=目标用户+情景场景+用户目标+用户行为。

要了解用户需求，首先要进行用户研究，确定产品目标用户。一般使用定性研究了解用户。特别进行新产品开发前，定性研究可以帮助我们了解这个需求是不是“伪需求”，也可以让我们了解用户有什么特征。

定性研究包含两个阶段：前期资料收集和用户访谈。

前期资料搜索主要包括：文献综述、竞品分析、利益相关者访谈、专家访谈，通过这几个步骤可以描绘一个假设的人物模型，为下一步用户访谈提供基础。

用户访谈：通过直接与用户进行访谈，观察他们的行为，可以从中了解用户的行为模式以及用户目标，找出不同类型用户之间的区别，将有着相同行为模式的用户归为一类，成为一个特定的人物模型。在后续的设计都将围绕人物模型展开，人物模型所代表的用户，就是我们的目标用户。

在这里要说一下，B端的人物模型一般基于角色岗位和工作内容，与ta的性格、爱好关系不大。C端的人物模型更关注个人期待和想法。

用户目标在用户研究的过程中了解和提炼。用户目标有三种不同类型：

体验目标（本能层次）——用户想要什么样的感觉。关注用户的感官体验，简单来说产品的操作、色彩、音效要令人愉悦，满足用户的情感期待；

最终目标（行为层次）——用户想做什么。用户使用产品时执行任务的动机，关注具体的用户行为。设计具体某个功能和模块时围绕用户行为展开。特别在B端产品，要重视最终目标。

人生目标（反思层次）——用户想要成为什么样的人。产品整体设计、战略、品牌的关注点。对于C端产品，致力于帮助用户实现人生目标。

用户总是在某个情景场景下使用产品，部分设计师会将情景场景简化为空间和时间，实际上情景场景应该是用叙事的方式简明的描述运用产品或服务来实现具体目标的一个或多个人物模型。这话有点拗口？简单来说，情景场景就是在讲故事，人物在某个环境下，为了实现动机/目标，使用了某个产品。在这里，人物、环境、目标/动机、行为都是建立在前期用户研究的基础上，然后将产品加入其中，组成一个完整的情景场景。

1.4明确设计需求

当确定情景场景后，对其进行分析，提炼出设计需求

举一个简单的例子:Andy是一个电影爱好者，借助一款购票app便捷购买电影票。

情景场景：某国外大片即将上映，Andy购买了一张电影票打算周日观影。

自此，用户需求就变得非常明确：

用户场景（每当）：大片上映

用户目标（想要）：观看电影

用户行为（就能）：购买电影票。

当得到用户需求，还需要对其进行提炼，通常围绕“创造动机、排除担忧、解决障碍”三个方面入手。在用户使用产品前，我们应该为用户创造使用动机，排除用户对于产品的担忧，设计师可以回顾用户访谈内容，找出可能存在的动机和担忧。为了顺畅使用产品，优化操作过程和逻辑，解决障碍。

还有另外一种方法是分解成数据元素、功能元素。

数据元素——必须在系统中呈现的对象和信息。常见例子是账号、人、地址、文件等基础信息。从情景场景中可以提取执行动作需要用到的数据元素。

例如一个B端产品，用户填写申请表单，需要整理出表单内容相关的数据。

功能元素——对系统对象执行的操作或动作，通常会转换为界面控件，可以把功能当做产品的动作。

例如拨打电话功能，选择联系人，最近通话，直接拨号，语音拨号这几个功能元素都可以满足拨打电话功能。

2、搭建设计框架

当目标和需求都整理好，可以开始搭建设计框架。不要一开始就进入细节设计，先从产品信息架构和产品使用流程入手，搭建产品的整体结构。这个阶段的输入物都已低保真为主，方便与团队成员进行沟通以及快速修改方案。

2.1信息架构

用官方的说法，信息架构是进行结构、组织方法及归类的艺术。

用通俗的话说，用符合用户心理模型的形式，将数据元素和功能元素进行分组。良好的信息架构可以让用户更容易理解产品，并通过产品完成想达成的功能。

竞品分析

在改版或者市面有大量同类产品的情况下，通过竞品分析，找出不同竞品信息架构的差别，可以帮助快速构建产品的信息架构。通常找3-5个竞品进行，分析过程中着重关注共性和差异。

对于共性，可以看着用户使用该类产品的用户习惯，在进行设计时，要尊重用户习惯，不要在证据不充分的情况下违背用户习惯，做出差异过大的设计。不在不必要的时候进行创新。

对于差异，反映不同产品之间产品目标和用户群体的差别，需要设计师思考造成差异的原因，并结合实际情况设计信息架构。

卡片分类

对于市面上缺少竞品或者行业针对性较强的B端产品，可以使用卡片分类法探索合适的信息架构。

卡片分类法是设计师提供一组产品功能或信息卡片，用户对此进行分类。卡片分类有助于设计师理解用户心理模型。当用户完成分类，设计师与用户交流为何这样分组，背后的原因是什么。还可以为用户安排任务，观察用户执行过程中用到哪些卡片，以及使用的顺序。

对于卡片分类的结果，统计结果后进行趋势上的解读，关注哪些卡片分组结果比较接近，对于结果差异比较大的卡片，思考差异的原因，针对这部分内容再次与用户进行交流。

在信息架构层面确保使用流程的通畅

a、尽量保证根据树结构进行层级自上而下前进。

例如IM类型用，需要找某个好友聊天，通常的步骤是：好友－某个联系人－聊天页面，从这里也可以感觉到信息架构树的结构，必须是从上而下。

b、不连通层级间的跳跃，尽量发生在最后一步骤，避免用户在返回时产生困惑。

好友-联系人－聊天，聊天页面并不在好友这一层，到这里聊天已经是这个流程的结束了，所以跨层级也是没问题的。

LOFTER信息架构改版

完成信息架构的探索后，需要输出一份树状图，并且对功能重要性进行一个分级，重要的功能有更高的优先级，分级不等于排序。分等级的重要性在于面对大量信息时不至于出现信息遗漏的情况。

2.2流程设计

完成信息架构后，产品的主体框架已经搭建起，用户将与组成框架的不同功能和数据元素进行交互，形成完整的任务流程，通常使用关键路线情景剧本的方法进行设计。

与目标导向情景场景不同，关键路线场景以任务为导向，关注情景场景中描述和暗含的任务细节。通过关键路线场景，可以找到用户与产品的接触点。

梳理接触点时，每次用户状态发生变化时，要考虑当前这个状态下一步用户需要做什么，想了解什么内容，使得交互流程尽量自然顺畅

最好的模式是

做事——看信息——做事，一个页面接收一个或者一类信息，避免用户同一时间接受过多庞杂的信息，导致用户不知所措，操作过程产生错误。

也会有两种特殊模式

做事——做事

这类多数是用户平时的经验可以支撑，例如注册流程中填写手机号-接收验证码-填写验证码。

看信息——看信息

信息量较多时，需要依次理解，例如看活动大致流程－看到具体规则。

在查找接触点时，需要准确找到开始和结束接触点，不要遗漏，特别某些功能需要跳转到不同的app，需要把其他app的接触点都标示。

分支流程及异常流程

主线流程中的某个接触点可能出现替代或者分叉点，属于分支流程。例如发送邮件时不是直接发送，而是选择定时发送，就会进入一个新的分支流程。

异常流程包括错误操作、输入内容超出限定范围、用户网络故障/服务器资源不足等。

预测用户可能出现的错误

最可能出现是——错误点击，这个可以通过二次确认进行避免。

注意处理的力度

Toast——不需要用户点击，两秒后消息；适合提示文字较少，用户可以马上重试的场景。大部分的异常都可以通过toast形式提示

Alert——需要点击确认使弹窗消失；适合提示文字较多，且需要用户进行再次确认的场景。

了解错误返回码可以让错误考虑更全面

开发在编写服务器时需要编写错误返回码，为了保证系统运行正常，开发在这方面会考虑的比较细致，所以交互可以询问开发拿一套错误返回码，对照自己的交互流程中哪些部分可能出现错误，进行异常流程的编写。

设计时的优先级

正常流程设计>核心异常流程设计>可以简单解决的小异常

把流程梳理完成后，需要输出一份流程图，方便与团队成员进行交流，特别是开发和QA会参照流程图展开工作。

总结

在了解产品目标和业务需求基础上，通过用户访谈了解到用户的目标以及行为模式，将业务需求和用户需求统一起来，提炼出设计需求。并且为产品搭建出设计框架，包含信息架构和任务流程，把需求落实到产品当中。至此，绘制线框图的前期准备工作已经完成。

拿到需求就马上找竞品，沉迷模仿和界面细节无法提升交互能力，时间长了就变成一个“画线框图”的设计师。交互设计师需将更多精力放在需求理解和提炼，同时站在商业和用户角度考虑问题，得出有效的解决方案。

与各位共勉。kyocai