在页面导航栏中，常会见到返回、取消与关闭三者按钮。许多同学会弄混它们的使用逻辑，所以写一篇小文帮助各位梳理下。
先抛开图标，我们回到功能本身的含义上看。如果我们不在产品的语境里，就单看「返回」和「关闭」这两个词，你首先会想到什么呢？
当我这么去问自己的时候，脑子里出现的并不只是零碎的词语，而是一些场景和画面。比如我走错路了，需要原路返回；公司复工了，我要返程回去。或者，睡觉时间到了，我该关闭电脑了；饭菜烧好了，我得把油烟机关掉，等等。
如果仔细去想的话就会意识到，语义衍生出来的，都是我们日常生活中的经验和对世界的认知。产品中使用的各种语言，不管是文字也好，或者图标图形也罢，一直都是以我们对它最本能的理解为基础的。所以只要你联想自己对「返回」和「关闭」的看法，就能知道它应该在什么样的产品情境中出现，以及它为什么会出现。
于是，很自然的，我们会把「返回」和「路径」联系在一起，所以「返回」在导航设计中不可或缺。并且「返」也预示着我们会回到之前的路径节点，整个过程是连续性的，不被切断的。而「关闭」就完全不一样了，它一般和我们的动作有关，是一个短暂性的操作，相比返回也显得更为独立。
根据我们对语义的判断，再结合实际产品中「返回」的场景，我们可以概括出「返回」和「关闭」的特征差异。
1. 返回
连续性：按照产品的页面层级顺次跳转。但存在特殊情况，因为有些产品定义的功能出入口是不一致的，在信息架构层级已经做了一定的优化，所以返回不一定会按原来的路径回去，可能会按产品既定的路径。比如网易云音乐歌曲播放页进入直播后返回不是到播放页。
整体性：在产品功能页面关联性较强的功能中，「返回」需要连接各个页面与层级之间的架构关系，因此「返回」作为操作节点，可以帮助产品功能的各个页面之间建立联系，维持产品的整体性。
2. 关闭
非连续性：用于产品中的临时内容或临时动作，比如弹窗或活动页，与上一级页面没有直接关系。
独立性：非产品原生内容或是产品内的独立内容。比如小程序、浏览器标签等。
3. 返回和关闭的使用场景
知道了返回和关闭的特征后，我们可以从两者的使用角度上再去梳理一下。
现在产品中关于返回和关闭有三种状态：
1 和 2 的情况很好理解，我们只要根据前面各自的特征去看就能够理清场景。
3 的情况会有特殊性，因为它同时具有返回和关闭这两种看起来相矛盾的特性。其实这是由内容决定的，当内容同时具有独立性和整体性时，就需要支持两种操作。如小程序可以作为一个独立功能，但其本身又可以看作是一个完整的小产品，具有自己的页面结构和页面层级。所以小程序对于它所属的产品，我们有关闭的需要，小程序内的页面导航又需要返回来实现。
除此之外，产品可能开始只有返回，后面临时出现关闭按钮，比如微博「疫情地图」中使用「小区疫情查询」和「7×24 小时疫情快讯」后会出现关闭功能（帮助用户快速退出）。
这里我们可以从连续性和非连续性的角度看，产品针对具有复杂层级和内容的页面设计了顺次（返回）和跳页（关闭）的导航方式，其中关闭随实际情境出现。以此为用户提供了更为灵活的导航路径，来同时满足用户逐级深入、连续返回浏览和选择性查看、临时关闭的需求。
针对于「关闭」，它和「取消」会有重叠的含义，所以有时并不能很好地去区分这两个功能表达的应用场景。于是，我们可以借用之前的方式，先把「取消」单独拿出来理解。
一般来说，「取消」意味着行为过程中，还有后续行为，整个过程没有完成，当下后悔了，因此取消了当前操作。它更倾向于表达我们主动去做了什么改变，然后中途放弃了。
比如，想煮个饭，于是下了米，倒了水，定时，确认（取消），完成（关闭）。
这时候中间如果突然不想煮饭了，在定时之后，就停止当前行为，那就是取消。但点了确认并完成煮饭之后，这个行为就结束了，只能关闭。因此，它们之间就是行为上的差异。
就好比，打开微信公众号文章，内容已经加载出来，行为已经产生并结束，这时候左上角就一定是关闭。而发朋友圈的时候，左上角是取消，那是因为行为过程还在继续，没有发布，所以可以取消。而发布之后，就无法取消，想要关闭，也就只能删除这条朋友圈了。
所以在操作行为中的页面，左上角最好是使用「取消」。
当我们对词的含义有了进一步思考后，就可以去看它们在产品中的表现了。
比如广告的关闭、推荐内容的关闭。都是产品自身提供的内容，用户不想看到就选择关掉了，没有试图去改变什么。
包括内容页面，或者活动页面，被点开，且加载完成呈现出来之后，这个行为就结束了，没有取消的概念，只有关闭。
再比如，选择图片文件时的取消，微信发朋友圈、微博发帖时的取消等等，我们能发现都是用户主动采取了什么措施，但是又后悔了所以选择取消。
或者如游戏设置，就不适合用关闭，会让用户在理解上产在歧义，比如用户设置到一半，不想设置了，那现在关闭的话，设置是生效了么？所以用取消会更合适。
这些时候，不存在关闭的概念，因为没有内容可以关闭，只能是取消当前行为。如果使用关闭，与该场景下的用户行为不符，反而增加了用户对文案的理解成本。
简单来说，取消强调的是放弃改变，关闭强调的就只是抉择。
不过这里也有一个特殊例子，就是，微信公众号文章转发给好友，左上角是关闭，而钉钉里面内容转发给朋友，就是取消。为什么呢？
在一些特殊场景之下，「关闭」是包含「取消」的。
好比刚才煮饭的例子，现在的电饭煲很高级，如果在过程中不想继续了，拔掉电源就是完全关闭了，但同时这个行为也包含了人不想继续煮饭这个行为，想取消掉了，所以这时候关闭是包含取消的。它跟文章加载完成，已经呈现出来，是不一样的。
而上面这个微信与钉钉的例子，就存在这种包含关系。比如，内容已经加载完，要分享给好友，这时候加载出来的好友列表已经出现，只是选择发送给谁的问题，用户可以关闭已经加载完成的好友列表页面，或者理解为用户打算取消当前行为。
不过这样的设计并不建议大家将其定义为关闭，因为毕竟行为还在继续，使用取消反而更容易理解也更符合场景定义。
譬如，PC 的弹窗经常会同时出现叉（指代关闭）和取消，虽然操作的结果都是使弹窗消失，但是用户的操作目标是不一样的，事实上这里提供了两种选择，即我不想做决定，我要关掉弹窗，以及我决定现在不这么做，我要取消这个动作，这里的关闭其实就暗含了取消的动作。
在 PC 端，我们有足够的空间为用户提供不同的选择，给予用户充分的自主控制权，以满足他们对功能的不同期待。而在移动端，我们需要删减或合并功能，所以当用户同时产生重叠的诉求时，我们往往会选择当下最符合用户心境的功能，这是「场景细化」的结果。这也能解释为什么现在很多 PC 产品的弹窗中也只会保留取消，而不提供叉（指代关闭）的选择。因为用户面对功能不知所措、不做决定的情况已经越来越少，更多的用户已经明确地知道自己应该怎么做。
这就是「取消」和「关闭」的差异，以及移动产品对两者的取舍的根本原因。
同样的，有一些页面，取消和关闭都会用叉的图标来表示，只是在不同情境中，这个叉同样可以理解为取消，关闭，以及取消或关闭。差异点跟上述内容相同。
返回、取消和关闭看起来简单，深入分析后又显得复杂，但相对复杂的分析都只是为了能简单地去运用。在这个问题中，每个人都可以从自己日常的经验出发，然后在产品不同的语境里去体会一个词语、一个图标背后隐藏着我们什么样的认知和使用的习惯。
那由这个问题延伸的，其实还有产品的导航方式，页面出入口的设计差异，产品中整体与独立，连续与非连续的内容结构，原生与非原生页面的差异等等。
小问题同样可以见大，但我们也不需要过度思考，本来问题的解读角度就是因人而异的，也无法面面俱到，上面的只是我的理解方式。设计还是需要回归到用户和产品的目标，再去结合场景和产品业务的使用模式才能得出合理有价值的方案。
文章来源：优设 作者：呆呆U理
保持好奇，巧妙融合，追求卓越，自然而然
B 端工作看起来总是没有 C 端工作那么有趣，面临的限制比较多，面对客户（金主爸爸），很多时候总是左右为难。在实际工作中，面对这些情况该怎么办？笔者根据自己的 B 端工作经验，总结了一些交互设计的要点。
从事 B 端 SaaS 行业已经两年有余，从最开始面对需求的茫然无措，到现在已经有了自己的一些基本方法论，这期间经历了从有人带到自己摸索的一个阶段。
每天看看文章、看看书，大家讲的都是 C 端的产品，C 端的交互和体验；每天看同行们分析的不是如何提高用户活跃量，就是 APP 的设计风格。这在我一个 B 端交互看来，无比羡慕啊。
C 端项目的设计师感觉每天和一线用户打交道，忙得不亦乐乎，可以与用户直接对接，可以添加有趣生动的文案。
而对于一个做 SaaS 的 B 端来说，Boss 常说的话就是：
你这个颜色太鲜艳了。
我们是 B 端，你这种页面布局不合适吧。
这个文案太幼稚了，不适合我们产品的调性。
中规中矩就好，不要太跳。
整理了一堆的字段，画了无数的线框和流程图，却拿不出 C 端设计师才有的丰富多彩的作品集，
尽管如此，设计的原则是通用的，无论是尼尔森十大可用性原则，还是格式塔原理，在设计方案的落实上，都有着相同的方法论。
无意在此讨论 B 端和 C 端之间的差异，仅以此文章来总结下我自己的一些工作经验，如有错误，敬请指出。
从业务需求的对接，到界面交互的细节，从功能的设计要点，再到产品的发展导向，我总结出了以下几个方面，逐步展开：
C 端设计师最开心的可能就是收到用户的反馈需求了吧，这样表示自己的产品还有人在用，然后建个群让用户开开心心吐槽，完了就从里面提炼适合产品的一些需求和建议。
而对于 B 端设计师来说，如何处理需求是其成长的第一关，尤其是 SaaS 行业，不会处理需求，产品的功能更新将会遇到极大的问题。
B 端的用户不像 C 端，虽然可以用用户画像来进行归类和分析。但是由于 B 端的直接用户是付费用户，付了钱的就是大爷，因此大爷提的需求你敢不应？
用户提的需求乱七八糟，有些是体验问题，有些是功能问题，有些就是属于比较极端的需求。那种传说中甲方要你做一个可以根据手机屏显示颜色而改变手机壳颜色的需求，在 B 端行业也是存在的。
那么问题来了，我们该如何处理纷繁杂乱的需求呢，我从收集需求-评估需求-需求落地挨个讲起：
如果你也打算像 C 端产品体验群那样建立一个群，完了将自己的用户聚集在那里，静静等待需求的话，我劝你三思而后行。你可以这么做，但是应该明确群的目标，可以收集需求，可以是 bug 反馈群，也可以是更新通知群；但是不要将其变成一个纯粹的用户反馈群，因为这会导致用户的吐槽声音过大，而让潜在的用户流失。
B 端的客户一旦使用你们的系统，就要付出相应的金钱和时间代价，不是说想换一家就能换。因此他对于已经使用中的用户反馈是极其看重的，B 端的产品很大程度是靠着同行间的口碑传播从而取得了良好的效益。如果一个新用户想进群了解，结果一进去就发现大家都在吐槽这个系统的不足之处，那么可想而知他的选择是什么。
因此，最好的需求收集方式是通过运营、市场以及客服的同事们的反馈，因为他们是离客户最近的人，他们每天都跟客户打交道，了解这个行业从业者的一些基本情况。很多时候，客户回访和运营对接的时候用户会提出一些功能的建议。
通常的一种情况是，在 SaaS 行业，你的一个客户的流失意味着你的竞争对手多一个客户。因此一般市场都会有竞争对手的信息，他们会知晓客户从我们平台流失到其他平台的一些原因。最重要的是，他们也为你提供了绝佳的竞品资料，进而可以进一步明确需求。
收集好的需求，该怎么处理呢？
工具之前我用的是 trello，很好用，你可以将需求按照类型分为不同的看板，规划产品的进度。
之后由于团队的原因，改用 teambition，功能要丰富点，可以写测试案例等，对于国内用户比较友好；可以按照 KANO 模型将需求划分为不同的类型，用以安排产品。
KANO模型
基本（必备）型需求——Must-beQuality/ Basic Quality
一个产品应该具有的基本功能，能满足用户的基本需求，比如，微信的基本功能是即时通讯。
用户不会因为该功能的出现而觉得满意，因为这是基本的、必备的一项功能。如果连这个都没法满足，用户满意度会大幅下降。
期望（意愿）型需求——One-dimensional Quality/ Performance Quality
用户迫切希望产品能提供的功能，当提供该需求时，用户满意度会大幅上升，当不提供该需求时，用户满意度会下降。
比如百度网盘一直为人诟病的下载限速，无法对单次下载而付费。而需要开通会员，用户的抱怨恰好说明了其痛点；当提供单次下载付费的服务时，用户满意度明显提升。
兴奋（魅力）型需求—Attractive Quality/ Excitement Quality
用户对该类型的需求并无明显的期望，但是若产品能够提供该类需求，用户满意度会极大提升，也会培养用户的忠诚度。
比如，很多产品都有实验室功能，即对那些不是必备需求的功能设计一个开关，用户打开后可以进行使用。对于有的用户来讲，这些功能很大程度上会带来惊喜。当然，每个人期望不一样，实验室方案也可以视为另类的灰度测试，用以验证用户对于功能的需求。
无差异型需求——Indifferent Quality/Neutral Quality
产品无论是否满足该类需求，用户的满意度是不会变化的，正如用户不会因为收到「玛莎拉蒂5元代金券」而感到开心。因此在 B 端行业，开发时间有限的情况下，无需为该类需求投入资源。
比如优化一个用户访问量很少的网页，也无需因为领导或者客户的个人喜好而改变后台页面的颜色。无论使其鲜艳活泼还是稳重大气，后台满足基本的视觉要求和规范即可。当然，这并不意味着你可以把后台设计的简陋和杂乱。
反向（逆向）型需求——Reverse Quality
当提供方向性需求的功能时，会招致大部分用户满意度的大幅下降。比如常见的在搜索中掺加广告、强制用户授权过多个人信息以及推送大量无用的消息等，会导致用户的反感。
通常需求的收集不是你一个人在进行，产品经理、老板以及其他同事也会帮助你收集，汇总到你这里的需求会开会进行讨论，下一步要做什么。
做之前首先要对需求进行评估，评估的原则基本是按照 KANO 模型来，但是也会有比较特殊的情况。
交互设计师需要注意的是，你除了需要关注用户体验的问题以外，还要与开发一起评估该需求的实现；你不懂技术没关系，开发会告诉你该需求的落地会出现什么问题，在实现上会有什么难度。这些在评估需求的阶段都要提出来，并且在交互层面解决掉，否则你画出了原型以后，开发告诉你这个页面必须要修改，否则开发成本过大，无法在排期内完成，这个时候你再去改交互稿将会费时费力。
评估完需求，定好下期开发的需求后就结束了么？
其实并没有，因为需求收集不可能是一个固定的阶段，它是渐进的、不确定的。因此收集需求和评估需求会不断在实际工作中叠加和重复，比如你制定好了需求优先级，已经着手开发了；这时候老板或者领导突然又增加了一个优先级很高的需求，所以你得重新安排这些需求。如何在敏捷开发中保质保量的完成工作任务，这是一场斗智斗勇的 battle。
前面讲到需求评估的时候，需要与开发人员一起评估技术难度。其实在你将需求落地为交互原型的时候，也需要持续沟通，这完全是为了避免因为技术问题而产生修改设计稿或沟通不顺畅的问题。
如果你是在做的过程中，持续与开发人员保持沟通，能了解到他们是如何实现这个功能的。当然，有些基本的设计原则所不允许的事完全不用屈服于他们的「淫威」，毕竟他们得按照你的方案来。如果开发懒惰而想通过最简单的办法来实现，用户体验又是极其不友好，那么请直接对其说「NO」。
比如常见的删除的二次确认等弹窗，一般最好的体验是在按钮旁边弹出；但有些开发懒得写弹窗，直接调用浏览器的弹窗，即浏览器顶部经常出现的那种确认弹窗，这个时候你要坚决告诉开发，这样搞是坚决不行的。
需求的落地伴随着竞品分析，判断一个需求是否靠谱、落地方案是否成熟的一个重要途径就是竞品分析，可以通过调查研究相关竞品是如何进行设计的。这对于我们有着非常大的帮助，可以避免很多的弯路，甚至能避免犯错，提高交互方案的可靠性。竞品分析又是个比较繁杂的事项，如果是有特殊要求可以做成报告的形式，如果仅是去参考对照的话只需要去体验竞品即可。
B 端的业务比较重要，尤其是涉及到数据的增删改查和金额的计算，一旦出错，将会导致无法挽回的后果。因此在出错前和出错后，应该有相应的挽回机制。
1. 出错前
内容编辑类的功能应该提供自动保存草稿功能，防止没有及时保存而丢失内容；删除、禁止等较重操作应该有二次确认，防止用户误删。
对于操作流程应该建立明确的引导机制，长表单可以分开按步骤填写。
提示信息应该明确而及时。比如一个表单需要登录才能填写，在未登录的状态下，应该先提示其登录再填写否则用户在填写大量信息后，因为一个错误而前功尽弃。
系统内的禁止信息、警告信息、提示信息建立一套相应的规则。
2. 出错后
用户的时间就是金钱，这对于 B 端商家角色中尤为重要，大量订单的处理、表格化的导入和导出、批量管理和网站运营等方面，对于效率有着极高的要求，商家通过可视化界面来完成某项任务。
在这其中，影响最大的莫过于交互方式了，相信各位一定用过各大银行的网站，页面的导航关联性弱、结构不合理、提示不明确、交互流程过长，甚至有的网站光是登录，就得大费周章。
如何提率，我认为主要从以下几个方面着手：
1. 提高易用性
如果你的产品，让人看一眼就能上手，那么说明是非常友好的设计。易用性不一定意味着简单和低智，依据复杂守恒定理（泰勒斯定理），每个应用程序都有自己内在的、无法简化的复杂度。
所以，提高易用性意味着要设计合理的交互，易用性分为对新手（小白用户）友好和对老用户（专家用户）友好，包括数量最大的中间用户。
如果你的界面是仅仅对于新手友好，那么可能完成的任务都是简单而轻松的。但是对于老用户，他需要更复杂的功能来处理大量庞杂的任务；因此在设计的时候，既要提供傻瓜式的操作方式，也要对专家用户提供提率的工具。
2. 智能化
此处的智能化既包括通过大数据或者人工智能自动将操作步骤变得简洁，也包括诸如一些字段输入、自动定位、图片识别、OCR 等方式来使用户的效率得以提升的功能。
以前的用户要抠图可能会在 ps 中操作好几个步骤才能完成，但是随着机器学习技术的发展，ps 已经可以更加智能的抠图。当然，还包括其他功能的智能化。
在 B 端 SaaS 领域，智能化也是一个重要的趋势，针对不同的商家所面临的不同的行业领域，我们或许可以提供更加全面且友好的服务。
3. 场景化思维
如果你深入了解你的用户，去观察他们整个行业的运作模式，以及他们对于业务的处理方式，你就会明白你的产品的走向。
你需要深入每一个场景，比如，在户外旅游领域，发布旅游产品线路的可能是在办公室中的编辑人员，带队出行的是在户外场景中的导游，现场签到的可能是集合点的管理人员，而处理订单的又是另一个坐在办公室里的小伙伴。
他们需要协同工作，才能使各项工作顺利展开，发布活动-用户报名-订单管理-报名人统计-活动成行-集合点签到-带队出发-旅游结束-活动评价-领队评价-交易成功，这一系列流程中，面临的角色是复杂的，而意外也是常有的事。比如报名人无法参加活动而导致的退款、活动因为天气原因而无法成行、户外活动发生意外等。
你需要做的就是：
场景化的思维会让你设身处地为一线操作用户的体验而努力。因此，交互稿完成以后，彻底回退到小白用户的身份，假装自己是在某个场景下要做某件事，通过你的交互方案，能否顺利完成自己的目标。
此处的通用性是指，在 SaaS 软件领域，不同客户所面临的行业有一定的差别，可能这个功能对于 A 用户极其重要，但对于 B 用户，该功能并不重要。比如有的客户想要在前台展示某活动的报名人的姓名以增加真实性，用以吸引用户参加；但是有的客户就明确反对该功能，认为这个功能侵犯了用户的隐私。
诸如此类的需求相离、甚至相反的情况太普遍了。合适的解决方式是建立两套开关，一套是由 SaaS 服务提供商的统一后台来配置，用以区分比较大的行业差别，比如电商领域中，可以配置店铺类型为：美妆、服饰、食品、电子产品等；另一套开关在客户的站点后台，用以控制不同的站之间的差别，比如前台界面样式、交易流程、相关字段或菜单的前台显示等。
另外比较重要的一点，也是最基本的一点，软件设计中存在一个原则就是高内聚低耦合，模块化设计，用以提高系统内部组件的复用。
交互设计也是同样的道理，可以将你的商品视为一个模块，那么这个模块无论是添加到网站，还是小程序，我只需要创建一个商品即可，可以同步更新到不同的平台。
另外，订单的管理只需要添加相关的标记即可（比如来自小程序的订单标记为小程序，淘宝订单标记为淘宝等），一个平台发布，多个平台同步，有效提高了运营人员的效率。
同样的，如果你的 pc 端产品和移动端产品没有实质性的运营差异（即当成两种模式来运营），那么很多数据（如文案、图片、banner等）的获取可以采用同一个数据源 。
最后，提高系统内的一致性，减少用户认知成本。在同一平台内的页面，样式和交互上要尽量保持一致性，不要有的地方是总金额，有的地方是总价格，这会让用户犯迷糊。提高通用性，也意味着你需要关注并熟悉系统内不同功能之间的关联性，尽量做到统一处理。
在进行商业化运作和产品功能的优化时，对于正向的用户需要激励，对于负向的用户需要限制。
这是我在读完有赞的白鸦写的关于有赞产品设计原则的文章后，影响最深的一个原则，他写到：
我们的使命是帮助每一位重视产品和服务的商家成功。「每一位」和「商家成功」是我们最重要的关键词，我们要服务的是每一位商家，然后帮助每一位商家成功，但是为了整个生态的健康，那些不重视产品和服务的商家，我们是（可以）不服务的。所以我们在产品设计原则上，在产品做一些功能的选择上，如果这个功能做完了会导致商家不重视产品和服务，我们是不会/能做的。
举个例子：消费者购买之后（可以）有一个评价，我们的购物评价是要么开启要么不开启这个功能。我们不接受商家去删购物评价，因为商家一旦可以删了消费者的差评，他就（很可能）不会那么重视产品和服务了。所以有赞永远不会提供删除商品评价的功能，商家要么就不开启。可以不用，如果要用就要接受有人说你不好，商家可以去跟消费者沟通，沟通完了消费者自己改，但是我们不提供让商家删坏评价的功能。所以，这就是最基本的有赞产品设计原则，我们只服务重视产品和服务的商家，我们所有的产品设计原则都是需要这样。
——《白鸦内部培训：企业服务类产品的底层逻辑和有赞产品设计原则》
更多内容请看：
曾任支付宝首席产品设计师，现任有赞创始人的白鸦是很多人心里的产品大神，这份由他在内部分享的《产品设计原则》值得设计师、产品、运营等阅读学习。
阅读文章 >>我将其概括为一个产品的中正原则，即中立且保持正向原则。
一方面，对于企业未来的发展而言，正向的用户能带给平台无尽的潜力，平台可以和商家一起成长，而负向的用户，则会给平台带来隐患。比如，淘宝既限制商家的违规运营和欺诈客户，也限制 C 端用户的恶意薅羊毛，在商家和用户之间做一个中立者和调节者的角色。
我在做需求的时候，也遇到过很多的负向需求，这在商家看来是一个必须的功能，作为平台应该提供。但是若是提供给商家，则会对消费者的利益造成损害，删除差评就是一个很好的例子。
看了白鸦对于有赞产品原则的阐释，我觉得每一个平台类的产品，都应该保持自己的中正原则：
在 B 端行业，口碑传播是非常重要的一种被动营销方式，很多 B 端公司都是低调的潜行者，坚持中正原则，并不会损害自己的利益，反而会获得商家的尊重和消费者的信赖。
啰啰嗦嗦说了这么多，比较细碎，不乏逻辑凌乱的片段，但也算是对自己两年以来对于 B 端交互的一些心得吧。
其实交互的原则基本都是通用的，无非就是根据平台属性做一定的调整，不同的是产品所处的行业，每一个产品都无法脱离其所处的行业而存在，这也是使用产品的具体场景。
因此做一个产品前，一定要了解行业，去熟悉行业的通用做法，了解行业的专业术语和规范，研究行业的所属群体等，这样你就会做出真正适合市场且能让大多数用户满意的产品。
文章来源：优设
写这篇文章的初衷，是在实际工作中遇到 PRD & DRD 文档，对于一些交互设计图，会产生不理解，或者说在实际落地画图的时候会发现一些前后不一致的问题，解释过于冗余，不清晰。在接触新的业务时，很难把新理解的内容从上至下的消化完整。所以希望通过这篇文章帮助刚接触交互的同学更好地开展交互设计工作。
在传统瀑布式需求分析流程中，我们设计师往往拿到的是已成型的信息架构图&产品结构图&关键业务流程图，只是了解一下大概是什么类型的产品，很难发现企业产品中真正关键的流程价值点在哪里，或者说也不清楚后续发展的走向，只能卯足了劲去做图做说明，整理完整。时间紧迫压力大，又要照顾整个项目。往往决定产品成功与否的，是产品 20% 的主要功能（二八原则）。所以在面临初期产品设计中，应该将主要精力放在重要功能流程中。
目前，在互联网产品中，敏捷开发是所有产品设计者最推崇的。原因在于，能够对业务、设计、开发更有前瞻性&敏捷性。
产品交互的成功一定是建立在业务需求提炼清晰的基础上。业务需求的价值提炼，也是设计师需要参与完成的。业务需求是一个比较大的任务，来源可能是老板的要求，可能是产品提出的，也可能是用户的反馈。通过业务需求，我们要分析出相关的业务目标。有个偶然的机会，了解到彩色 UML 的设计方法，在具体实践中，感觉这个方法能够快速适应任何业务流程，简单方便，易懂，并能快速发现业务流程中的问题，加以修正完善。
有幸认识王海鹏老师，他推荐了早年他翻译的彩色 UML 建模一书，作者 Peter Coad，是将彩色和企业组件集成到建模技术之中的第一本书的主要作者，是世界上经验丰富的建模人员之一，他所创建的模型几乎涉及到所有行业。
此书是第一本介绍用彩色来表达软件设计的著作。作者用 4 种颜色来代表 4 种架构型，给定一种颜色，你就知道这个类可能具有哪些属性、链接、方法和交互。得到的彩色构建块能创建更好的模型，并获得应有的认可。彩色和架构型仅仅是开始。作者更进一步将这些架构型发展为 12 个类的领域无关组件。作者在过去 10 年中创建的每个模型，都遵循这个组件所表达的基本形状和职责。
笔者利用彩色 UML 建模的设计方法，用于业务梳理工作，达到了意想不到的效果。以下为彩色 UML 建模基本概念（截取彩色 UML 建模书中的介绍）。
△ 《彩色UML建模书》第9页
△ 《彩色UML建模书》第10页
△ 事例会员注册
定义：ER 图是用来描述现实世界中的实体关系模型，所谓实体是指客观上或者逻辑上存在并且可以区分的人事物。
作用：促使你以最适合技术理解实现的方法，来规范的描述功能模块的核心要素，其实就是数据库的物理结构。而这种描述是无二义的，最清晰传达 PM 的设计思想。
功能结构图就是按照功能的从属关系画成的图表，在该图表中的每一个框都称为一个功能模块。功能模块可以根据具体情况分得大一点或小一点，分解得最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。用通俗的话来说，功能结构图就是以功能模块为类别，介绍模块下各功能组成的图表。
作用
信息架构属于用户体验的结构层，是产品的骨架。一般是由产品经理或者更高层的管理人员给出大框架。除非是大的产品迭代，否则不会大改。
作用
信息结构图构成要素
定义：产品结构图是综合展示产品信息和功能逻辑的图表，简单说产品结构图就是产品原型的简化表达。
作用：它能够在前期的需求评审中或其他类似场景中作为产品原型的替代，因为产品结构图相较于产品原型，其实现成本低，能够快速对产品功能结构进行增、删、改操作，减少 PM 在这个过程中的实现成本。
业务流程图，不是操作流程图也不是页面流程图。它是产品的整体业务流程，直接和业务挂钩，可以说是产品的核心流程。
作用
通过业务流程图，钻研关键事件的流程，分析为什么要这么做，探索出更深层次的问题，从而对现有不合理的业务流程进行重组优化，进而制定优化方案，改进现有流程；阐述在项目中各个角色是如何产生相关联系的。
绘制规范/建议
任务流程图就是通过图形化的表达形式，阐述产品在功能层面的逻辑和信息。它能够更清晰、直观地展示用户在使用某个功能时，会产生的一系列操作和反馈的图标。
作用：基于业务流程，进行任务流程梳理，阐述角色和程序发生交互的流程，你如何进行操作，系统如何进行反馈。
任务流程与需求文档中的业务流程并不一样。虽然它们都是流程图，但业务流程更偏向于业务限制、后台逻辑等，并不过分注重用户的操作逻辑。而任务流程则需要关注用户如何操作、界面如何反馈等，从而引导用户完成用户目标。
定义：指电子产品具体所呈现的页面跳转流程图。其承载了业务流程图所包含的业务流转信息。
作用：
定义：页面的模块、元素、人机交互的形式，利用线框描述的方法，将产品脱离皮肤状态下更加具体跟生动的进行表达。
作用：用例阐释者，用来了解用例的用户界面；系统分析员，用来了解用户界面如何影响系统分析；设计员，用来了解用户界面如何施加影响及它对系统「内部」的要求；类测试人员，用来制定测试计划活动。
构成要素
限制
包含范围值、极限值等。
范围值主要指数据的取值范围。比如，当你的界面上出现了下拉菜单、筛选按钮、滑块等控件时，你必须标注清楚它们的选择范围，否则开发人员就不清楚该如何设定，如图所示。
极限值主要指数据的显示限制。比如，最多应该显示多少字数，过时如何显示，是否折行等，如图所示。
状态
包含默认状态、常见状态、特殊状态等。
「默认状态」主要指默认显示的文字、数据、选项等。这些内容需要注明，否则开发人员可能难以意识到这是用户填完的效果，还是默认就有的。
「常见状态」主要指针对某一个模块，经常遇到的一些状态。这些状态都需要在原型上表述出来。比如一个普通的积分模块，一般会出现 3 种状态：未登录状态、登录后未签到状态、登录后已签到状态，如图所示。
「特殊状态」一般指非正常情况下的样式、文案、说明等，如图所示：
操作
包含常见操作、特殊操作、误操作、手势操作等。
「常见操作」主要指正常操作时得到的反馈状态。比如一个普通的翻页控件，在经过不同操作后会立即出现如下的状态。
「特殊操作」主要指一些极端情况下的操作。一般，用户不会这么操作，但是一旦遇到极端情况，还是要想好应对措施，因为对于开发人员来说，不管是正常的还是极端的操作情况，他们都要去编写对应的代码。如下图，是填写用户信息的例子，当不写交互说明时，开放往往会遇到很多问题：如果已经勾选了 2 个人，再勾选第 3 个人，怎么办？如果勾选了「张XX」，下面区块中会相应地出现张XX的信息，那么这时候允许修改张XX的身份证信息吗？假如允许的话，修改后「张XX」还保持勾选状态吗？表单提交后要新增一个被保险人信息吗？若修改的是除身份证号码以外的信息，「张XX」 还保持勾选状态吗？提交表单时是覆盖原存储信息吗？若修改后出生日期、性别与身份证号码不吻合怎么办？等等。
面对各种复杂的情况，一方面要和开发人员积极探讨，看看有没有其他的解决方法可以简化各种逻辑判断；另一方面，在得出结论后，要把交互说明写清楚，避免出现让开发人员感到棘手的情况。
「误操作」主要指当用户操作错误时的情况。不过我们在设计时要尽量避免有用户犯错的机会。如图所示，提示中已告诉用户「库存5件」，如果这个时候用户在「数量」一栏中输入「6」会怎么样呢？系统会自动帮用户将其改为「5」省去用户手动修正的操作。
「手势操作」主要指用户使用移动产品时的操作方式。常见的有点击双击、长按、捏、伸、滑动等等。
反馈
用户操作后得到的反馈动作，包含提示、跳转、动画等。
「提示」主要指操作后，系统反馈给用户的文字说明等，如图所示。
「跳转」主要指点击某个链接后，页面跳转到哪里。设计师需要在原型上注明跳转时是「原页面刷新」还是「新页面打开」。如果是做手机应用的话，需要注明跳转时的转场方式，如图所示。
「动画」主要指用户操作后，系统通过动画的方式反馈给用户。动画给人的感觉比较友好、趣味性较强，是非常常见的一种反馈形式。比如删除某条信息，该信息以渐变消失的形式告诉用户：这条信息已经被删除了。在移动应用中，动画反馈的形式更为常见。因此设计师一定要在原型上表述清楚动画的形式，必要时可以制作 domo 动画演示效果给开发人员。
文章来源：站酷
在做交互文档之前，我们先要明白什么是交互文档、为什么要做以及做了给谁看。
交互文档，即交互设计说明文档。英文 Design Requirement Document ，简称DRD。主要是用来承载设计思路、设计方案、信息架构、原型线框、交互说明等内容。
有些人可能对文档这种东西比较反感，尤其是从事工作不久的朋友。其实工作得越久，越会发现文档的重要性，它可以帮助你理清思路，并记录下来，便于回顾。
交互文档其实要说给谁看，其实具体情况具体分析。有的公司老板也要盯交互文档，以及甲方爸爸、运营部门同事，都有查看的可能。
【产品经理】产品经理与交互设计师可能是沟通最多的人，产品经理主要在文档中确认设计思路和业务流程，然后过一下页面交互模块。
【视觉设计】UI设计师通常最关注的是页面交互模块，有着产品思维和体验思维的设计师也会仔细看一下设计思路和产品背景，以便于自己更了解产品业务逻辑和用户心理。
【开发人员】前端的开发同事和UI设计师一样，最关注页面交互模块，其他的作为提升会辅助了解。而后端开发人员关注更多的是业务逻辑、信息架构、操作流程等，这些都清晰了，他们才能输出一份准确合格的开发文档。
【测试人员】因为测试人员是把关产品上线的一群人，所以各个模块、步骤都应该去了解透彻，才能提出有效的bug。
本文主要阐述以Axure软件为撰写工具，大家可以根据实际需求决定用什么软件（Sketch、PPT、Word、PS、AI 等）。比如小需求可以用Sketch，快而。如果是要给甲方爸爸/大老板看的，使用PPT会让他们更好理解。
通常，一个比较基础、规范的交互文档（DRD）由：文档封面、更新日志、文档图例、设计背景/思路、业务流程、页面交互、全局通用说明、废纸篓八部分组成。当然，这不是绝对，你可以根据你的实际工作需要进行增减。
比如，如果是C端产品的话，用户调研的结论、用户画像、用户体验地图等等，都可以放进去给看的人一个参考。尤其是在如今这么关注用户体验、产品思维的一个大环境下，这些数据支撑很有力量。同时还可以帮助开发人员、界面设计人员培养产品思维、体验思维，大家一起将产品变得更好。
其次，交互文档的整洁与美观也很有必要。相信在过去几年不少人有遇到过这样的产品经理（兼交互），他们会输出一些有时连他们自己都看不太懂或者直接从其它竞品截图来的线框图。当开发和界面设计的人提出质疑的时候还美其名曰线框不重要，重要的是里面的业务逻辑。。。其实用产品思维想，交互文档就是交互设计师的产品，而看的人就是用户，保持良好的可读性，可谓至关重要。
交互文档的封面如上图，通常包括产品的名称、Logo、版本号以及版本发布时间、所属部门、对接负责人/对接人。
我们都知道，在产品的迭代的过程中，需求/功能是会不断调整的。而更新日志，就是为了迭代而生。它一般由修改日期、修改内容、修改人、版本号和备注组成。如果是新增的功能或模块，建议是要加上链接可直接跳转至新增内容的，如上图。
版本号也是同理，都应加上对应的版本链接，便于查看者回溯之前的内容，与当前的新版本形成对比。这一点对开发人员来说很重要，其次对于新同事深入理解产品也能起到很大的帮助。
修改日期，通常是按时间倒序排列，查看起来会比较方便。
文档图例，顾名思义就是关于此文档的一些辅助说明，目的是为了让读者更好地理解文档。如上图的：操作/跳转图例、标签图例、流程图例以及手势操作图例。
因为我今年对接最久的是一个B端产品的项目，所以整理了一个产品画像，仅供参考。
业务流程图，不是操作流程图也不是页面流程图。它是产品的整体业务流程，直接和业务挂钩，可以说是产品的核心流程。
例如淘宝APP，买家购物由始至终的流程就是它的业务流程。通常用泳道图的形式展示，多数情况下是由产品经理绘制。
以上是我所负责产品的核心业务的流程图。因为是B端产品，涉及角色较多，针对3个代表性角色分别进行了绘制，仅供参考。(涉及到保密协议，所有关键词都去掉了)
信息架构属于用户体验的结构层，是产品的骨架。一般是由产品经理或者更高层的管理人员给出大框架。除非是大的产品迭代，否则不会大改。
如果是C端产品，权限这一块相对简单，比较好整理的。B端产品涉及角色众多，可能要单独拎出来分析整理。以上仅供参考，大家具体情况具体分析。若是功能很单一的产品，交互文档中也可省去这个模块。
产品操作流程图就是通过图形化的表达形式，阐述产品在功能层面的逻辑和信息。它能够更清晰、直观地展示用户在使用某个功能时，会产生的一系列操作和反馈的图标。
上图是登录、注册和找回密码的操作流程图。仅供参考。模板源文件下载，后台回复“交互”即可。
页面线框图，是通过图形化的表达形式，阐述产品在页面层面的信息。包括：
【页面标题】即每一个页面的对应标题，一般就是导航栏标题
【页面内容】以黑白为主，保证信息规整易读
【交互说明】用标签将其对应起来，包括交互逻辑、操作流程及反馈、元素状态、字符限制、异常/特殊状态、相关规则 等等
【主流程线】只需要画出主流程线即可，千万不可太多太杂，时刻考虑读者的感受
以上是注册/登录的线框图和详细的交互说明。将重点内容用红色标记，可以让查看者一目了然更好理解文档。
常用控件类似UIKit，通常将极具复用价值的控制整理在一起，方便及时调用。
文档、软件只是工具，最重要的还是要落地、实行起来才能对产品有所帮助。所以在撰写文档的每时每刻，都应该站在“读者”的角度思考，他们看的时候感受会是怎样的，会觉得很难理解吗？
转自-站酷
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。
大部分交互设计师接到需求后，就开始分析下竞品、然后结合自己产品和自己的想法，就着手交互原型制作了，在这样一个设计流程中，交互设计师很难有体系化的思考。
有没有一套体系化的设计思路，让交互设计师做出的方案又专业、又全面、又经得起挑战和用户检验的设计方案呢？
本文是我梳理的一套体系化设计流程与思路，希望可以帮到大家。体系化设计思路大纲如下：
作为一个交互设计师。在我们接到需求之后，首先需要弄清楚的是产生需求的业务背景是什么。其次是基于业务背景了解产品的目标是什么。最后弄清楚产品的用户人群有哪些，用户目标是哪些。
交互设计师通过从产品经理或者其他需求发起方那里了解需求生产的业务背景，了解为什么要做这个需求。在了解清楚之后，追溯需求最原始本质。
在我们实际工作的大部分情况下，大部分产品经理不会在需求文档中将业务背景写清晰，这时候我们交互设计师就可以将业务背景在交互文档中输出，并清晰的展示出来。
1. 业务背景是什么？
业务背景通常是我们为什么要做这个功能。通过做这个功能，对业务有什么帮助。通过业务背景，我们可以推演出业务诉求，并得到对应的产品目标。
2. 产品目标是什么？
产品目标是产品能得到什么样的结果，对产品来说可以获得什么样的好处。所以在交互文档的设计中要重点体现出产品目标。通过明确产品目标，可以清晰的指导我们做交互方案。
3. 用户人群是哪些？
用户人群主要是通过我们对现有产品的用户画像得到，并推算出使用这个需求的用户人群是哪一类人，通过明确的用户人群，这样我们在做设计过程中，可以很清晰知道这个需求为谁而做。
4. 用户目标是什么？
用户希望通过使用这个功能达到什么样的好处或目的。
5. 设计目标是什么？
通过业务背景、用户人群、用户目标和产品目标拆解出对应的设计目标。
以登录注册为例。业务背景是目前产品的登录和注册的效果不理想。对应的用户人群分为两类，分别为新用户的注册流程和老用户的登录流程。用户目标是方便快速的完成登录注册流程，越简单越快越好。产品目标是提升登录注册的完成率。
设计目标是拆解，如何能提高登录注册的完成率。那么设计师可以拿到登录注册的完成流程，看看登录注册过程中，哪些步骤转化率低，那么对转化率低的地方进行设计优化。
目标拆解就是对页面进行数据提升具体优化方案，例如文案问题、视觉布局问题、交互路径问题等。
对于设计师来说设计方法有很多种。例如常见的有：目标导向、数据分析、用户调研、设计走查、场景化设计、用户体验地图、竞品分析等。
在做设计方案过程中，一般不会将上述的方法全部用到，更多的是使用其中的一种或者几种混合使用。
根据具体的需求选择适合的方法。例如在做登录注册这个优化流程方案过程中，可以通过数据分析找到转化率低和设计走查思考如何提升数据，就可以完成设计目标。
1. 不同场景梳理
我们需要以场景的思维做场景分析，通过场景分析就可以清晰地描述这些场景，从而确定用户的需求，并在这基础上用交互方案满足需求。
举个栗子，产品提出一个需求：应用添加「商品列表按照价格从低到高排序」的功能，这还是老思维，是在「定义我们的应用」；
而如果从场景的角度来思考，用户搜索某种商品，在列表页会列出一长串商品，而用户此时只想快速找到符合他的要求的那一个；而有些用户在挑选的时候，会需要买价格便宜的，此时排序功能就是用户的需求。
这样从场景来理解，会更清楚地理解需求发生的环境，便于做出好设计。
比如，顺着排序的场景，可以进一步想：有这样需求的用户在我们的应用里多吗？如果多，那么意味着用户经常需要进行排序的操作，所以在设计的时候，可以把排序的入口放的明显一点，好操作一点，方便用户轻松地进行排序。
对于使用滴滴快车的用户，整个流程包含三个阶段，分别为上车前，坐车中和下车后。每个阶段都存在多种用户使用场景。
2. 不同角色用户
有时候需要考虑不同角色的用户，例如后台系统，需要同时考虑普通用户、管理员角色和超级管理员。
三个不同角色的使用权限也是完全不同的。权限：普通用户 < 管理员角色 <超级管理员。三种角色的主操作流程也是不一样的，在设计过程中需要差异化设计。
3. 设计不同流程
明确设计目标、设计方法确定、弄清楚不同场景。接下来就是设计不同的流程。
一般先设计功能入口流程，接下来就是主流程和支线流程。最后才设计异常流程。
4. 方案细化和走查
在涉及到异常场景，且可以全局性复用的情况，则只需要全局性组件说明即可，不用每个流程都展示其异常场景组件或者页面。
全局组件指的是整个产品通用的组件，例如全局断网，操作成功、操作失败、加载、空数据界面，404 等
全局断网：一般是在首页使用 tips 提示。用户在其他界面点击操作时，也会出现 toast 反馈提示用户。也有一些 app 在用户进入后出现对话框提示用户网络异常。相对于对话框，使用 tips 对用户的干扰度更小。
操作成功：一般操作成功都是根据具体的使用场景出现对应的提示。
操作失败：异常情况导致操作失败，这时需要统一的提示，通常使用 toast，也有一些使用对话框强提示用户。
加载：涉及到全局加载和局部加载，全局加载在设计中要统一说明，例如上一个界面点击进入下一个界面，使用的全局加载就需要说明。如果是一些小场景的加载，那么需要特殊说明。例如上拉加载，下拉加载，局部小区域加载等。
空数据类型一共有三类：
通过核心指标判断设计方案是否符合预期，以此验证设计方案是否成功，并为后续产品的迭代优化做依据。
1. 关注设计的核心指标
设计过程中，要关注设计的核心指标，针对于核心指标，进行针对性的设计。
如果改版的最重要（核心）的指标是任务流程完成率，先查看用户操作流失率，然后分析找出流失原因，给出对应的优化方案。等到优化方案的产品版本上线后，对比完成率数据变化。
如果改版的最重要（核心）指标是人均观看次数，则要思考可通过哪些设计策略可提升产品的人均播放次数。
举个例子，新浪微博，以前版本用户看完视频后，视频会有重播按钮和推荐视频，用户只有进行下一步点击才能播放下一个视频。
改版后看完视频会自动切换到下一个视频。这样的设计策略虽然绑架了用户的行为，用户从一个主动接收者，变成了一个被动接收者，但是这种策略能有效的提升人均播放次数。
2. 核心指标带来的价值/收益
当验证了核心指标往好的方向发展，这时候，就需要总结核心指标带来的价值和收益，这样的话设计价值才可以直接被量化。
举个例子：一个 banner 的点击率达到 3% 的时候，每天 GMV 约 200 万，当重新设计了这个 banner，同时其他条件保持不变，点击率提升到了 6%，这时候通过数据查看每天的 GMV 是多少，如果达到了 400 万，那么这增加的 200 万的 GMV 则是通过设计优化所带来的。
设计师在交付稿件后，容易松懈，以为项目告一段落，就疏于后续的跟进工作。其实后续的跟进也很重要。产品测试版上线后，交互设计师应该跟进后续的走查和设计问题的反馈。
通过数据分析，确定上线的方案有哪些问题需要优化，建立需求池方便后续跟进优化，不断完善产品设计。
文章来源：优设
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
当别人问你什么是交互设计时，你又一脸懵逼了。本篇文章就来好好聊聊什么是交互设计
工作了很多年，却依然说不出何为交互设计。一说道理，大家都懂，但是当别人问你什么是交互设计时，你又一脸懵逼了。为什么会这样呢？因为我们没有自己去总结，没有形成自己的知识库。
交互设计，它由IDEO的一位创始人比尔•莫格里奇在1984年一次设计会议上提出，他一开始给它命名为“软面（Soft Face）”，由于这个名字容易让人想起和当时流行的玩具“椰菜娃娃（Cabbage Patch doll）”，他后来把它更名为“Interaction Design”――交互设计。
首先，我们来看看权威方对交互设计的定义：
交互设计协会(The Interaction Design Association (IxDA))解释如下：
交互设计师以创造有用且实用的产品及服务为宗旨。以用户为中心作为设计的基本原理，交互设计的实际操作必须建立在对实际用户的了解之上：包括他们的目标、任务、体验、需求等等。以用户为中心的角度出发，同时努力平衡用户需求、商业发展目标和科技发展水平之间的关系，交互设计师为复杂的设计挑战提供解决方法，同时定义和发展新的交互产品和服务。
百度定义如下：
交互设计（英文Interaction Design, 缩写IXD)，是定义、设计人造系统的行为的设计领域，它定义了两个或多个互动的个体之间交流的内容和结构，使之互相配合，共同达成某种目的。交互设计努力去创造和建立的是人与产品及服务之间有意义的关系，以“在充满社会复杂性的物质世界中嵌入信息技术”为中心。交互系统设计的目标可以从“可用性”和”用户体验“两个层面上进行分析，关注以人为本的用户需求。
唐纳德诺曼给出的定义：
重点关注人与技术的互动。目标是增强人们理解可以做什么，正在发生什么，以及已经发生了什么。交互设计借鉴了心理学、设计、艺术和情感等基本原则来保证用户得到积极的、愉悦的体验。
首先要知道什么是交互
交互，及沟通交流，发生互动关系。比如人和人之间的交互就比较好理解，最经典的一幕可以用孙悟空智斗金角大王、银角大王。金角大王说：孙行者，我叫你一声你敢答应吗？然后，金角大王就叫：孙行者。孙悟空回答：爷爷在此。就这样，孙悟空就被收进去了。这就是一个简单的交互。
再比如，我们每天上班，到公司和同事打招呼。你说：“早上好呀”，同事回答“早”。这也是一个常见的交流互动。
人和人之间的交互比较好理解，那人和机器呢？其实也是非常好理解的。我们都忘不了微信推出的摇一摇功能，打开摇一摇，摇动手机，就会出现“咔咔”的声音，然后加载，搜寻出一个和你同时在摇的人。其实，我们和任何机器之间的发生互动关系，都是属于交互。往更广的意义上说，如果失去了交互，地球将不再运转，将毫无生机。现在，智能时代已经到来，我们除了研究人和人、机器、产品、环境、服务、系统等之间的关系，还要研究机
器和人、机器、产品、环境、服务、系统之间的关系。
总之，当人（或机器）和事物（无论是人、机器、产品、服务、系统、环境等等）发生双向的信息交流和互动，就是一种交互行为。
其次，我们来聊聊设计
聊设计之前，我们要先说说艺术，原研哉老师对设计和艺术的描述非常精辟，下面就引用他的话。
艺术说到底是个人意愿对社会的一种表达，其起源带有非常个人化的性质，所以只有艺术家自己才知道其作品的来源。这种玄虚性使得艺术“很酷”。当然，解读艺术家生成的表达有多种方式。非艺术家通过对艺术的有趣阐释与艺术互动，欣赏之，评论之，在展览中对艺术进行再创作，或把艺术当做一种知识资源使用。
而设计，则基本上不是一种自我表达，它源于社会。设计的实质在于发现一个很多人都遇到的问题，然后试着去解决的过程。由于问题的根源在社会内部，除了能从设计师的视角看问题外，每个人都能理解解决问题的方案和过程。设计就是感染，因为其过程所创造的启发，是基于人类在普遍价值和精神上的共鸣。（来源，原研哉，设计中的设计）
通过上述的描述，我们不难发现，设计主要表现在发现问题–解决问题。而交互设计就是发现和解决人（或机器）和事物（包括人、机器、产品、服务、系统、环境等等）之间的互动关系问题。
所以说，交互设计的范围是非常广的，和各个学科都有涉及，我们可以通过下面的图来看看交互设计和各个领域之间的关系。
那交互设计主要是做什么工作呢？
作为交互设计师，也应该好好问问自己这个问题。通常，外界的人就认为我们就是画画原型，或者有时候画画UI，而我们通常就是这么做的，所以也不得不让人们这么想。而现在大多数交互设计就是指移动端、网页端的交互设计。
那么交互设计的核心竞争力是什么呢？对于很多公司来说，其实是没有交互设计这个岗位的，交互的工作就由产品经理和UI设计师各自分担了。现在产品经理基本都掌握了原型技能，而且产品经理通常在做需求移交的时候已经把交互表达的很清楚了。而且很多UI设计师能力较强一点的，在做设计的时候都会考虑到交互。如果交互设计师在公司就只做做原型，那么，你就会被取代。
那么交互设计的工作内容到底包含哪些呢？《用户体验要素》这本书很好的说明了这些内容。本书把用户体验要素分五个层级：战略层、范围层、结构层、框架层、表现层。不同层级，表示着你的不同能力，引用一下大众点评高级交互设计经理范怡的一张图，比较形象的描绘了交互设计的能力范畴和价值。
怎么样，看到这些是不是有一点点觉悟了呢。如果想做好一名交互设计师，就应该扩大自己的能力范围，提升自身价值。怎样做好交互设计呢？如何运用设计原理来做交互设计呢，我们下篇来聊聊唐纳德罗曼老师书里的交互设计6要素：示能、意符、约束、映射、反馈、概念模型。
原文地址：站酷
作者：Luyeelin
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
第一段：工具
设计师学习的第一阶段其实都是从工具开始的。这分为两种：
第一种是有形工具，比如PS、AI、Axure之类的软件；
另一种是无形工具，就是设计时用到的思维方式。
1、有形工具
先说第一种有形工具。
很多人在学习UI时很容易陷到工具的学习里去，觉得工具学的越多能力就越强。其实根本不是这么一回事，软件对交互来说是非常基础的一部分。
从UI视觉方面来考虑，PS就足够了，AI都显得略有多余，不需要其他软件。PS其实是一款非常强大的视觉软件，切图也比较方便，BAT等公司也是用的PS。
还有输出交互文档的工具，一种是PPT，一种是Axure，这两款软件就足够覆盖绝大多数交互文档了。当然还有其他软件，如果是快速迭代的原型直接在纸上画也可以。
交互需要快速沟通，你要拿着设计反复和其他人对接。要是搞了个很生僻的软件给别人，结果别人打不开，老板就会骂你。要记住自己是设计的一环，能快速传递自己的设计思路才是最重要的，不要搞一些生僻的软件、格式和字体，这都是门外汉干的事。
像AE、Flash面试时可能会给你加分，因为公司可能有一些高保真的动画展示要做，其实在真实工作中用到的机会非常少。
2、无形工具
第二种是无形的思考工具。设计思维其实最不好培养，说的残酷点，你可能看五年的书都出不来思维，最好能有人指点一下。
第二段：新产品、新思路
前沿的设计意识，是很多设计师容易忽略的。
这个怎么练呢？
每天一定要抽出三十分钟的时间看新产品和新思路，这是今天的互联网设计师必须要干的一件事。很多一线团队每天都会分享各种各样的新闻，百度有自己的分享机制，三星喜欢每个月让设计师找的交互、用研、技术信息，收集起来专门搞一个月报。
设计师有很多渠道可以看前沿信息，比如互联网一些事，爱范，36kr，瘾科技之类的网站。这种前沿意识非常重要，它决定了你能在二流公司还是一流公司，这是排在第二位的。
这个坚持三个月以后，自然而然就会飞跃，不需要怎么特意去学，这可不是培训可以得到的，养成一个好的习惯，每天看半小时其实就是最好的学习。
第三段：人——对人和需求的研究
工具和思维的问题比较好解决，最难解决的问题其实是“人”的问题。可能很多设计师一辈子都解决不了“人”的问题，而它对企业的影响又是最大的，交互设计最重要的就是解决“人”的问题。这一点甚至能决定一款千万级甚至上亿级产品的生死。要知道你的一切设计行为都是为商业负责的，所以前期对交互不甚了解，可以先从PS开始，后期就是“思维”和“人”，这两个东西是比较难的。
看看前辈是怎么说的：
交互设计目前发展得怎样，前景如何？
答：现在我们接触到的交互设计可能只局限在网页或者APP这种，交互设计是个很广泛的概念，前景肯定是有的。互联网是人和服务的对接，很多崭新的设计和商业模式一旦出来，那就是新的商机。
新手自学UI应该从何处入手？
答：视觉基础不好的就学PS去临摹，现在很多开源的信息，比如学UI网。如果临摹到一定程度，可以看一看dribbble，其实视觉非常好解决，思维的提升才困难。
学习交互设计需要掌握什么软件？
答：PPT和axure足够了，这两个东西都不需要学。随便来个人学两三天都能拿着软件画出漂亮的线框图，关键是你的线框图从哪里来、为什么要这么画。
交互设计师需要学习代码吗？
答：交互设计师不需要学代码。知道为什么企业招聘要求你们懂代码吗？因为很多企业希望你做了设计做前端，节省人力成本，正式公司都不会有这个要求。就算你觉得设计师应该学代码，建议你还是先把本行的设计能力学好。当两件事你都要做的时候意味着哪件事你都做不好，这是自我管理的问题。
交互需要手绘功底吗？
答：手绘功底？有或者没有都可以，交互不需要你造型能力多强，你只要能把逻辑关系画出来就行了，不需要搞什么素描阴影。你不是要做画家，朋友们，画家和设计师是有区别的。
（内容来源网络，如有侵权请联系，承诺必定删除）
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
“工欲善其事，必先利其器”；作为设计人员来说，设计方法和设计模型就是辅助我们更好做设计的工具。就像厨师做菜时候的菜谱一样；面对新的菜种，能更快指引我们做出味道不错的菜肴。
体系化的设计方法不仅能更好的指导设计师做设计；另一个方面，经过设计方法包装后的设计，能让设计师更坦然面对来自各方的质疑，更专业的讲述自己的设计依据。在做不同菜肴的时候，我们需要不同的菜谱来指引；而在不同的设计阶段，设计师也需要不同的设计模型/方法，让我们更灵活的做设计分析与输出。
下面从接到项目需求 > 体验迭代优化阶段，笔者将为大家详细讲解以下 5 种设计模型，并配出具体实践的案例，希望对大家有所启发。
1. 概念介绍
SWOT分析法（也称 TOWS 分析法、道斯矩阵）即态势分析法，20世纪80年代初由美国旧金山大学的管理学教授韦里克提出，经常被用于企业战略制定、竞争对手分析等场合。
在现在的战略规划报告里，SWOT分析应该算是一个众所周知的工具。来自于麦肯锡咨询公司的SWOT分析，包括分析企业的优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。
2. 使用场景
主要用在产品前期的战略规划中；用于项目成员知己知彼，同时也能知道在行业领域自己的产品所处的位置和核心竞争力是什么；对于产品方向的定位和全方位分析有复用价值。
3. 计价值
SWOT分析实际上是将对企业内外部条件各方面内容进行综合和概括，进而分析组织的优劣势、面临的机会和威胁的一种方法。
优劣势分析主要是着眼于企业自身的实力及其与竞争对手的比较，而机会和威胁分析将注意力放在外部环境的变化及对企业的可能影响上 。在分析时，应把所有的内部因素（即优劣势）集中在一起，然后用外部的力量来对这些因素进行评估。
4. 具体实践案例说明
下图是笔者曾为的阿里内部某个数据服务平台分析的案例；侧重介绍了为什么要做这个数据平台；以及做这个平台我们项目组的优劣势和机会点分别是什么。在给老板汇报产品来源&方向时是非常有效的。
最后，SWOT 分析模型其实还可以与商业画布相结合，便于更全面对项目/业务进行快速分析和深入了解；深入懂业务的设计师才能真正在团队中进行发声，提出超越 UI 层的建设性意见。
1. 概念介绍
Design Sprint, 设计冲刺，顾名思义就是要在短时间内做出好设计；是由 Google 提出的设计方法。
2. 使用场景
设计冲刺这个设计方法主要适用于短时间就需要产出设计方案；例如一些 Workshop 的共建, 产品迭代周期很快的新需求/任务，需要系统化分析与输出设计方案。
3. 设计价值
可以在很短的时间内输出一套系统化的设计策略及方案；
通过与不同背景的参与者进行沟通协作，能获取更多看事物的角度和差异化知识；创造更多可能；
作为一种理想的设计教育工具，让非科班的设计人员完整又快速了解产品&设计。
4. 具体实践案例说明
设计冲刺的主要内容包括 6 个阶段：
理解（Understand）：理解要为用户解决的问题
定义（Define）：明确产品策略（数据分析，用户调研，设计原则制定等）
发散（Diverge）：探索实现方案
决定（Decide）：确定设计方案
原型（Prototype）：构建产品原型
验证（Validate）：验证产品原型
1.概念介绍
相比前一个设计冲刺模型，GUCDR 模型在设计过程中的实用性更强，能让你快速用起来，帮你系统性梳理信息；在实际工作中，只要能够回答画布中的每个点，即可形成完整的设计推演过程，让设计思路逐渐清晰起来。
G：Goal
U：User
C：Condition
D：Design
R：Realize
2. 使用场景
GUCDR 模型很适合用于前期需求调研和整理阶段；特别是在自己不是很熟悉的领域中，把信息按照模型和画布中的点进行归类汇总；最大限度的让自己的设计思维和信息逻辑得到诠释。
3. 设计价值
3.1 对设计的需求来源及设计目标的聚焦定位，非常有价值，能快入深入了解业务背景；
3.2 对设计阶段的目标拆解，从设计目标 > 设计策略 > 设计方案，层层递进，设计方案输出的逻辑性和针对性很强。
4. 具体实践案例说明
GUCDR 模型在具体的使用过程中，可以和 GUCDR 画布结合起来一起使用。信息下钻的更深入具体，从项目目标到设计落地，每个阶段都有具体的节点支撑，在使用过程中只需要把信息直接输入到对应的位置即可。下图为 GUCDR 画布模板，可直接把业务相关信息输入进来。
1. 概念介绍
双钻设计模型由英国设计协会提出，该设计模型的核心是：发现正确的问题、发现正确的解决方案。
双钻模型是一个结构化的设计方法，被很多设计师喜爱和使用。
探索/调研——透析问题（发散）
定义/合成——聚焦领域（集中）
发展/构思——潜在问题（发散）
传达/实现——实施方案（集中）
2. 使用场景
一般应用在产品开发过程中的需求定义和交互设计阶段；教我们如何对未知的可能的事物进行探索；一步步到达已知的理应的层面。
3. 操作使用说明
双钻模型的四个阶段也许很精简并且合并到两个主要的阶段。
第一阶段——做对的事（菱形1——探索和定义）
第二阶段——把事情做对（菱形2——开发和履行）
4. 具体实践案例说明
下图是对阿里内部一款移动运维产品的分析，分析其从 0-1 的方向探索和从 1-1.5 的发展历程：
下图是曾经在一个设计讲座中，滴滴 CDX 一位设计师的分享，她把双钻模型利用到设计的研究和输出阶段，个人感觉此模型此刻的使用场景也很贴切；不仅仅是在完整的一个项目中，在单一的某个阶段双钻模型也是理念很好的承载容器。
1.概念介绍
kano模型是狩野纪昭教授发明的一种工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。
在卡诺模型中，将产品和服务的质量特性分为五种类型：
1> 魅力属性：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；
2> 期望属性：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
3> 必备属性：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低；
4> 无差异因素：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意；
5> 反向属性：用户根本都没有此需求，提供后用户满意度反而会下降。
2. 使用场景
卡诺模型的主要使用场景是对用户需求分类；
另一种是对多个功能点进行优先级排序。
3. 具体使用操作
步骤一：设计问卷调查表，实施有效的问卷调查
KANO 模型的问卷问法，是对每个质量特性都由正向和负向两个问题构成，分别测量用户在面对存在或不存在某项质量特性时的反应。问卷中的问题答案采用五级选项分别是：
我很喜欢：让你感到满意、开心、惊喜。
理应如此：你觉得是应该且必备的功能。
无所谓：你不会特别在意，但还可以接受。
勉强接受：你不喜欢，但可以接受。
我很不喜欢：让你感到不满意。
步骤二：问卷结果整理，进行数据分析
根据问卷结果进行 KANO 模型二维属性归属分析，可得出魅力属性、期望属性、必备属性、无差异属性、反向属性与可疑结果的功能属性归类百分比。除了对属性的归属探讨外，并通过百分比计算出 Better-Worse 系数，表示某功能可以增加满意或者消除很不喜欢的影响程度。
增加后的满意系数 Better/SI=(A+O)/(A+O+M+I)
消除后的不满意系数 Worse/DSI=-1*(O+M)/(A+O+M+I)
根据 better-worse 系数值，将散点图划分为四个象限。
第一象限/期望属性：better 与 worse系数成正比；表示产品提供此功能，用户满意度会提升，不提供此功能，用户满意度会降低，这是质量的竞争性属性，应尽力去满足用户的期望型需求。
第二象限/魅力属性：better系数值高，worse 系数绝对值低的情况。表示不提供此功能，用户满意度不会降低，提供此功能，用户满意度和忠诚度会有很大提升；
第三象限/无差异属性：better系数值低，worse系数绝对值也低的情况。即无论提供或不提供这些功能，用户满意度都不会有改变，这些功能点是用户并不在意的功能。
第四象限/必备属性：better系数值低，worse系数绝对值高的情况。当产品提供此功能，用户满意度不会提升，当不提供此功能，用户满意度会大幅降低；此象限的功能是最基本的功能，这些需求是用户认为产品有义务做到的事情。
步骤三：数据解读，将结果落地实施
KANO 模型是对功能需求的优先级进行探索，具体情况还需要和业务方进行讨论，结合实际情况后制定可行的产品功能开发优先级顺序，以将调研结果落地实施。
4. 具体案例实践说明
题目：根据报警内容，“掌上运维”提供运维操作建议（如磁盘满了智能推荐执行日志清理等）
步骤一：设计问卷问题，发放问卷
步骤二：问卷统计，进行 KANO 模型二维属性归属分析
步骤三：根据问卷统计的用户数据；计算出每个区域的百分比；
具体计算方式是全部区域的人数相加作为分母；每个格子中的数字作为分子，即可得出每个格子的百分比出来。
具体百分比得出后，将下表中标 A、O、M、I、R、Q 的格子中百分比相加，即可得到五种属性对应的百分比。本调查结果可以得到A魅力属性占比为42.1%，O期望属性占比9%，M必备属性占比1.2%，I无差异属性占比38.9%，R反向属性占比1.8%，Q可疑结果占比7%。
步骤四：根据 Better-Worse 计算公式，得出 Better-Worse 系数，明确功能落点象限。
步骤五：多个功能需求结果对比进行优先级排序。
1. 概念介绍
为了帮助大家更好地进行“幸福设计”，卡里罗教授分享了他的一个模型——Motivation, Engagement and Thriving in theUser Experience (METUX)。
2. 使用场景
产品成熟稳定期，需对产品&用户体验进行提升时；或需综合对产品体验进行评估分析时；提升用户幸福感，希望产品能对用户行为方式及生活质量有所影响时。
3. 主要使用操作
在考虑用户体验时，从4个层次进行考虑：
▪︎ 第一层是“界面”体验：用户与产品交互时的体验如何。
▪︎ 第二层是“任务”体验：界面之上是用户完成的任务。如利用智能手环计步，用户在完成任务时体验如何。
▪︎ 第三层是“行为”体验：任务之上是用户的行为。如用户购买智能手环的目的是运动，此时行为可能是跑步、骑自行车。因此产品在任务之上应该深入关注用户行为上的体验。
▪︎ 第四层是“生活”体验：行为会对生活产生影响。如运动过量可能导致身体受损。
在设计过程中，应该关注“胜任力”、“自主性”和“关系”三个关键因素，这些基本心理诉求是动机、投入感和幸福感的根本。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计
蓝蓝设计的小编 http://www.lanlanwork.com
