在经典的尼尔森十大启发式当中，「系统状态可见性」可以说是如今交互设计领域当中，最为重要的原则之一。通过向用户展现当前的状态，让用户拥有对系统的控制权，建立用户对于产品的信任感，这也是这种设计启发式的最重要的价值之一。
但是，想要做到可靠、易用，系统状态展现的技巧是很讲究的。这里梳理了4种最为常用的方法，结合了不少实用的案例，希望对你有所帮助。
1.1、让用户知道自己在哪
没有人会喜欢迷失方向，但是无论在现实生活还是在数字领域当中，这种情况都会发生。让用户知道他们在哪里是创建良好导航体验的关键。应用程序和网站都应该凸显当前的导航选项，帮助用户了解他们所在的位置。
Google 的底部导航栏设计
1.2、要经过多少步骤来完成任务
这也是一个非常基本的操作，通过展现步骤数量，帮助用户来预估完成这个过程所需要的时间。
Selecto 的调查问卷的设计
数字界面毕竟不是现实世界中的真实硬件机构，用户更多只能借助交互过程中的即时视觉反馈来确定是否完成了操作，即时的视觉反馈因此显得非常重要。
即时的视觉反馈让用户的操作得到了视觉上的「认可」，从而强化了「确信感」，这样一来一回的确认可以避免错误的发生，比如可以避免用户因为「感觉没有点下去」而反复点击。
这种视觉反馈的设计，最常见的范例就是点击按钮按下的微交互动画，它告知用户「系统已经捕捉到点击交互了」。
AliAli 所设计的悬停点击动画
但是在某些状况下，按钮的视觉反馈还有很多不同的呈现形式，有更多可见的、可理解的新形态，可以在原有的基础上探索更多可能性，比如下面的
2.1、单击点赞按钮
Spread love, not viruses ，作者 Charles Patterson
2.2、开关按钮
这个开关按钮不仅有点击动效，而且色彩和按钮标识也随之改变，更为清晰地表明状态，甚至兼顾到了视觉障碍用户
Switcher XLIV , 作者 Oleg Frolov
2.3、书签按钮微交互
这个书签按钮通过色彩的虚实变化来呈现书签已添加的状态，颇为巧妙。
Bookmark interaction，作者 Oleg Frolov
2.4、添加购物车微交互
在这种情况下，视觉反馈非常明确且优雅地告知用户已经添加到购物车里面了。
咖啡下单动效，作者 Nhat M. Tran
3.1、系统正忙于什么事情
当系统正在加载，正在执行，正在运行的过程中，通过动效来告知用户系统并没有停止，而是正忙于执行某件事情，是避免用户误解的手段。在用户等待的过程中，通常会实用无限加载的动效（一般使用在低于10s的操作中）：
对于超过10s的更长的执行过程，无限加载的动效会显得令人沮丧，这个时候实用进度条会更好：
这些视觉反馈很大程度上降低了系统给人的不确定感。
对于移动端应用，在初始加载阶段所使用的启动动画界面，是否精心设计，决定了用户对于整个产品的第一印象，优秀的初始加载动画能够将用户的注意力从焦躁的等待中解放出来。
Logo 闪屏 ，作者 Gleb Kuznetsov✈
3.2、内容加载
当用户需要时间来加载内容的时候，建议使用一种特殊的的容器「界面骨架」来展现。这种临时的内容容器不仅能够帮助用户快速地了解界面的整体框架，构建用户预期，并且能够在后台快速地加载数据，渐进式地帮用户获得信息。
内容加载，作者 Ginny Wood
这种设计方式对于移动端和桌面端的设计同样适用：
界面骨架加载动效，作者 Shane Doyle
4.1、通知和提醒
有效的通知和提醒，能帮用户意识到有新的事情正在发生。在多数时候，我们建议设计师使用微妙的动画来进行通知，因为动画效果会自然地吸引用户的注意力，人类的双眼的动态视觉其实是非常强的。
Aleksei Kipin 设计的通知动效
4.2、提示用户采取行动
在很多情况下，用户界面中会有很多地方会需要用户提交信息。比如，需要用户提交表单，或者用户创建了一个密码，但是在复杂度上不足需要修正，或者填写邮箱来订阅信息的时候，邮箱格式出错，等等。使用适当的视觉反馈总能够更加有效地将问题告知用户。
内联邮箱验证机制，作者 Derek Reynolds
让用户有掌控感，就是为用户创造更好的体验。在很多设计方案中，视觉反馈会因为种种原因被削弱了，甚至被忽略了。但是当用户在和 UI 进行交互的时候，期望度和可动性其实是高度依赖于这些动效和微交互，而这正是设计师需要设计出优秀视觉反馈效果的原因所在。
文章来源：优设 作者：Nick Babich
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
随着车内屏幕越来越多，越来越大，驾驶者在开车过程中因操作屏幕而分心机率逐渐升高。众多汽车制造商均希望探索出一种降低或避免「驾驶员分心」的安全性技术。
手势，是指人手、手和手臂结合产生的动作，作为解决「驾驶者分神」这个痛点的解决方案之一，正在全世界的汽车制造商中掀起「热浪」。
你只需要随意的挥一挥手，就能挂断电话；将手指向顺时针或者逆时针方向移动，就能调整音量大小。
汽车手势的出现，源于对车内屏幕的操作。而这些操作均来自于移动端的设计标准，比如苹果IOS设计规范中的标准手势或者谷歌Mertiral Design中的标准手势。
△ 移动端常见交互手势
常见的手势如上图，分别为
为了满足手机屏幕外观改变，屏内显示内容越来越多元化的需求，设计师们也在探索屏内手势的新玩法。
△ android底部导航栏按键从左至右分别为：返回上一级、返回主页、多任务
2017年iPhoneX的发布，正式开启了全面屏时代。为了替代Home键及android底部导航栏，各大手机厂商相继开始拥抱「全面屏手势交互」。
在车机系统中，部分汽车制造商也在积极迎接变化，比如理想one采用「三指下滑」的手势交互替代「返回主页」的图标按键。
△ 「 三指下滑」表示返回主页
2019年的Google I/O大会上，新版本Android Q选择与IOS采用一样的手势操作逻辑，即在屏幕下方提供一个指示条，用户在左侧页面边缘右滑代表「返回上一级」、提示条区域上滑代表「返回主页」、提示条区域上滑并悬停代表「多任务」。
△ android系统中的三种全面屏手势
随着全面屏手势在手机端的操作交互上达成一致，相信在不久的将来，也将越来越频繁的在车机端看到全面屏手势的「身影」。
当汽车与数字屏幕相遇，如何让屏幕与内饰结合的更加完美，又能突显品牌特性，似乎给内饰设计师带来了许多挑战与机遇，「一字屏」、「T字屏」、「7字屏」、「旋转屏」应运而生。
△ 拜腾M-Byte 一字屏
△ 理想one的T字屏
△ 合创007的7字屏
△ 比亚迪王朝系列的旋转屏
与此同时，因为成本及技术的限制，汽车制造商的量产车型不得不在屏幕上做出妥协。理想one的妥协方案是利用3块屏幕组合，在视觉上形成「大长屏」的既视感。
要让3块屏幕「变」成一块屏幕，仅仅在视觉上做足功夫显然还不够，多屏联动手势交互也不能「缺席」。
事实上，多屏联动手势交互依旧来源于IOS及android系统中的标准手势，它将不同的手势进行组合，并与页面联动显示，形成了多屏联动手势。
理想one在停车模式下，用户长按并向左滑动，即可将副驾娱乐屏上的信息「甩动」至中控屏。
天际ME7不仅有3块屏幕组合而成的前排「一字屏」，还有2块后排乘客娱乐屏，5屏联动的手势交互，天际采用「手势+屏幕显示」来解决。
在中控屏、副驾娱乐屏和后排娱乐屏上采用五指抓取手势进入多屏互动页面，比如想把中控屏上的内容分享给副驾娱乐屏，第一步是单击选中副驾娱乐屏，第二步按住并拖动中控屏至副驾娱乐屏位置，第三步在副驾娱乐屏中点击确认。
视频版交互演示：https://v.qq.com/x/page/w08791lhqus.html
通过隔空手势接听或者挂断电话，这似乎是科幻电影中才有的情节。但正如开篇所说，车内屏幕数量增多，尺寸加大的同时「驾驶者分心」的机率也增加了，盲操手势与隔空手势的出现，是解决这个痛点的一种尝试。
目前量产的汽车中，盲操手势主要是通过标准手势与声音反馈的组合来实现。
比如在理想one中，用户在空调屏上左右滑动可以调节风量，上下滑动调节温度，且系统通过声音反馈告知用户操作成功与否。
与盲操手势相比，隔空手势似乎科技感十足，备受汽车制造商的青睐，我们不仅可以在各种概念车上窥见它的踪影，在君马SEEK上，也可以实际操作一番。
君马SEEK提供8种隔空手势。
△ 左图：接听电话 右图：挂断电话
△ 左图：上一曲 右图：下一曲
△ 左图：音量升高 右图：音量降低
△ 左图：音乐播放/暂停 右图：玫瑰花
与君马SEEK相同，宝马提供「向左」手势代表上一曲、「向右」手势代表下一曲，「yeah」手势代表播放或暂停。
但在许多其他操作上，宝马与君马的手势操作则各有特色。
君马SEEK使用手掌的正面与反面来区分不同的操作，正面表示接听电话·/音量增加，反面表示拒听/音量降低。
宝马则选择向屏幕方向点击代表接听电话，手掌向右挥动代表拒听电话，手指顺时针画圈代表音量增加，手指逆时针画圈代表音量降低。
在倒车影像中，手指向右挥动代表调整视角。
△ 图片来源于「汽车界的扛把子」的短视频《宝马手势控制详细演示》
在手势交互上，拜腾也交出了自己的「成绩单」。
拜腾的手势识别共五种，手掌向下激活手势识别，手掌向上启动主页面，手指移动代表移动光标，ok手势代表确定，五指捏合可拖拽内容。
△ 图片来源于太平洋汽车网《拜腾Concept手势感应系统操作演示》
这些高大上的技术看起来令人兴奋，但在实际使用的过程中，依旧存在识别范围有限、识别精度不灵敏、识别后的响应速度慢等等问题，而各个厂家的手势识别没有形成统一的标准，且没有大规模在在用户中进行推广，必然会增加用户的学习成本。
手势识别对用户来说是「真香」还是「鸡肋」，相信时间会给出答案。
参考文献：
汽车内手势的交互设计，是一个有趣又好玩的课题，但如何让这个课题在好玩但同时易用、好用，恐怕只有设计师不断思考，并不断采用一些用户测试的方法进行验证才能获得答案。
文章来源：优设 作者：点滴DESIGN
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
这次我们不聊视觉，也不畅想未来，只说说当下 HMI 产品设计与交互体验。
本文内容会涉及一些专业的汽车知识名词，因为篇幅有限，如有些知识名词不太明白可以百度一下。
说到 HMI 大多数设计师应该是既熟悉又陌生，HMI 是 Human Machine Interface 的缩写，「人机接口」，也叫人机界面，人机界面（又称用户界面或使用者界面）是系统和用户之间进行交互和信息交换的媒介， 它实现信息的内部形式与人类可以接受形式之间的转换，凡参与人机信息交流的领域都存在着人机界面。
听起来是不是觉得这不就是 UI 吗？有什么区别吗？似乎差不多，几乎是没有区别的，只不过是在某些场合和设备上管他叫 UI，比如移动端设备，而在另外某些场所和设备上管他就叫 HMI，比如汽车车机和数控机床。所以这个概念也不用去特别较真，HMI 就权当作是汽车上的 UI 界面吧。毕竟汽车是高科技与工业结合的完美产物，「HMI」念出这个词时候就感觉是蛮专业的！很般配！
刚才说 HMI 最早更应用于工业上，比如常见的各种机床、制造装备。
或者说让时间再向前推进一点！
而这里通常意义的 HMI 则更加聚焦点，基本特指汽车车机或者车载多媒体设备。
说到这里还是要从车载仪表盘说起，从德国人卡尔·本茨发明世界第一辆汽车，距今已经 100 多年的时间了，在那些还没有 HMI 这个名词的年代，那么他是以什么形态出现的？那就不得不提「仪表盘」了。
当然写这篇文章并不是去评测谁家 HMI 更优秀，而是希望通过一些假设、实验和推断，和大家一起来探讨一下如何更有效地设计 HMI。
屏幕越大越好？车内到底需要几块屏幕？
我们先从屏幕开始。
说到屏幕，设计师都是比较敏感的，因为我们最终的设计交互创意都是需要都是在屏幕上显示展示出来的，HMI 当然也不例外。现在在车载屏幕上你能看到最大尺寸多大？
拿特斯拉为例，Model S 和 Model X 车型都是 17英寸，Model 3 为 15 英尺。
当然他肯定不是最大的，熟悉汽车朋友你应该知道我想说谁了，没错就是他！拥有 48 寸可多段升降屏幕的 BYTON 新能源概念车 M-Byte！48 寸的确很夸张，难道屏幕越来越大就是未来 HMI 的方向吗？
当然这个问题肯定是否定的，为什么？那就要从车载屏幕的作用来说起。
首先我是作为一个曾经就职于汽车公司的设计师，并且是一名地道的汽车发烧友，凭借对汽车还算熟悉和热爱做出一些产品交互分析，以下如有不妥之处还望海涵。
按照功能场景总体可分为三类：主行驶状态信息、附设备状态信息、多媒体 & 外设
不可缺少还需要与使用者、场景结合，我们先来做一个大概的用户画像。
对应这些需求，汽车需要有仪表台（屏）控制和显示的区域有五个。
五个区域分别是：
其中前三个是主流配置，后两个比较少见。
关于汽车设备这块我们不做深入展开了，毕竟这篇文章主要讨论的还是设计，直接看结果！
题外音：屏幕安全性的考量
汽车是比较特殊的设备，基于安全性考虑，汽车内屏幕尺寸不宜太大与太多。
屏幕总体为玻璃材质，但与车窗挡风玻璃的材质不同，当汽车遭遇碰撞的时候，车内屏幕极易破损并形成尖锐物，极大可能会乘坐人员造成二次伤害，所以车内屏幕不易太多，更不易太大。虽然车载屏幕变大变多已不可逆转，而且随着屏幕技术的提升，柔性 OLED 的应用也将会在一定范围解决安全问题。但也需要汽车相关设计者多在安全方面进行考虑，任何产品体验应该建立在安全基础之上的，特别是交通工具。
为什么大屏幕操控成为了当前的 HMI 主流了呢？那不得不去提一下另外一个我们熟悉的设备——手机！
同样一个有限的区域，如果用物理按键那么这个区域只能是固定的功能，而屏幕就可以无限扩展。特别是在汽车中控屏上集成内容会很多，体现就更加突出。
但是在汽车上的全部使用屏幕真的是最佳选择吗？显然这是有待商榷的。
不可否认屏幕的确有很强的扩展性，但是缺点也是明显的：1.触控反馈缺乏 2.交互效率不高
对于这样的判断，我们可以通过两个实验来进行验证。
将类似于 Surface Dial 这种智能按钮交互装置引入汽车的屏幕控制中，每个按钮可以根据情景进行自定义，并且吸附到汽车屏幕的任何位置进行交互操作，相信这一定是一种全新的使用体验。当然这一定是需要解决比如吸附力、安全性等一系列问题。
虽然目前的屏幕还无法做到完美触控反馈，但已经出现了一些新的硬件技术来试图解决这些问题，比如 Tanvas Touch，其定义为 「手指与触摸界面之间的电子压力控制」。简单来说他们的产品就 「皮肤的磁铁」 一样，能够更加精准地感应手指的动作，最后结果就是比 Apple 的 3D Touch 更加具有压感的触摸操作表现。
原理是利用手指尖触摸显示屏时产生的静电引力来模拟触感，通过电磁脉冲把更的反馈发送到用户的指尖。
Tanvas 也正在与汽车制造商们合作把这项技术嵌入到汽车或屏幕上，让人们更容易感触受到不同物体的表面。
也许在未来我们真的会遇到他。
文章来源：优设 作者：残酷de乐章
医疗行业的交互设计，跟其他行业有何不同？有什么要特别考虑的点？设计师应该注意哪些方面？
产品体验设计通道中有条简单好记的定义： 1+X。
「X」这个字母常被定义为更多可能性，它的诞生往往是为了更好地服务行业与产品。
例如在医疗健康行业中，不再只有C端用户，我们要面对医院管理人员、患者、医护人员还有企业用户等；环境也不单是线上场景，它可能是医院、企业大楼、社康、疾控中心等等；合作方式同样独特，我们做出的任何一个设计都是需要客户过目的，每一个字段甚至都涉及到生命健康与安全，所以会要求我更高标准地了解行业与用户，促使我们在项目前期去不断学习和应用一些用户研究知识，使设计更加贴近用户。
过往经历中，总结了用户研究在各阶段的介入场景和方法，接下来会具体讲下在医疗健康项目中的运用。
企业健康项目是从一个合作开始的，公司的行政部门想要通过我们提供的健康管理产品来提升员工整体的健康水平，并将该方案进行复制从而提供一个企业健康管理的行业解决方案。
的确，员工是一个企业的宝贵财富，健康有活力的员工群体对提升企业生命力有着非同一般的影响。通过网络文献调研，我发现国内企业的亚健康状况并不乐观。
△ 国内企业健康现状
第一阶段用研——产品定义与设计方向
为了更了解员工和企业的真实情况和痛点，我们规划了用研计划，列出了三个用研目标：
目标1: 员工们的主要健康问题都是什么？
通过和企业方的沟通，我们发现员工的体检报告是挖掘健康问题的源头，于是我们由此开始研究。
首先，我们拿到了历年的公司员工体检数据统计（脱敏分析），整理出体检问题的Top10。
△ 腾讯2018年体检数据统计
获许可，我们也随机向外发放问卷，了解到一些公司职工最想要改善的问题。
△ 某大厦的用研报告（仅作为分析用）
目标2：企业现在所提供的服务有哪些问题，该如何改善？
B端: 由于这是一个B to C的项目，我们优先会去采访企业端遇到的问题，沟通发现企业都会投资提供的健康设施（体检，食堂，健身房等），其中很多设施并没有被充分利用，或是没有得到合理的分配，现有的线上预约流程也存在很大的后台计算成本。
△ 腾讯提供的健康服务与设施（非疫情期间拍摄）
C端: 通过公司内部招募和访谈了20名员工，我们总结为三个主要痛点：
△ 员工在体检健康中遇到的痛点
以上，我们也对企业客户与员工用户的诉求有了初步的了解。
△ B&C两端诉求分析
目标3：如何定义产品目标与设计目标？
通过以上分析，和其他合作团队一同讨论了体检与健康管理行业的现状和盈利点，我们最终确定了产品方向：通过加入AI技术，分析用户过往体检数据来给用户推荐最合适的体检套餐，帮助用户解析体检报告转化为更加易懂的方式，加强与医疗服务的定制化连接；并智能定制最适合员工的管理方式和行为，充分利用起公司资源。
△ 产品形象与定义
通过对整体流程的用户情绪地图分析，我们得出设计的关键词：专业，贴心，安全
△ 阶段情绪地图分析
知识点1: 访谈与问卷调研
不要一上来就直奔主题，可以先问一些简单回答的问题和闲聊，让用户进入放松状态时再聊重点问题。且要时刻关注受访用户的状态，比如：是不是开始疲惫，回答过于发散以及表达意思模糊等等。遇到这些问题，需要随时做调整。
访谈的时候最好不要单独行动，要有1个主导访谈的，一个记录的。如果访问过程很长，有条件以及受访者允许的情况下，可以进行录音有助于后期的整理。
访谈结束后，最好是当场，或者至少应该是当天就完成本场次的访谈记录和总结工作。因为根据遗忘曲线，人在20分钟后将遗忘42%的内容，而1天后则将遗忘74%。即使有录音笔记录，你也会忘掉很多细节的，诸如表情，用户的潜台词等等。想到的设计解决方案也可以先记录下来但不急于放到总结当中去。
第二阶段用研——产品与设计验证
确立了目标和方向，我开始从体检预约和检后管理两部分来进行设计，由于在前期建立了用研机制，我们会定期对重要版本的内容和信息设计进行测试验证，并让用户基于我们定义的设计标准来打分，判断是否达到了专业，贴心与安全。
卡片分类-测试内容与排序
在检后的体检报告解读中，我们需要对解读结果进行结构化展示，方便用户快速获取有用信息，提高阅读效率，由此我们运用了卡片分类法，让用户对其重要性的排序，得知对用户来说体检异常中的单项的指标解释>危害性>指导措施。
△ 卡片测试与分析
可用性测试-测试架构与信息形态
体检解读的首页我们绘制了三个版本的方案，来突出不同的信息通过制作原型demo来进行可用性测试，让用户选出最喜欢的并说明原因，最终选择出一个最优方案。
△ 体检解读首页可用性测试与分析
从弹窗内容组合到内容的体检解读指标的可视化设计我们都做了用研测试版本
△ 体检解读内页信息测试稿
最终得到更加符合用户认知的体检解读设计。
△ 体检解读设计
灰度测试与深度访谈
由于某些需求时间紧迫，例如体检预约，当时很快就要到体检季，于是我们快速搭建框架和基础功能的设计，细节疑问点列出后进行灰度版本测试，并对前期招募的种子用户进行测试访谈，总结现存版本的问题，同时我们也访问了企业侧，把他们的优化诉求纳入考虑。
△ 体检预约访谈脚本与测试结论
比如企业要求突出安全感，福利感与智能推荐，减少后台结算成本等，我们便通过明确隐私授权认知的全页面弹窗以及简化体检预约流程，2步变1步，增强页面福利与智能推荐的感知渲染来满足客户要求，也得到了满意的赞赏。
△ 隐私授权设计
△ 体检预约设计
以上的用研方法其实可以运用在大多数的项目中，于是我在后续的腾讯健康模块设计中也常会去使用，例如疫苗设计中的闪屏方案测试等等。需要注意的是用研应该被列入到日常的流程中去，而不能作为临时安插，需要在项目实施前就进行用研计划的拟订，才能保证我们和用研同学有条理地客观的进行调研和验证。
知识点2:卡片与可用性测试
就医流程是看似并不陌生的场景，痛点也非常明显，就是常被提到的「三长一短」问题（挂号时间长，支付时间长，问诊时间短），于是在进行线上就医服务设计时，很多人会认为没什么好特别调研的，竞品也非常多。
然而其实在设计中，最害怕的就是「我以为」。记得在做某医院的就医服务项目时，由于就医环境和用户非常复杂，所以我们在做这个项目时坚持去到了前线进行了实地考察与影子观察法，才发现了新的洞察。
实地考察中的望闻问切
说来很巧，现场的调研方法其实和中医中的「望闻问切」有异曲同工之妙。
△ 医疗场景用研方法
「望」：可理解为影子观察法：选择最能反映问题的时间和场景去观察用户行为，发现痛点，经过几天的观察我们发现早上8-10点是医院看病的高峰期，也是排队最严重，院内最拥挤的时期，所以我会在这两个小时集中观察和记录患者以及医生的状态。
「闻」：即为倾听，其实也是访谈法中很重要的一个原则，多让用户去诉说，减少自己的主观判断干扰用户的完整陈述，如果记不下可以录音。
「问」：根据我们想要了解和观察到用户的行为进行提问。
「切」：这里和中医中的切诊接触不同。是指切身去体验患者的感受，比如我会根据自己身体的某些不舒服去挂号体验流程，情景带入。
以上的实地考察后，我在第一时间用我们设计师的手法来记录整理：体验地图分析，并通过讨论提炼出设计的关键点：引导，连接，合并与转化。
△ 用户体验地图与关键点分析
知识点3:影子观察法
用户体验地图的落地应用
这四个设计关键点其实来源于痛点描述中的一些高频提到的情况，拿引导和连接这两个点来说明。
引导：通过观察发现，用户在嘈杂的就医环境中本处于极度焦虑紧张的状态，对信息阅读和处理的速度低于平时的好几倍，因此我们需要提供具体的，正向的引导。
△ 精准预约设计
连接：通过访谈和自己实际的体验发现，许多线上和线下的服务之间是断层的，一方面需要流程上连接我付了款下一步要去哪，怎么拿药；另一方面我们也发现线下的引导设计是一个非常重要的连接机会点。
于是我们从线上和线下两方面进行了连接，提供了一套整体的解决方案。
△ 候诊与取药签到设计
△ 医院物料布局与落地布置
通过用户关系图了解了每个相关利益人的人群要素和诉求，在设计中不仅会考虑针对他们的设计，也结合体验地图中的机会点引出了设计原则，作为设计的指导和验证标准。
△ 相关利益人分析与设计原则
测试与收获
上线后，我们穿上志愿者的衣服，去往前线进行现场解说和用户测试，经过一个月的努力，真实感受到了现场效率的提升和满意度的提高，院方和使用过的用户都非常满意，这也让我们设计师切实感受到了欣慰和成就感。
△复旦大学附属肿瘤医院病理会诊 整体服务上线前后对比
这得益于我们能长时间与用户在一起，真实地听到了他们的声音与感受，也把想法落地去帮助他们解决了问题。这个过程中，让我们发现类似的垂直领域需要去到前线自己去感受，而不是隔着屏幕去观察，每个人的思考角度会不同，会发现新的问题和洞察。
知识点4:用户体验地图
在医疗数据分析的场景中，我们面对的客户是政府和医院领导。相信在做TO B设计的小伙伴经常会遇到这样的问题：客户时间比较难约，给的调研时间有限；决策层客户思考的比较广而泛，很难深入用研。
基于这样的问题，我们想出了一个根据客户群体层级，区别调研的方法。
梳理角色
去年年初，我们曾走访多家公立和私立医院，优先通过管理层梳理出了关于数据处理上报的流程。他们对数据的关注度和处理顺序往往是有一个自下而上的上报过程，基层人员进行每个月度和季度的数据汇总，分析与简单的可视化表现，上报给部门管理和上级管理者进行审核提炼，最终给到管理决策者一些关键现象和趋势和对比。
由此提醒了我们，想要提供一个完整的数据解决方案，就需要绘制角色面板，区别调研目的与手段。
△ 医院层针对数据的处理流程
分角色的沟通用研
我们确立了针对基层人员，中层管理者以及决策管理者的用研目标并展开了差异化的沟通用研，我们会每个角色找1-2人和我们3-4个同事坐在一起，以焦点小组的方法一同脑暴某一数据场景和所需数据。
△ 医院数据现场用研
数据研究与总结应用
根据对医院不同角色的沟通梳理出了一些总结点，运用到了产品和设计中。
第一：我们发现了管理者们最关注的一些医院数据的形态，并打算把基础数据尽量以对比，警示等手段进行分析与场景描述。便于管理者直观获取他想要获取的辅助决策信息。
第二：根据不同角色提供针对性的角色面板，并梳理出个角色关注的数据模块和现象。
第三：各角色具体数据字段的梳理与总结，并进行了频率的标注便于后续的设计面板规划。
第四：调研中发现领导层在看数据时需要来回切换系统，且看起来没有一个统一的路径和条理，因此我们也和对方沟通，通过故事化的手法进行数据分析的流程体验设计，层层深入和下钻，从现象挖掘到问题本质。更加符合了用户看数据的顺序和认知。
△ 长沙超脑项目设计版图
除此之外，我们后面的产品和设计的汇报也会根据角色的差异来进行内容的调整，让听我们说话的人可以快速理解我们想要达成共识的内容，加快沟通效率，提升了在客户心里的印象。
这个过程中，通过用研让用户感觉到我们懂他们，并让其增加了参与感，对产品和设计都是一个推进器。
知识点5：TO B/G客户用研
说了那么多设计师在用研技能上的应用，也许有人会有这样的疑问：如何可以不断提升自己在各方面学到的技能呢？一年前读到《刻意练习》这本书，给了我一些启发，在此总结给大家，希望对你们有帮助：
1. 制定具有定义明确的特定目标
「提升专业」是个很大的词，所以我们往往定了一个很大的目标，然后被各种事情拖着然后抛之脑后。因此拆分目标才是第一步。比如最开始做交互时我发现自己在归纳场景时总会缺失，再比如每次自己在汇报总结时，耗时过长，缺乏重点，那么这些都可以被列入要提升的小目标，总之目标不要太泛太难实现，这样实现起来会更加容易，也更容易坚持和自我激励。
2. 持续学习与专注练习
研读多本相关专业书籍，并应用的项目中去。这是我的一个目标也是方法。投入项目后，我们往往会陷入事件当中，甚至会就一个点和产品争论不休。但其实跳出来，去看些新思路不妨为一个好方法。
比如我最近在读《感官心理学》这本书，提到人们对于「软」和「硬」的触感印象会延伸到女性和男性的联想上，提到女性人们自然都会有柔软的印象，男性则会有刚硬事物的联想，这也就充分佐证了对于不同性别上的设计形态差异。类似的小实验可以帮助我们的设计更有说服力。
大多时候理论知识很枯燥，也难以一时间就可以用到，但只要你读过，在需要的时候它就会突然跑出来给你灵感。
专注是我一个单线程人的特点，我很难在一个时间里同时处理多件事，所以我会每天根据要完成的训练目标，把时间进行划分，个人感觉这的确产出效率也会高一些。
3. 一定要有反馈
每一次的练习必须要得到反馈，这也是评审的重要性。但其实不同的目标点可以对应方面的专家，不仅限于leader了，同事也是很好的老师，比如我会去发现身边汇报比较厉害的同事，帮我把关。只要遇到问题，一定不会放过去问用户研究同学的机会。
某方面没有老师怎么办？让用户告诉你！首先我会常用可用性测试的方式去检测自己的方案中的信息传达，交互反馈等等在进步，另外我也会在每个项目后整理一个小总结，来记录自己的思考与进步
另外，以下是我在用户研究学习中读过的几本书，推荐给大家～
面对飞速发展的现在，各行业的产品也都在积极转型，例如开始涉足TO B行业和客户，开始研究00后的新生代用户，面对新事物我们设计师更要保持敏锐的眼光，利用自身的设计洞察能力去挖掘新的问题与方法，于是新的技能和方式也开始出现，所以我们一直认为产品体验设计师没有一个固定的能力模型，还是要根据你所从事的行业和产品来发现所需的技能点去发挥价值。学习的过程中，我们成就项目的同时也在慢慢成就自己。
文章来源：优设 作者：腾讯 April
通过一个案例解释那些让你们看得有大的交互专业词汇
UI 和交互这两个词汇是一对孪生兄弟，有非常密切的联系，我们在前期了解 UI 的时候“交互”这个词总是形影不离，出现的频次极高。
但是，从我开始学习 UI 起，就被它困扰了非常长的时间，并不是苦于如何在实战中应用，而是在中文语境下，交互有关的词义实在是太“玄学”了，网上对它的解释多数也含糊不清。
比如看百度词条里，交互本身有两种解释，我们分别来看一下。
1.交互：指替换；互相；彼此。语出《京氏易传·震》：“震分阴阳，交互用事。”（阴阳……难道是我想的那个意思？）
2.交互：通过某个具有交互功能的互联网平台，让用户在上面不仅可以获得相关资讯、信息或服务，还能使用户与用户之间或用户与平台之间相互交流与互动，从而碰撞出更多的创意、思想和需求等。（交互使人类进步？）
单就这个词，如果词条看不懂，多在网上搜索相关的信息，咂摸个10天半个月的，是可以对它有个大致的认识。我会用一个比较简单词来概括它 —— 相交互动。即人和机器有了接触并产生操作、互动的整个合集。
好不容易把这个词搞懂，但是，交互事件、交互操作、交互方式、交互流程、交互原型、交互设计、交互文档、交互体验、交互动效……又是什么意思？
当我们在网上看一些交互相关的分享，你就会感受到这种混乱，比如下文截图的这种表述方式。
这是我非常不喜欢的风气，通过非常生硬的专业名词包裹自己的思路，去总结一个非常简单易懂的道理或原则，也就是俗称的 “不讲人话”。
所以，对于这个问题的反感，我打算自己做一篇 “接地气” 的分享，对交互的基本常识做一次扫盲。
针对这些解释，我找了一个我自己课程学员正在处理的真实案例作为依据，并进行改版优化，来解释所有和交互有关的名词具体含义，以及对应的实例是什么。
先看看下面这个案例。
Protopie线上可交互稿：https://cloud.protopie.io/p/a66d68949d
围绕这个案例开展，该页面是公司内部人员使用的订单管理页面，订单代表的是为客户上门测量门框门扇数据和进行设计定制的服务。
再详细点解释，就是销售找到定制门的客户，要创建一个销售订单，填写客户的基础资料信息，然后设计师会上门进行进行测量，并将测量结果和定做要求编辑进去，以及填写具体定制参数，还有服务的价格明细。
这个页面与公司内部的四个角色有关联，分别是销售客服、设计师、财务、派单员。
销售客服：联系到客户以后，确定客户的资料信息基本需求，然后创建订单填写基本的客户资料。
设计师：设计师在看见订单后需要上门进行测量沟通，并给出方案确定报价，然后将明细也记录到资料中。
财务：财务在做账的时候有时候需要进来订单查看具体的明细和数据。
派单员：派单员要根据订单内的具体数据要求，联系仓库进行准备和发货（进销存管理）。
说到这里，大家应该还已经对这个页面是做什么的有了基本的认识了把。那么我们先不讨论它的优缺点，就来讲讲上面的交互名词在这个页面中的对应实例。
人机交互：就是指上面销售、设计、财务、派单四个角色进入这个页面，编辑信息、查看信息的所有操作和行动的合集。
交互界面：该页面可以进行操作和编辑，就叫做交互界面。
交互操作：交互操作就是指我们操作这个页面的行为方式，该页面目前只有两种，点击（Tap）和上下滚动（Scroll）。
滑动Scroll
点击Tap
交互方式：这是软件允许用户操作的规则，比如想要选择设计师，就要通过点击 “设计师” 栏目，在弹出的选择器中，通过滚动列表来选取指定人选的方法，就叫交互方式。
交互事件：交互事件是指整个人机交互中的其中一个独立事件，比如上面案例讲的，点击设计师触发选择器弹出的事件，就是一个交互事件，在选择器列表中选择具体设计师，也是一个事件。
交互流程：交互流程是完成一个操作目标的操作流程，范围可大可小。比如上面选择设计师的全部操作流程，可以定义为一个交互流程。而完成整个页面信息录入的过程，也可以成为一个交互流程。
交互动效：比如选择设计师的交互流程中，点击设计师选择器的动画效果，就叫交互动效。交互动效是由交互操作触发而成的，方便用户理解界面的内容，而不是任何在UI中看到的动效都叫交互动效，比如下图这种。
交互体验：它和产品、用户体验还不太一样，专指用户在交互流程中得到的体验，维度并没有覆盖产品服务、情感化设计。
关于交互设计、交互原型、交互文档，我们在下一个部分讨论。这里的结尾我们就来讲讲交互体验，交互体验的评判维度有很多。但抛开所有技术分析，我自己将交互体验的结果简化成 3 个：难用、能用、好使。
交互体验的好坏不是产品、交互、设计师、程序员说了算的，是由用户来评判的。所以产品和设计行业都会强调 “共情” 能力，可以站在用户的角度来审视我们做出来的东西，而不是呆滞的上帝视角。
之所以挑这个案例，就是因为即便作为读者的你们，应该也可以想象如果你是这个页面的操作用户，那么体验一定会非常差，虽然它功能可能是完备的，但一定是 “难用” 的。
而对难用的分析上，绝对不是直接去套理论分析哪里难用，而是先找到难用的原因。
这个是多数新手会犯的错误，不站在业务、用户的角度去使用应用，找出原因，而就指望着去套理论套公示来对这个界面进行 “专业分析”。
所以这里我们简单讲讲，它的主要问题：
页面菜单选项太多，操作起来感觉压力非常大
菜单内容的分布感觉混乱，很难形成记忆点每次要设置的东西在什么位置
不同角色对这个页面的功能诉求不同，现在的设计显然没有满足
在得到上面三个问题以后，我们就可以对这个页面做出新的优化。 而要优化交互，我们就要首先从交互原型入手，即根据我们的想法设计出可以表现交互方式、交互流程的原型图，比如下图案例。
Protopie线上可交互原型：https://cloud.protopie.io/p/838165bdad
交互原型和产品原型不一样，产品原型是用来解释产品经理自己对产品功能的规划，不需要着重考虑交互体验，逻辑能跑顺并且能讲清楚即可。
而最终的设计稿，就是基于交互原型的基础上，遵照它的交互方式、事件、流程展开视觉内容的填充和细化。
我们再回到这个改版过后的案例，讲讲我们在交互原型中的流程给大家一点启发。
首先这个页面的所有菜单，并不是只有一个人完成填写，最起码要由派单员、设计师两个人，而财务、派单员进入到这个页面中，通常会有明确的目的要查看哪一部分数据，其它的数据信息对于他们而言都是干扰。
所以，我们将所有数据类型进行划分，统计结果如下（大致规划，了解意思即可）。
完成分类后，旧版中只使用上下滚动查找菜单的方式显然是不满足实际需要的，所以我就根据内容的划分创建一个分页栏的形式，将不同类目的菜单对应进行匹配。
当我们要查找某个具体元素的时候，首先选择对应的分类以后，再在分类下方查找。并且我们还引入一个新的 “交互方式”，可以通过左右滑动的 “交互操作” 来切换分类页面。
并且这个分页器栏目也可以进行标识，你的账户对这些内容的权限如何，比如 “不可看”、“只读”、“可编辑” 等等。
而每个分类下方，对它们再做一次逻辑分类，还有区分必填项和非必填项。如果有大量非必填项目为空，那么对于信息的查阅检索都是干扰，选填内容是用户需要填写的情况下才会去填，所以我们将每个分类下面的必填和选填也作出拆分，默认将选填菜单进行折叠（也可以是默认不折叠）。
这样，我们就可以得到一个你没有想到的 “船新” 版本。相信大家在这个版本的交互体验肯定比老版好出不少。
当然，这只是对交互流程的其中一个改版，并不代表我们的交互只能这么改而已，实际项目中，优秀的设计师都会提供几种不同的版本进行评审和测试，挑出其中最优的方案。
比如，我们可以不把分类页面做成左右滚动的，而是做成上下滑动的。
所以，在了解上面两套交互原型的案例，我们就可以再来介绍交互设计（UE）了。交互设计就是制定用户操作界面的流程、方式、体验的设计，和界面视觉设计并不能划上等号。
虽然过去行业里喜欢强调，将交互设计 (UE) 和界面视觉设计 (UI) 岗位拆分开来，但这不是一个太合理的现象，对于多数业务和团队来说增加 UE 岗位只是平添负担而已，未来的大趋势是由 UI 设计师负责交互设计的内容，当然也有个洋气的新名称叫 UX。
最后，在完成了上面这些内容的设计和规则制定以后，事情还没完。专业的 UE 和 UX 还会提供一份文档叫 “交互文档”，除了将交互原型图置入进去以外，还要具体来介绍它的交互方式、交互事件和交互流程的说明。
基于时间原因我就没办法提供一份基于这个案例制作的交互文档了，大家只要明白，如果我没在一个地方标注可以通过左右滑动来切换页面的方式，或者默认状态下选填内容是展开还是关闭之类的信息，那么最后落实到开发环节中可能就会导致很多细节问题的错误。
以上，就是我们关于对交互有关名词扫盲和解释的全部内容了。学习交互，要先从这些名词的认识开始入手，搞清楚底层的逻辑和原因，然后再通过实践和分析来积累对这部分内容的经验。
只有深入去了解业务，并站在用户角度审视，勤于思考的设计师，才能在交互领域中有所建树，理论知识只是其中嘴不重要的一环。
下面再把所有涉及的名词罗列一遍做个总结：
人机交互：用户和机器、软件实现操作和互动的过程。
交互界面：可以用来进行交互和操作的UI界面。
交互操作：用户操作软件、界面的具体操作，比如单击、双击、长按等。
交互方式：软件允许用户操作的规则，比如按钮的交互方式要通过点击才能触发。
交互事件：没完成一次交互操作并获得反馈的事件。
交互流程：用户为完成目标所做的一系列交互的合集。
交互原型：用来确定产品交互方式的原型图。
交互设计：制定用户操作界面的流程、方式、体验的设计。
交互文档：用图文记录交互思路、具体交互规则的文档。
交互动效：用来协助交互操作明确交互事件的动画效果。
交互体验：完成交互流程后所获得得感受。
完！
转自：站酷-酸梅干超人
在页面导航栏中，常会见到返回、取消与关闭三者按钮。许多同学会弄混它们的使用逻辑，所以写一篇小文帮助各位梳理下。
先抛开图标，我们回到功能本身的含义上看。如果我们不在产品的语境里，就单看「返回」和「关闭」这两个词，你首先会想到什么呢？
当我这么去问自己的时候，脑子里出现的并不只是零碎的词语，而是一些场景和画面。比如我走错路了，需要原路返回；公司复工了，我要返程回去。或者，睡觉时间到了，我该关闭电脑了；饭菜烧好了，我得把油烟机关掉，等等。
如果仔细去想的话就会意识到，语义衍生出来的，都是我们日常生活中的经验和对世界的认知。产品中使用的各种语言，不管是文字也好，或者图标图形也罢，一直都是以我们对它最本能的理解为基础的。所以只要你联想自己对「返回」和「关闭」的看法，就能知道它应该在什么样的产品情境中出现，以及它为什么会出现。
于是，很自然的，我们会把「返回」和「路径」联系在一起，所以「返回」在导航设计中不可或缺。并且「返」也预示着我们会回到之前的路径节点，整个过程是连续性的，不被切断的。而「关闭」就完全不一样了，它一般和我们的动作有关，是一个短暂性的操作，相比返回也显得更为独立。
根据我们对语义的判断，再结合实际产品中「返回」的场景，我们可以概括出「返回」和「关闭」的特征差异。
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界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。
蓝蓝设计的小编 http://www.lanlanwork.com