前几天版本号为 「OS Build 21996.1」的 Windows 11 系统在网上泄漏，虽然微软官方辟谣说这并非正式版本，但是这个非正式的泄漏版本依然可以让我们窥见新的 Windows 系统的一些有趣的特质。
在整体观感上，和补丁摞补丁的 Windows 10 相比， Windows 11 拥有着更加明确统一的视觉设计，足够简约又不会显得简陋，充满了一种浓郁的「形式跟随功能」的设计特质。微妙又高级的「亚克力美学」 Fluent Design 则显而易见地贯穿整个系统，所以 Windows 11 应该就是 Fluent design 的第一次集中式、成体系的呈现和总结。
在系统功能上，一眼就可以看到新增的桌面小组件功能模块，经过这么多年这么多系统的迭代 和验证，相信微软这次的桌面小组件不会是那么鸡肋的存在，应该可以整出一个颇为不错的桌面信息中心：
新的软件商店也根据当前风格进行了优化：
在游戏领域玩儿得风生水起的 Xbox 是肯定会出现在新的 Windows 11 当中，完善的游戏服务应该成为 Windows 11 的加分项，不过具体如何应该需要新版本正式发布之后再去验证：
在动效和交互上，Windows 11 彻底摆脱了 Windows 10 时代似是而非的状态，经历过 Surface 系列产品的反复迭代和测试，Windows 11 在触摸交互上终于有点样子了，不再拉胯。得益于之前在 Surface Neo 和 Duo 上的探索，在分屏交互上，也提供了非常成熟的原生交互体验：
不过，这次更新对于绝大多数用户感觉最为不同的，应该是挪到底部最中间的开始菜单。这个历经近30年的功能组件，变成今天这个样子本身是一件非常有意思的事情。接下来我们回顾一下这一部分的变化。
其实「开始菜单」这个东西谈不上是微软的独创，在 Windows 之前，这种系统级别的菜单设计由来已久，Macintosh 在左上角：
BeOS 在右上角：
不过和当年大量交互逻辑千奇百怪的桌面系统相比，MacOS 和 BeOS 这种终究是少数，而面向兼容机市场的 Windows 95 把这种易于上手、高度集成的功能发扬光大，不得不说既是时势，也是机遇。
Windows 95 上的「开始菜单」设计可以说是当时同类设计中的最佳实践，易于理解的树状结构和明确的位置结构，让整个操作系统具备了更强的可用性。
Windows 系列在 开始菜单上的成功影响了后续包括 Gnome 、 KDE 在内的诸多 Linux 桌面环境，它们大都是顺应着这种潮流来进行桌面端控件的设计。
随着市场份额的增长，「开始菜单」也成了 Windows 系列最具认知度的组件之一。这种事情最直接反馈在键盘的设计上，在圈内有 WK 和 WKL 两种常见的配列，前者即是 Win key Layout（有Win键键盘布局），WKL 则是 Win Key Less Layout（无Win键键盘布局）：
在 2000 年之前有大量的键盘这样的键盘，而如今我们在零售市场上已经很少能见到这类产品了。为「开始菜单」单独安置一个按键虽然也不是 Windows 的独创，但是从这类键盘的市场份额的变化，也能看出 Windows 的市场变化。
在「开始菜单」上尝到甜头之后，微软几乎在每一代 WIndows 操作系统都会将这个默认位于界面左下角的组件进行升级，并且按照自己的想法进行了「优化」（当然后来的某些设计也确实是毁誉参半）。
Windows 98
Windows Me/2000
Windows 98/2000/Me 基本上还是在延续 Windows 95 上的简单的层级结构，但是由于受限于硬件性能和操作系统领域的流行风格，这一波系统的开始菜单在视觉上也保留了当时桌面系统的浮雕式控件的视觉风格。
Windows XP
值得一提的是，促使微软痛定思痛认真搞 Windows XP 的视觉风格的重要原因之一，其实是苹果这边的 Mac OS X 在视觉设计上搞得风生水起。要说微软一新追求技术无心设计肯定是假的，因为在去年泄漏的部分 XP 源代码当中，有微软模拟的 Mac OS X 风格的主题：
两相印证，也不难看出微软在 Windows XP 的原有视觉风格上的探索还是相当上心的。而这个阶段的「开始菜单」从单栏变成双栏，一方面承载了更多的固定快捷方式、快捷文件夹，而且开关机按钮和控制面板 等一系列常用的关键功能也相对简约地集成，而全部程序则隐藏在下级菜单当中：
Windows xp
在 2000 年前后，随着个人电脑的全面铺开，操作系统战争开始在开源和商业领域充分展开，商业巨头和个人开发者几乎全都参与进来，无论功能还是视觉设计上，都必须一较高下。
Windows XP 在「开始菜单」的功能设计上是成功的，随后带来的影响持续了十几年。不过市场份额上的增长并不足消除对于微软对于设计的焦虑，所以下一代的 Vista，微软拼着消耗性能也要让新的视觉风格让全世界看到：
Windows Vista
以 Aero 为命名的视觉风格，最讲究的是玻璃式的光影变幻，Vista 当中的「开始菜单」也随之进行了更为「现代」的改进，精简了右侧文件夹的图标，通过双色对比来区分功能属性，也增加了信息层级，半透明的玻璃窗口也可以更好地传递界面之间的前后关系。
从成熟度上来说，比 XP 更进一步，随后是小幅迭代之后的 Windows 7：
菜单上变化不大，功能和设计上的延续性显而易见，随后就是翻车了的 Windows 8:
需要强调的是，Windows 8 所处的整个时代，是移动端设计开始繁荣的开端、拟物化设计开始不足以满足大众新鲜感的阶段，而从微软的 Zune 部门开始流行的 Metro 设计风潮开始影响整个公司走向，催生了 Windows 8 这样的新设计：
将简约的LOGO和多彩多变的动态磁贴结合到一起，用层级清晰的文字排版来快速传递更多的信息，不同尺寸的磁贴结合成不同的组，这种「开始菜单」的设计是近乎颠覆式的，但是对于用户认知上也同样是颠覆式的。
而完整的程序菜单需要向下滚动才能呈现，而用户看到的是布满整个屏幕的小色块和文字：
而用户对于 Windows 8 的「开始菜单」的质疑也正是从这里开始的，不仅全部程序列表不是可见的且没有引导，连原本的关机、重启等功能也被隐藏了，可用性大打折扣。
最终，在作为增补升级版而存在的 Windows 8.1 当中，开始按钮重新回到了桌面，但是「开始屏幕」依然保留，而全部程序的列表也有了视觉指引，没有「开始菜单」的 Windows 依然没有灵魂，没有从根本上解决问题。同时，Windows Phone 这边份额也是一路下跌，每况愈下。
原本期望借助「开始屏幕」让 Windows 系统更加兼容彼时正在上行的移动端生态，可惜平板模式本身极度拉胯，加上同样缺陷一堆的「开始屏幕」让整个 Windows 8/8.1 世代呈现出一种干啥啥不行的状态。而这个阶段同样也是微软换帅、内部重新整合设计部门、战略全面转移革新的阶段，产品出现这样的问题也并非单一原因造成的。
Windows Phone完蛋了。Windwos 8 也终于成为过去了。推倒重来升级系统，把问题留到过去似乎永远是最好的选择。
在 Windows 10 当中，动态磁贴的优点和传统 Windows 「开始菜单」重新组合到一起，久经验证的功能——或者说符合长久以来用户认知的功能，又重新集成回来，让「开始菜单」回归了「用户舒适」的状态。
一方面，Windows 10 即使进行重要的功能和设计改进，也并没有像之前那样做名称更换，而是自 2014 年以来一直以 Windows 10 的名称面向大众，几遍内里随着更新彻底翻新了好几波。
另一方面，在「开始菜单」的设计上，Windows 10 前期和后期在视觉层面上有大量的细节差异。功能上虽然保留了动态磁贴的优点，但是在具体的性能、图标元素、功能体验、视觉风格上，进行了大幅度的升级和改变：
2014 年刚刚发布时的 Windows 10 的开始菜单，大概是 Windows 8 时代所有用户都期待拥有的样子。
2016年之后，随着 Fluent Design 的逐步发展、成熟，Windows 10 在视觉上几乎是每版都不一样。「开始菜单」的优雅级别以肉眼可见的速度提升了上来。
但是功能上，「开始菜单」不管怎么换，它的默认位置倒是没怎么变过。在原本的计划当中，Windows 10 之后应该是会有一个针对移动端优化、面向双屏设备的 Windows 10x 系统。原本，Windows 10x 系统会伴随着双屏设备 Surface Neo 来发布的：
Surface Neo
而这个更加偏向移动端使用场景的「开始菜单」其实上用于这里的。只是出于种种原因，Neo 跳票了，Windows 10x 也一直没有出来。
泄漏的 Windwos 10x 界面
在原本的 Windows 10x 当中，全新的「开始菜单」被挪移到中间的同时，并没有包含关机等按钮和功能。不过并入 Windows 11 之后，开始菜单的核心功能还是得到了很好的延续，而目前泄漏的 Win11 系统界面也很好的印证了这一点：
不过最重要的是，Windows 10x 和 Windows 11 在「开始菜单」上的设计，算是一次向着「移动端设计最佳实践」的妥协。
虽然居中的「开始菜单」看起来很像 macOS 的 Dock 的设计，但是，实际情况并不是这么简单。
一方面，微软内部来看，试图重新进入移动端领域的微软选择了 Surface Neo 和 Surface Duo 两款设备作为切入点。前者使用的是 Windows ，而后者使用的是魔改后的 Android：
在移动端计算设备占据主流的今天，居中的底部快捷方式是经过了十几年验证的「最佳实践」。
另一方面，在桌面端操作系统上，这种趋势也相当的明显。macOS 自不必说，而借助低价入门硬件和教育类电脑采购而快速崛起的 ChromeOS 设备，也是使用底部居中 Dock 的大户：
ChromeOS
围绕着 APP 和服务的整个软件生态让用户对于复杂的系统级菜单功能没有早年间那么强烈的依赖，大量的移动端用户的基础认知和桌面端操作系统交互的逐步统一，让 Windows 早已没有必要在这个简单的事情上去做不必要的差异化，这可能才是 Windows 11 顺应趋势的主要原因。
当然，Windows 的老用户依然可以遵循自己的喜好，让开始按钮老老实实待在原来的位置。
Widonws 11 目前泄漏的开始菜单的设计相比于以往，更加简约，复杂的层级结构被精简掉了，APP 快捷方式保留了，点击 All apps 可以访问全部程序，原本固定的文件夹选项被人工智能推荐所替代，顺应着时代潮流，最重要的关机等功能依然存在。
控制面板这类对于移动端原住民有认知负荷的功能，也在这个后 Win10 时代，化作一个「设置」快捷方式，和其他的 APP 待在一起，如同其他的手机或平板一般。
Windows 11 正式发布会就在几天之后，关于全新的视觉设计、用户体验细节上的东西，应该有更多看点，不过最好还是再等几天，正式版上手之后，再详聊。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码蓝小助，报下信息，蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
文章来源：优设 作者：陈子木
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
手势作为图形界面与用户之间沟通的方式之一，在便携电子设备上大量应用。与实体按键相比，它有着纯粹的简洁性和无尽的创造性，手指的个数变化、不同变量的组合能够创造出无数的操控方式。
位移类手势是指代那些通过手指接触屏幕后的位置变化从而操控电子设备的手势，本篇文章主要讲解单指操作的位移类手势，多指的位移类手势（如捏合）将放到后续文章中讲解。
一谈到位移类手势，大部分设计师的脑海中可能会浮现出拖拽、甩动和轻扫这三个术语。然而，当我们想仔细谈论他们三者之间的区别时，大部分设计师可能无法准确地描述。为了能够准确描述三者的区别，我们在这里引入三个维度的概念，它们分别是控制方式、稳定化效果、以及阈值类型，这三者的不同的变化组合可以创造不同的位移类手势，拖拽、甩动和轻扫之间的区别也是这三个维度影响的。当我们在讨论不同位移类手势之间的区别时，不如说是在讨论这三个维度之间的区别。比如常见的轻扫手势，因为这三个维度的变化就会产生不同的变种，而且不同变种在体验上也存在很大差别，若不分场景随意使用，很容易就影响用户体验。那接下来我们首先了解一下这三个维度。
第一个维度是控制方式，它分为绝对控制和相对控制，也可以通俗的表达为跟手和不跟手，区别如下。
绝对控制/跟手：施加控制的一方（后文简称施控物）的某个属性变化与被施加控制的一方（后文简称受控物）的某个属性变化是对应的。
相对控制/不跟手：施控物的某个属性变化与受控物的某个属性变化不是对应的。
比如在网易云音乐的播放页（下图左），左右滑动黑胶时，手指是施控物，黑胶是受控物，手指的横向位置变化和黑胶的横向位置变化是对应的，即绝对控制。上滑调出评论页时（下图右），评论页的位置和手指的位置没有对应关系，手指的上滑仅仅控制评论页是否出现，即相对控制。
与相对控制相比，绝对控制允许用户去操控受控物的属性变化过程，因此给予了用户更强的掌控感。比如在微信读书阅读页边缘右滑，手指的横向位置与书籍封面的变化过程对应，模拟现实生活中慢慢合上书的感觉，如下图。
但是在有些场景，为了避免混乱，属性变化过程是不适合被用户绝对控制的，此时我们应采取相对控制的方案。比如 iOS 的相机中，左右滑动切换拍摄模式，由于前后不同模式之间的页面框架变化较大，切换时会有过多元素的属性变化，如果使用绝对控制就会导致切换拖沓且混乱，使用相对控制就能避免这个问题。
当我们使用手势控制某个受控物时，由于手势的某个属性（如手指位移）达到阈值，进而导致受控物的某个属性稳定在了特定状态的效果被称为「稳定化效果」，或者也可以称为「吸附」。
稳定化效果能够保持界面的视觉秩序，避免过多的中间状态导致界面的杂乱，进而帮助用户聚焦信息。
是否有稳定化效果是区别轻扫与另外两个手势即甩动和拖拽的重要维度，当某个位移类手势有稳定化效果，我们就将其称作轻扫。
以滑动切换抖音视频为例，当手指上滑的位移距离和释放速度其中的某一项属性达到阈值后，下一条视频会往上移动到一个固定的位置然后进入稳定状态，而不会出现停留在不完整的中间状态，如下图所示。
在 iOS 端的微信消息页左滑某条消息后会出现更多操作按钮，按钮会在手指滑动的距离达到阈值并松开后稳定在一个固定的大小，而不会停在类似下图左所示的混乱的中间状态。
在多内容选择的场景中，如果滑动与选中是绑定的话，一般需要使用稳定化效果。例如在 iOS 相机里选择滤镜时，滑动滤镜选项不但能够控制滤镜选项的位置，并且会自动选中一个位于中间位置的滤镜，位置的稳定化避免了被选中选项的不明确。
如果滑动与选中是分开的，比如美图秀秀的滤镜选项需要先滑动后选中，这种情况下稳定化效果不是必要的。
不同的稳定化规则带给用户的体验差异是非常大的，最明显的差异是在效率方面。我们使用稳定化效果的强弱来理解，稳定化效果越强，单次滑动能够切换的选项个数越少，效率越低。稳定化效果越弱，单次滑动能够切换的选项个数越多，效率越高。
比如在比较常见的 banner 切换功能中（下图左），无论手指位移和释放速度的值有多高，banner 只能切换并稳定到下一个，不能够一次切换多个 banner。而在网易云音乐的首页排行榜中，一次滑动能够切换多个内容卡片。因此，我们可以说前者的稳定化效果比后者强。
拖拽和甩动虽然没有稳定化效果，但是也存在效率的高低。我们可以将其与轻扫放在一起做对比，如下图所示，拖拽、稳定化效果强的轻扫、稳定化效果弱的轻扫、甩动它们切换效率依次增加。
那么我们决定添加稳定化效果后，如何选择强弱程度呢？选择没有绝对的对错，整体来说主要考虑两点，业务诉求和用户诉求。例如在常见的 banner 切换中，banner 的总数量一般不会很多，业务的诉求是希望尽可能曝光每一个 banner ，使感兴趣的用户进行消费，因此这里比较适合做稳定化效果强的轻扫。在云音乐的排行榜案例里，不同用户感兴趣的榜单是不同的，稳定化效果弱的轻扫可以方便用户单次滑动切换多个，快速切换到自己感兴趣的榜单的大概位置。
百度 App 的表情面板原本是左右轻扫浏览表情，在一次改版中改为了上下甩动浏览。主要目的之一就是为了提高浏览效率、降低非首屏表情的曝光难度。
微信视频号的改版是一个典型的案例，旧版的微信视频号的视频流并不是类似抖音那样的全屏化形式和轻扫手势（下图右），而是占据屏幕尺寸三分之一到二分之一之间的卡片形式（下图左），并且使用甩动而非轻扫。视频号问世初期优质内容匮乏，社交推荐算法不完善，贸然模仿抖音式的全屏化形式和轻扫手势的话，会导致用户浏览到劣质视频时负面感受被增强且切换效率变低，反之卡片形式加甩动手势给予了用户更自由的选择空间，提高了用户的切换效率，降低了负面体验。等到如今时机成熟，再从卡片形式和甩动手势换成全屏化形式和轻扫手势就势在必行了。
在某些场景，用户需要先通过高效的方式选择特定区域的内容，然后进入聚焦状态进行内容浏览和慢速的切换，此时我们需要设计两种切换效率不同的手势应对前后场景的变化。如下图，在 iOS 的照片 App 中，先使用切换效率较高的甩动进行粗略切换找到目标图片大概位置，点击进入大图模式时使用切换效率较低的轻扫进行精确切换查看。
触发稳定化的时机可以分为释放前和释放后，不同的时机带给用户的体验也不同。释放前稳定化指的是用户使用手指滑动屏幕时，手指位移达到阈值后，手指无需离开屏幕，稳定化即可被触发。如下图左，iOS 的相机滑动切换滤镜使用的就是释放前稳定化。释放后稳定化指的是用户使用手指滑动屏幕时，手指位移或释放速度达到阈值后，手指必须离开屏幕，稳定化才能被触发。如下图右，常见的 banner 切换。
释放前稳定化可以避免拖沓，增加切换效率，但是缺点是无法反悔回退且缺乏掌控感。反之，释放后稳定可以反悔回退，掌控感强，但是缺点是比释放前稳定化拖沓了一些。
阈值是能够触发变化的最小值。比如当水的温度达到 100 度时就开始变成水蒸气，100 度就是一个阈值，温度是阈值类型。在手指与屏幕的交互中，手指在屏幕上的某个停留时间、位移、释放速度、点击次数等都可以成为一个阈值类型，达到相应阈值后就可以触发相应的变化，常见的变化有受控物的位置、大小、不透明度等，理论上变化可以是任意的。
在位移类手势中，通常会用到的阈值类型有手指位移和释放速度，手指位移是用户在手指触摸屏幕时的位置与之后某个时间手指位于屏幕的位置之间的距离，释放速度是用户的手指在屏幕表面进行位移后离开屏幕那一瞬间的速度。
市面上的 App 暂时不存在仅通过释放速度判定而与手指位移无关的阈值判定方式，因为其不太符合常识。因此我们在设计位移类手势时，能够选择的阈值判定方式常见的有两种：① 判定手指位移和释放速度满足任意一个即可；② 仅判定手指位移。
当我们设计手势时，就需要考虑两者的区别。由于 ① 比 ② 增加了释放速度带来的额外移动距离，因此 ① 的主要优点是高效。但是由于我们无法预判释放速度带给受控物的移动距离长短，所以相对应的缺点就是易误操作和不精确。②就恰恰相反，由于不存在释放速度造成的不确定因素，它的优点是不易误操作和精确，缺点是低效。
甩动和拖拽之间的区别就在于阈值判定方式，甩动是 ① ，拖拽是 ② 。如下图，当在微信消息列表找相应的消息时，用户的诉求就是能够快速找到特定消息的位置，对特定消息的出现在屏幕的位置也没有特定要求，只要能够被手指点击到即可，因此选用甩动较为合适，但是对于调节音量、亮度这一类的操作，滑动的范围有限，因此用户对效率没有太高的要求，但是对于滑块位置的精确度有要求，因此选用拖拽是更为恰当的。
再举一个反例，在 Steam 移动端横滑首页的泳道卡片时（下图左），使用的手势是拖拽而不是甩动，浏览起来特别低效。更适合的做法应为甩动，会更符合此场景下的快速浏览的诉求，如下图右的豆瓣。
对于轻扫来说，使用哪种阈值判定方式有多种情况（如下图所示）。在本文中，根据阈值类型、稳定化效果以及控制方式的不同我将把轻扫分为 A-E 共 5 类（A-E的命名方式仅存在于本文章，因此在向其他人传达时，尽量使用在后文我介绍的手势描述而不是类别名称，以便于对方理解。）。后续会为大家仔细举例讲解，大家现在仅了解一下即可。
当我们在刷抖音视频时使用的手势就是轻扫，是否滑动到下一条视频进行播放的判定方式是① 判定手指位移和释放速度满足任意一个即可，对应的手势类别是上面表格中的轻扫A。如下图所示，在刷抖音时，如果使用判定手指位移的方式，我们可以将手指在垂直方向位移大于半个屏幕高度的距离，从而切换到下一个视频。如果使用判定释放速度的方式，我们可以移动任意的垂直距离但是手指离开屏幕时保留一个速度从而切换到下一个视频。大部分情况下用户都会使用判定释放速度的方式，因为既省力又便捷。
如果将阈值判定方式改为 ②仅判定手指位移，对应的手势类别是上面表格中的轻扫 B，并且位移的阈值设置得比较大的话，给用户带来的负面体验可能将是非常大的。比如下图中打开美图秀秀的短视频评论浮层后，想要下滑收起时，App 仅判定手指位移，而且这个位移阈值设置得比较大，对于希望通过快速滑动一小段距离收起浮层的用户来说体验很差。即使由于开发资源有限我们只能做到仅判定手指位移，我们也可以通过减少手指位移的阈值来降低负面体验。
但是某些场景下，②仅判定手指位移是更加合适的。比如想要在微信中下拉打开小程序选择页，就只能通过手指位移达到一个特定的阈值才能够触发，无论怎么用力滑动去增加释放速度都无法打开小程序选择页。这样处理的原因是在微信消息列表页，上下滑动浏览微信消息是一个高频操作，如果释放速度也能作为打开小程序页面的阈值的话，用户可能就极易在下滑消息列表时误操作，无意间打开小程序选择页。
因此，对于位移类手势，选用哪种阈值判断方式要依据用户使用场景和诉求，不能想当然地设计。
了解完三个基础维度后，我们再将其进行组合，从特定手势的角度更全面地理解它们的差异和使用场景。三个维度的排列组合能够生成十余种位移类手势，我列举出了常见的 7 类，如下图所示，这 7 类基本涵盖了 95% 以上的场景，我将一一举例说明。由于施控物控制受控物改变的属性一般都为位置，因此接下来在描述下面手势的定义时我都以受控物的位置变化进行举例。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，无论释放时手指是否仍有速度，受控物都会立即停止移动。（下图的动态演示由 Principle 制作，观看会有些不太直观，大家可以在文章结尾处下载 Principle 源文件后导入到手机里体验，源文件包含文章提到的所有位移类手势）
精确度高但效率低。由于阈值类型仅判定手指位移且没有稳定化效果，拖拽适用于对操作精度要求高，对效率要求低的功能。
在 iOS 设置中调节亮度时，在有限范围内，手指左右拖拽可以控制亮度变化。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动。若释放时手指仍有速度，受控物将移动一段距离后才慢慢停止，移动的距离与释放速度呈正相关。若释放时手指速度为 0 ，则受控物立即停止移动。
精确度低但效率高。由于阈值类型判定释放速度和手指位移，甩动适用于需要快速浏览较多内容的场景，如滚动浏览列表。
在微信的消息列表页，使用甩动手势控制列表上下移动，若释放时仍有速度，列表将仍移动一段距离后才慢慢停止。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动。若释放时的速度和手指位移有任意一个达到阈值，受控物将稳定在一个新位置。若释放速度和手指位移没有任何一个达到阈值，受控物将回到原位置。
由于轻扫拥有稳定化效果，因此它能够保持界面的视觉秩序，避免过多的中间状态导致界面的杂乱，进而帮助用户聚焦信息。接下来讲解的其他轻扫类型都有这一特性，就不一一赘述了。轻扫 A 与接下来要讲解的轻扫 B-E 的最大不同之处在于轻扫 A 的阈值类型为「释放速度和手指位移」，这让轻扫 A 与轻扫 B-E 有两点不同，一是轻扫 A 可以通过释放速度的快慢去控制内容的切换数量的多少，更加高效，二是轻扫 A 可以通过用手指在屏幕滑动很短的距离但离开屏幕时保留一个速度来切换内容，因此更加省力。
在刷抖音时，如果使用判定手指位移的方式，我们可以将手指在垂直方向移动大概半个屏幕高度的距离，从而切换到下一个视频。如果使用判定释放速度的方式，我们可以移动任意的垂直距离并且手指离开屏幕时保留一个速度从而切换到下一个视频。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动。若释放时手指位移达到阈值，受控物将稳定在一个新位置。若释放时手指位移没有达到阈值，受控物将回到原位置。
轻扫 B 与轻扫 A 相比唯一的区别是阈值类型减少了释放速度的判定方式，这提高了触发切换的难度，使操作成本变高，但是在某些场景下，这也降低了误操作的概率。如下拉刷新等。
比如想要在微信中下拉打开小程序选择页，就只能通过手指位移达到一个特定的阈值才能够触发，无论怎么用力滑动去增加释放速度都无法打开小程序选择页，这样处理的原因是在消息列表页上下滑动浏览消息是一个高频操作，如果释放速度也能作为打开小程序页面的阈值判定方式，用户可能就极易在下滑消息列表时误操作，无意间打开小程序页面。
因此，当页面已存在一个滑动操作的情况下，还存在另外一个方向相同的滑动操作且仅会在边界情况下才能触发时，为了避免误操作，会将后者的手势设计为轻扫 B 。
上文提到，轻扫 A 的阈值类型为判定「释放速度和手指位移」，轻扫 B 的阈值类型为仅判定「手指位移」，由于前者的实现成本比后者高，导致本应适合做成轻扫 A 的功能有时只能妥协做成轻扫 B ，比如之前提到过的美图秀秀的短视频评论浮层案例，但我们也可以通过减少手指位移的阈值来降低负面体验，后文会讲解如何与开发同学沟通。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，但是受控物并不随着手指的控制而同步移动，仅当释放时手指位移达到阈值时，受控物才开始移动并稳定在一个新位置。若释放时手指位移没有达到阈值，受控物位置则一直保持不变。
上文讲到过释放后稳定化和相对控制的缺点，释放后稳定化比较拖沓，相对控制让用户缺乏掌控感。两者如果应用到了同一个手势（即轻扫 C ），就会导致用户在滑动屏幕时得不到任何反馈，用户会疑惑是否因为自己操作不当或是设备出现故障。只有当用户手指离开屏幕后才会发现触发了操作，整体的交互流程给用户一种滞后与延迟的感觉。
因此轻扫 C 与其他类别的轻扫相比存在劣势，但是它也存在很多的 App 的 H5 页面中，我的猜测是由于 H5 对于判定释放速度和绝对控制这两个维度与客户端相比难度大很多，因此只能退而求其次选择轻扫 C 这个较差的方案，实际上在同样的应用场景中用轻扫 A 替换轻扫 C 可以带来更好的体验。
下图左是 QQ 的个性装扮的 H5 页面，卡片的切换使用的就是轻扫 C ，如果能够优化为轻扫 A 体验会更好，比如下图右的音街首页卡片的设计。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，但是手指位移达到阈值前受控物并不随着手指的移动而移动。若手指位移达到阈值，无需手指释放，受控物将开始移动并稳定在一个新位置。若手指位移没有达到阈值，无论是否释放，受控物位置则一直保持不变。
相对控制的方式降低了用户的掌控感，释放前稳定化减少了操作的拖沓感。使用此手势的场景是在多个对象之间切换时，我们不希望用户过于自由地操控对象之间的属性变化过程，并且牺牲掌控感从而增加单次的切换效率。
比如 iOS 的相机中，左右滑动切换拍摄模式时，由于前后不同模式之间的页面框架变化较大，切换时会有不同元素的属性变化，如果使用绝对控制和释放后稳定化就会导致切换混乱且拖沓，使用相对控制和释放前稳定化就能避免这个问题。
上文我们讲到，通过轻扫手势 A-D 对受控物的绝对/相对控制都是存在于稳定化前，受控物一旦稳定化，就脱离了手指的控制，需要手指离开屏幕后再次接触屏幕开始下一次控制。
轻扫E的不同之处在于它可以在受控物稳定化后，仍然控制受控物朝着下一个节点稳定化，在每个节点之间切换时能够明显感觉到分段感，如下图案例所示。
由于轻扫E相对于轻扫 A-D 的特殊性，控制方式中的绝对控制和相对控制无法覆盖这个特殊现象，因此我们使用「多段相对控制」来命名轻扫E的这种特殊的控制方式。
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，若手指位移达到阈值，无需手指释放，受控物就稳定在了一个新位置，但是此时手指还是仍然可以操控受控物继续移动的，并且继续移动过程中如果手指位移达到阈值将会到达下一个稳定化状态。
轻扫 E 适用于需要在多个对象之间快速切换和确认的场景，它的使用感觉很接近拖拽。如下图所示，我们可以这样理解，当被切换的对象数量接近于无穷大同时每个对象之间的距离接近无穷小时，轻扫 E 就可以视为拖拽。
iOS相机人像模式切换打光方式、微信的通讯录滑动字母索引导航，它们都使用轻扫 E 来满足多个对象之间快速切换和确认的需求。
了解完上述的维度和常用手势后，我们在脑中就可以形成一个思考框架。当我们要针对一个功能设计位移类手势时，就可以从阈值类型、稳定化效果以及控制方式这三个维度思考。接下来我用一个我参与过的实际项目作为案例给大家讲解一下思考过程。
本案例是网易云音乐陌生人版一起听中的一个功能，一起听的双方在听歌过程中会收到彼此共同信息，比如听歌口味相似度、是否同城、都喜欢哪些歌手等，目的是为了增加可玩性和互动性、降低退出率，鼓励用户互相了解、提高一起听过程中的社交体验。
为了营造仪式感和避免信息过载，共同信息的展示方式设计为了一次只能看一条，进入浮层后默认展示最新的一条，可以通过滑动查看上一条。因此为了避免出现两条同时占据展示区域的混乱状态（如下图左），我们为其添加了释放后稳定化效果（如下图右），同时为了方便用户可以快速浏览旧的共同信息，这里使用的稳定化效果是较弱的，用户可以通过滑动一次切换多个共同信息。
由于需要满足用户快速浏览旧的共同信息的诉求，阈值类型选用了「判定手指位移和释放速度满足任意一个即可」，用户可以通过控制释放速度进而控制信息的切换数量。控制方式则选择了掌控感强的绝对控制。最后的结果如下图所示。综合三个维度进行归类，此手势为稳定化效果较弱的轻扫 A 。
位移类手势的方向一般为上下或左右，但并不是一定要完全垂直或水平才能够触发手势。当上下滑动和左右滑动同时存在于一个页面时，默认会有一个容错角度，比如上滑时手指滑动方向只要左右偏移不超过 45° 都会被判定为上滑，如下图所示。
但是有时开发同学出现失误，导致容错角度没有均分，例如下图中触发上滑和下滑的角度极小，导致用户在上下滑动时非常容易误操作为左滑和右滑。
云音乐也曾有过类似的遗留问题，iOS 端的播放页上滑调出评论页极易误操作为左右滑动黑胶切歌（如下图 A ，现已修复），安卓端的账号侧边栏上滑浏览极易误操作为左滑收起侧边栏（如下图 B ）。
因此，在验收阶段，除了上述的三个维度外，角度的容错性检查也是重要的一环。因此在验收时间充裕的情况下，最好要切换不同的手持方式分别体验一次，因为有些问题只有在特定的手持方式下才能够被发现。
客户端的角度判定方式实际上是一个比较复杂的过程，上述的内容是简化的版本。后续将延展为一篇独立文章给大家仔细聊一聊。
上文讲到，基础的三个维度即阈值类型、稳定化效果和控制方式决定了手势的类别，是设计阶段一定要定义清楚的。但是除此之外，设计一个手势需要定义的细节非常多。比如受控物的移动是否有速度曲线？手指位移与受控物之间的位移的比率是多少呢？这些都是开发阶段不得不面对的。幸运的是，安卓和 iOS 有系统封装好的一套系统组件可以调用，操作系统自行解决了刚才讲到的细节问题，但是 H5 框架下是无法调用系统组件的，手势的各种细节都需要前端开发人员自己编写，难度较大，大部分情况只能实现一些比较简陋的效果，这也是为什么在很多 H5 框架下的界面滑动的体验比较差的原因。
由于信息不对称，与开发的沟通过程中，很容易出现理解偏差。比较常见的错误有：将甩动误解为轻扫 A ，将轻扫 A 误解为轻扫 B 或甩动。如果造成效果达不到预期的情况，很多设计师不知道如何让开发同学修改，只能说“这个手势不丝滑，优化一下”，开发同学也是一头雾水，不知道往哪个方向优化。如果我们能够直接说出“阈值判定方式现在只有手指的位移，需要释放时的速度也能够触发跳转；这个位移的阈值太高了，滑动时很难触发跳转，需要把阈值改为 16pt ”类似这样准确的描述，就能够大大降低沟通成本，顺利验收。为了避免沟通出现问题，下面我将日常经验总结出现希望能够帮助到大家。
首先，一旦涉及到位移类手势，除了必要的文字描述外（可参考上述的手势定义的描述），最好给开发体验 demo 或者其他 App 上类似的效果，否则很容易产生理解偏差。各种 App 上的类似效果大家可以用本文的每个手势的案例给开发同学展示，但是 App 可能会更新，案例可能在未来某个时间就找不到了，所以我用 Principle 做了一个简易的基础 demo 集合（如下图，源文件在文章末尾下载），和我上述介绍的手势是对应的，大家可以拿着这个 demo 给开发同学演示大概的效果，也可以在这个 demo 源文件修改。
下载链接： https://pan.baidu.com/s/1iaFrcFwzC58TG3L17bjC_Q 密码: asto。
拖拽和甩动由于需要定义的细节参数都被操作系统提前封装好了，一般不需要我们给到额外的标注。但是对于轻扫，我们需要将细节定义清晰，下面将详细讲解。
上文讲到，阈值类型一般有两种：① 判定手指位移和释放速度满足任意一个即可；② 仅判定手指位移。①的开发成本高于②。
如果我们选用轻扫的阈值类型是①，开发同学编写代码需要两个参数的阈值，分别是手指位移和释放速度。手指位移阈值一般默认为受控物的1/2，例如下图的全屏短视频和 Banner 。
当然我们也可以自定义一个阈值，比如 100pt 、受控物高度的 1/6 等，没有特别的需要的话使用默认值即可而且也不用给开发同学特殊说明，但是如果有特殊需要想要修改默认值，就要告知开发同学你自定义的手指位移阈值。对于释放速度阈值，通常默认就非常的小，几乎是大于 0 即可触发，一般情况下使用默认值即可。
在本应该选用①的场景中，如果由于技术成本原因不得不选用②，需要注意的是由于缺少了释放速度的判定，手指位移的阈值我们需要设置得小一些方便用户触发，否则就会出现上文中美图秀秀浮层的那样的体验问题。经过我的实验，手指位移阈值一般定为 16pt 是比较适中的，既不会太容易误操作也不会难以触发。
轻扫是一定存在稳定化效果的，关键在于告知开发是释放前稳定化还是释放后稳定化。从开发的角度讲，系统会监测用户的行为，用户在使用滑动时会有按下（down）、移动（move）、抬起（up）三个行为，释放前稳定化是在移动阶段判断阈值并触发操作、释放后稳定化是在抬起后判断阈值并触发操作，开发成本几乎没有区别。
上文提到过稳定化效果强弱的概念。稳定化效果越强，单次滑动能够切换的选项个数越少，效率越低。稳定化效果越弱，单次滑动能够切换的选项个数越多，效率越高。首先，我们需要确定单次滑动允许切换多个还是只允许切换一个，如果允许切换多个，开发同学会设定一个控制切换难度的系数，而只允许切换一个的话就不存在这个系数。通常我们也不需要修改这个默认系数，但如果想让操作更加难或容易触发，可以告知开发同学修改这个系数。
绝对控制比相对控制的开发成本高，如果开发资源并不是很紧张，需要绝对控制的场景就不要退而求其次使用相对控制。涉及到轻扫手势一定要告知开发同学控制方式，否则很可能被视为相对控制处理。
通过本文的学习，我们不但可以在开发工作进行前与开发同学高效沟通，保证开发工作的顺利进行，也可以对自家移动端产品的现有手势进行逐一排查发现问题点进行记录，并且找到合适解决方案，然后用准确的语言描述给开发同学。下图是我在进行手势排查后输出的表格，挑选出一些有代表性的案例给大家作参考，开发同学可以通过它快速明确问题，理解解决方案。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码蓝小助，报下信息，蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
很多网站仍然在使用老旧的页面设计，比如国内一些企业官网，万年不变的相类似的模板，外国的则是hero页面，带CTA按钮，三栏式的布局。这些设计不能说是不好的设计，很实用，用户能够预测展示的内容，也容易找到需要的内容。但是正因为可预测，用户没有新鲜感，没有期待，所以我们找了一些不仅打破常规，也依然有良好用户体验的网页设计。
蓝蓝设计(北京兰亭妙微科技有限公司）是一家专注而深入的UI设计公司，公司对UI设计的追求一向很高，致力于为卓越的国内外企业提供卓越的手机app/安卓ui设计、软件界面设计、网站设计，用户研究、交互设计服务。
接下来是精彩的UI设计赏析
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码蓝小助，报下信息，蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
更多精彩文章：
ui界面设计之网站设计案例欣赏(一)
很多网站仍然在使用老旧的页面设计，比如国内一些企业官网，万年不变的相类似的模板，外国的则是hero页面，带CTA按钮，三栏式的布局。这些设计不能说是不好的设计，很实用，用户能够预测展示的内容，也容易找到需要的内容。但是正因为可预测，用户没有新鲜感，没有期待，所以我们找了一些不仅打破常规，也依然有良好用户体验的网页设计。
蓝蓝设计(北京兰亭妙微科技有限公司）是一家专注而深入的UI设计公司，公司对UI设计的追求一向很高，致力于为卓越的国内外企业提供卓越的手机app/安卓ui设计、软件界面设计、网站设计，用户研究、交互设计服务。
接下来是精彩的UI设计赏析
蓝蓝设计秉承设计优秀，不断超越的理念，诚信敬业、专业耐心的工作作风，一直坚持注重用户心理体验及“设计与营销”等领域的理论与实践相结合。10余年专注努力，300+案例磨练。我们在ui创意设计，用户体验与交互设计，各种类型软件界面设计，国际化标准和流行趋势，进行过不断的学习和实践。蓝蓝设计提供的是可以信赖的ui设计服务，我们内部有一套管理要求，比如去客户现场每周一次的检视和沟通、内部提案会议、每天下班前的整理反馈成果发邮件、随时沟通的qq、电话，阶段性的汇报和进度记录整理。多劳多得的奖励机制，客户满意度评价奖励机制，鼓励大家用心、平和、耐心、勤奋、创新的做事.
（以上图片均来源于网络）
（精美流程图设计）
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
更多精彩文章：
ui界面设计之网站设计案例欣赏(一)
设计尺寸一直都是设计师最热衷讨论的问题，讨论到最后结论总是一个死板的尺寸，很少有人去讲也真正明白背后的逻辑。今天的设计杂谈就带大家来了解一下，设计尺寸背后的逻辑以及设计尺寸如何去定义。希望之后在大家的交流中不要再去纠结我的设计尺寸究竟应该是多少？还是那句老话，耐心看完，你一定有所收获～
我先说结论，常见 B 端设计稿尺寸建议采用 1440×820，因为去除浏览器顶部页签以及地址栏高度 80px，因此高度上为 820px 而不是大家常见的 900px
相信很多 B 端产品设计师都是从 C 端产品中转型而来。想要搞懂设计尺寸的基本逻辑，我们先搞清楚大家熟悉 C 端产品的情况。在移动端设计尺寸上的定义，我们只需要考虑 iOS 设备与安卓设备之间分辨率的区别。而在目前，大多数移动端设计稿都是采取 iPhone 12 尺寸即：375 x 812 的分辨率
（这里就不讨论什么物理分辨率以及设计分辨率等内容）
因为移动端也会存在多个分辨率的情况，我们针对其他不同的尺寸，通常采取简单页面一稿适配多端，只针对核心页面进行多分辨率的适配。上面我们算是理解了作为移动端的分辨率的基本情况。而设计稿的尺寸是从何而来？大家想想，为什么我们在移动端设计稿的尺寸会从以前的 iPhone 8（375×667）转移到 iPhone 12（375×812）呢？
我个人认为会有以下几点：
1. 主流性
由于 iPhone 12 类的手机尺寸占比逐年增高，早期的 iPhone 8 的分辨率已经不再合适现如今手机的屏幕尺寸。因此决定分辨率尺寸的第一个因素便是这个分辨率的市场占有率。由于手机全面屏时代的到来大多数手机的屏幕比例都演化成类 16:9 的尺寸，因此参照 iOS 的生态下，我们的设计稿就会有如此的转变
2. 兼容性
作为移动端最为基准的设计尺寸，它一定要具备兼容性才能成为基准的尺寸。兼容性即能够通过该尺寸进行向上、向下的拓展，方便在一些主要页面中多尺寸的设计，比如：iPhone X 的尺寸，可以进行拓展成为 iPhone 8、iPhone 12 Pro Max 以及各类安卓端产品。减少设计稿因分辨率所带来的差异性
搞清楚了移动端的逻辑，我们再去思考一下桌面 WEB 端的情况呢？
因为 B 端产品的特殊性，在互联网中的分辨率数据只能作为一个辅助的参考（比如百度浏览研究院的数据），更多对于尺寸的定义还是来自你用户使用的设备。比如我们在一个针对销售的 CRM 系统中，销售使用的场景有两种：
首先通过用户访谈了解到大多数销售都是采取移动办公的形式，因为销售需要对不同的企业进行登门拜访，拜访完成会跟进一些销售记录。因此对于电脑分辨率会相对较小。对其分辨率的数据埋点得知，分辨率以：1440×900、1366×768 两种为主。第二种场景下，用户以 1920×1080 分辨率为主，主要是市面上的办公显示器多为 24 寸即 1920×1080然后想要去寻找作为设计稿的尺寸也与移动端一样，需要满足：主流性、兼容性两种不同特性的需求。因此在我的设计稿中，会采用 1440×900 的尺寸，因为它更容易兼容且更为主流
OK，我再举一个反例，在我之前做过的一个线下诊所系统中，通过走访我们了解到，几乎所有的医生都是配备的 24 寸显示器，分辨率也都为 1920×1080。
因此在尺寸的选择上就没有必要去一味的选择 1440 这一尺寸。
首先显示器的分辨率并不能代表我们的实际设计尺寸，就像在 iPhone 的设计稿中，会有 StatusBar 的存在，会预留上半部分空间
因为目前，大多数 B 端产品都是通过浏览器的方式进行呈现，大家也都知道电脑的浏览器中（Chrome 浏览器为主），还会存在页签高度以及当前网址、书签栏（书签栏大多数是隐藏的，因此不算进内），而想要真实了解设备中一屏的高度，就还需要对上面的分辨率尺寸进行处理：
电脑分辨率 – 页签高度 – 网址栏 – 书签栏 = 设计稿真实高度，即：1440×820 尺寸进行设计
因此想要让自己的设计稿被前端进行完整还原，就必须将浏览器页面当中的很多因素考虑进去。类似于我们去设计移动端的小程序，他也会有顶部固定的区域进行展示。
文章来源：优设 作者：CE青年
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
对于一直做 C 端产品设计的同学来说，面对复杂又陌生的 B 端业务，难免会有些头“秃”，设计师该如何应对？或者说我们如何更好地完成项目？并挖掘和发挥设计价值？B 端产品通常具有较高的业务门槛和业务深度，对于设计师也具有一定的挑战性，本文根据自己的这一年的 B 端工作经历，总结了一些设计方法以及自己的经验。希望会对处在这个领域感到迷茫的设计师有所指引和帮助。
B 端产品业务目的明确，业务逻辑和场景相对比较复杂，所以对设计师的要求更高，要更清晰理解 B 端业务，下面是我转 B 端产品设计时的一些思路：
针对之前一直做 C 端的我来说转战到 B 端业务，也面临着两个端的设计反差，B C 端的商业属性、产品定位、用户人群、视觉呈现、业务逻辑/流程都不尽相同，这将是一场知识迁移的过程。
需要转变自己之前的整个设计思路和角色定位，从之前被动接需求做图，只做执行输出设计稿，转被动为主动。也深知设计和产品的配合就是互相成就，互相补位。面对之前不太熟悉的 B 端那些较为复杂的业务场景和逻辑，尽量让自己在和产品需求对接时，提前介入，思维前置，全链路思考主动提出对产品的一些想法，难点或疑惑点都可以，也可以帮助自己梳理需求，了解从根本要解决的问题是什么，需求背后其核心是达到什么用途与目的，也想办法去收集来自用户、业务方的反馈，或主动去进行竞品调研，用户调研，这样不仅可以让我们更清晰的了解用户需求和业务场景，在这个过程中，往往也会更容易挖掘出需求的突破点，找到更好的解决方案和更有价值的驱动点，为业务赋能。不再只做被动接受的工具人，也会要求自己去做“项目推动型设计师”，尽量让自己全链路的参与其中，在每个环节寻找可挖掘和贡献的价值点。
转变了自己的定位后，由于自己负责的 B 端项目，是之前没有接触过的业务，很多业务场景无法使用设计 C 端产品时的同理心来对待，又有较高的业务门槛和业务深度的，首先我认真系统的学习业务涉及到的一些相关知识，可以帮助了解自己手里的设计工作的业务细节，和产研团队多方面沟通产品的需求，弄清每个步骤的业务逻辑，不懂可以多问多学，在产品评审需求的环节，一定要将业务逻辑理解透彻再考虑应该如何进行设计实现。要问问为什么业务流程是这样，每一个页面的跳转每一个功能的用途以及业务含义是什么等等，多出几版样式进行探讨最优方案。
设计工作的开展前，首先需要分析产品的背景是什么，要做什么，要提供用户什么服务？调研分析一下它的竞品状况是怎样的？现在是什么发展阶段（一般 b 端的产品竞品是极少的），不管是网上查找还是书籍搜寻了解一些行业内的资料，也可以找一些间接竞品吸取灵感。了解产品的目标用户群有哪些（用户画像）？不同角色的用户会有哪些权限？以及分析业务存在哪些重要的流程，背后设计的意图和产生的价值是什么，要解决用户或业务上的哪些痛点。进行了初步的业务分析以后，大致分析下使用场景，在需求分析阶段，要对产品本身和行业本身有一些基本的认知。
B 端产品的逻辑较为复杂，在交互及体验上的要求也要更为谨慎。所以设计上需要更加克制和理性，B 端产品虽然视觉上交互上的整体要求没有 C 端那么高，但是需要做到每一个功能点能够清晰明确的展示，并且让用户知道每个功能按钮或页面的使用意图。避免功能堆砌关系混乱。
在产品设计之初，需要全面考虑，把握产品设计的大方向与业务发展的一致，同步搭建页面通用的设计框架，统一的视觉设计语言，通用的组件的规范，可快速复用提效设计，即可把更多的精力投入到梳理产品逻辑及交互方式和功能的视觉表现上。也要时刻与产研团队保持沟通，从技术和设计层面综合考虑，哪种视觉呈现方式更合理，哪种方式更提效更稳定，支持的场景更全面…确保当前产品方案可行性。全面打造产品体验的一致性，实现有序、统一的操作体验，总之核心重点：界面清晰易懂，用户的操作门槛低，能够快速的使用产品，高效、专注完成任务。
项目上线后，及时复盘总结也尤为重要，这也是我接下来要重点去做的事情，可以通过回顾和思考，来归纳分析自己做的成功与不足的地方，把那些对后续有帮助的、复用性高的经验加以总结，沉淀自己的一套方法论。复盘是设计师自我提升的有效方式，也可以赋能团队为团队提效，提升自己的价值。
啰嗦说了这么多，比较细碎，不乏逻辑凌乱的片段，但也算自己对 B 端设计的一些想法吧～B 端产品承载的信息和逻辑比较复杂一些，所以需要对功能层级的划分呈现多考虑一点，需要有清晰的逻辑，多站在企业用户的角度去考虑，使任务能够精准化触达，毫不拖泥带水是设计 B 端产品最重要的工作。
文章来源：优设 作者：58UXD
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
那些关注用户体验的人们经常问我一个问题：什么是B端的用户体验？它与C端的用户体验有何不同？作为一名过去5年多主要从事B端IT产品的设计师，在这里给大家讲述一些我的想法。
首先，B端产品通常有2种类型：企业内部产品（Internal Solutions）和企业对企业的服务产品（B2B）。
企业内部产品的用户体验设计有一些独特性：
很遗憾，几乎所有企业内部产品或项目都被严格的保密协议（NDA）保护着。
绝大多B端项目都是为特定用户提供的专门内部流程。这意味着除了那些每天盯着它用的用户，其他任何人都可能不会看到你的设计。即使你设法获得了将其放入自己作品集的权限，也需要抹掉所有敏感的数据才行。
不过幸运的是，大多数有足够能力来构建自己的定制IT解决方案的公司通常规模很大，而且它们的品牌可能带有足够的“影响力”，这样，项目身价得以抬高，也能让设计师进入面试的下一步流程。
设计企业内部所用产品的优点：你的未来用户将会是你的同事们。因此，在进行可用性研究时，你无需担忧任何层面的法律问题。另外，由于大多数内部项目都是为了优化和改进现有的工作流程，你的用户往往会非常愿意配合你的调研工作。因为设计不当的产品让他们的工作饱受折磨，因此尽早获得反馈对他们来说是最有利的。
但这其中的弊端是，由于你的同事们需要平衡全职工作，你很可能无法占用他们的宝贵时间。如果你能解决这个问题，他们通常会提供比您预期更多的反馈。
关于B2B的一些潜规则
对于C端产品，如果太丑或不好用，消费者可以拒绝使用。而B端产品即使学习成本比较高，但企业仍然可以“命令”所有员工学习这些用于开展业务的专用软件。
B2B产品最终将出售给业务决策者，然后再推给（最终）用户。他们更关心的是量化提升效率（efficiency）和安全性（security），同时预防错误（preventing errors）。大多数组织都在寻找一种解决方案来替代和/或优化现有流程。
这并不是说企业软件不应以用户友好为目标，但通常情况下，只要能够实现某些被企业视为至关重要的目标，其他能省则省。对底线（bottom line）的影响有时会成为最重要的因素。
全球各大企业的用户体验设计领导者仍在争夺一席之地，以证明优质设计的价值。不幸的是，许多企业的用户体验设计师只能在满足业务目标、技术要求和用户需求之间无奈徘徊。
像在大多数项目中一样，在企业领域里，如果可以证明更好的用户体验可以量化地提升生产率，比如可以节省金钱，这样你就有了一个绝佳的机会和挑战。
如果你在B2B领域工作，可能会很熟悉“鲸鱼用户（whales）”的概念。通常，他们是带给我们最多收入的客户，因此在某个特定产品的路线图中拥有极大的影响力。由于较少的鲸鱼用户简化了需求收集和确认过程，有时你的工作会非常顺畅，但不幸的是，这也可能导致你忽视掉很大一部分用户群体的意见。
我们见过诸多“被需要”的功能看起来并不适合大多数工作流程的案例（因为这是鲸鱼用户的特性）。通常，决策只是为了“去执行”，因为销售团队已经在下一个版本中承诺了这一点，而这个核心客户占产品收入的40％。这通常会使得产品对于其他用户而言就有些随机且不合逻辑了。
通常而言，在设计师进入管理层之前，他们很难影响到销售团队等强大的利益相关者的决策。潜在的利益冲突无疑是需要整个设计团队共同去面对的，大家需要平衡产品的长期愿景和立竿见影的“快速制胜”二者之间的冲突，以便为产品提供可拓展的设计和构建道路。
几乎所有财富500强的公司都是通过并购而成长为庞然大物的。
每一次的并购，都会将一个完全不同的系统和工作流程修补到现有的系统和工作流程中。很多开发于90年代的软件仍在诸多大型公司中运行。尽管从概念上看，“整合一切（consolidate everything）”似乎很容易，但是协调数据库和系统的过程着实很繁琐，且需要足够的时间。
B端用户体验的大部分工作是将用户从一套旧版（有时是手动）的工作流程中解放出来的艰巨工作。这涉及到对用户目标及多个系统的深入了解，需要我们列出规划，识别冗余和协同效应，然后将其与边缘案例相结合，以检验它产出的结果是否与当前操作模式的产出一致（如果不能优化的话）。
尽管过程并非总是如此艰难，B端软件依旧比C端复杂得多，因为即使其概念是“从0开始做新系统”，其数据还是全部来自于一堆与之配套的旧系统。在系统级别上思考流程、提出正确的问题并有效记录文档的能力是此类项目中最有用的技能。
我不是开发人员，所以我不知道我从Google里找的这张图片是否是能够准确展示典型的后端体系结构。
我所知道的是，对于每个项目来说，开发人员都会创建一个外观相似的图表，该图表展示了数据的来源和去向，它非常复杂，并且在提取，存储和推送数据时可能受到一系列限制。
大多数企业或组织需要遵循一套严格的政策法规，并且通常受到各种管理要求的约束。
常见的例子包括：法律/隐私要求（例如GDPR），国际化要求（例如日期格式，语言），无障碍（例如WCAG＆ARIA），安全性等等。
这些规则中的每一条都来自于某领域的专家、某类别的检查清单（checklist）抑或是一系列更为模糊情景下的最佳实践（这些实践基于特定的方案和用例）。C端APP监管日渐常规化，同时，由于诸多企业或组织掌握的敏感数据极具货币价值，其受到的监管和审查也在不断增加。
当然，这个问题的答案显而易见，你的确切问题是存在第三方解决方案的，但是由于某些规则或规定，你可能根本无法使用它。
由于必须满足很多这样或那样的标准，对于用户来说，最终的设计往往不太理想，虽然乍一看可能并不明显，但这也是历史上许多政府软件的设计看起来很蠢的原因之一。
与上面的观点类似，B端产品用户的独特之处在于他们对变化的抗拒心理。这意味着你需要认真思考工作流程改变后的结果，诸如使用不同的颜色，或是调整页面内某个按钮的位置等简单变化。
我们甚至还没有谈及信息架构。当你开始做信息架构时，卡片分类研究可能会告诉我们现有的导航设计是完全错误的，或是导航里的某些分类实际上应该嵌套到其他地方。不过你很快就会发现，当实际执行这些变化时，你将面临巨大压力。
知道何时依赖自己的研究和专业知识，何时推进，何时放慢步伐是很关键的，这样你才可以避免疏远过多的用户。毕竟对于这些用户来说，过去几年的工作流程已经根深蒂固，他们需要时间、资源和指导来学习或重新学习这些系统的使用。
尽管他们可能会拒绝改变，但这绝对不代表我们作为UX专业人士就无法引领他们拥抱变化，我们要做的便是了解他们的痛点并在设计时时刻考虑到用户的最大利益。
许多旧版的B端app产品都有一个共同点，那就是它们的信息密度非常高。
理想的解决方案也许是隐藏所有不必要的信息，仅显示刚需的信息，但是“隐藏掉错误内容”的风险可能非常巨大，以致于不得不将其保留在不断增加的的实体屏幕上。
这就容易导致打包的屏幕设计极大增加了用户的认知负担。而这些负担之所以被用户“接受”，就是因为他们必须且只能“学习”如何使用该软件来完成工作任务。
此外，对于许多管理或监控类的产品，用并别模式查看信息进行比较和参考是非常重要的。复杂的非线性（Complex non-linear）的工作流使得界面设计更具挑战性，因为许多选项都需要既可随时访问又不能妨碍其他操作。
有个很好的例子：为什么Bloomberg（上图）的UI看起来比Robinhood（下图）复杂1000倍？
结论便是，B端产品的界面里，需要牺牲留白空间以展示更多信息的情况并不少见，因为用户经常需要查看更多信息以便完成更复杂的任务。
随着公司或组织越来越依赖技术，B端产品的用户体验设计将成为许多公司的主要竞争优势。
如果你具有拥抱复杂性、平衡多个利益相关方观点，并在约束内进行创新的能力，你便能轻而易举的杀入B端软件设计领域。
随着机器学习等诸多振奋人心的新技术出现，各种业务会带着其庞大而杂乱的数据库排队等候。UX将站在如何产生有价值的见解的最前沿，以便弄清用户想要从这些数据中获取什么以及如何对其进行操作和访问。
虽然在很长一段时间里，dribbble（追波）上的精美视觉设计仍将占有一席之地，但更繁重的任务还会落在那些不起眼的B端设计师身上：比如设计电子表格、数据集、草图原型、投入调查以及数小时与用户和利益相关者的交谈和测试。
最终出现在用户面前的内容可能并不完全整洁和简单，但请你相信，在成为备受瞩目的明星B端产品前，其每一处基准点都经过了UX设计师的严格审查。我们的用户已经全力以赴地使用这些产品努力工作，我们的产品也通过清除一些障碍来减轻用户的负担，这已经很不错了。
翻译：April.H 审校：戴猫子 | UXRen翻译组 #366译文
作者：Yichen He
原文标题：《Designing for enterprise vs. designing for consumers》
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
在BAT、TMDJ等一线互联网企业，决策平台又称决策支持平台、管理会计平台。但实质都是实现业财一体化后，提取业务、财务数据，自动生成各种管理报表、财务报表，智能预警风险、预报业务前景，通过Dashboard或驾驶舱的形式展现给管理层、决策层，本文作者暂以管理会计平台展开讨论。
管理会计，从定义来看有狭义与广义之分。狭义的“管理会计”通常是指财务会计概念，包含“成本管理”和“管理控制系统”两部分。
而广义的“管理会计”则是指运用一系列的分析手段，通过挖掘财务数据、业务报告等中潜在信息，对企业财务状况、经营成果、现金流量和产品竞争力进行分析，辅助经营者进行决策，指出业务、财务风险隐患，预测未来趋势，赋能业务，以数据驱动企业发展。本次讨论的后者，即广义的管理会计。
管理会计目标的实现，不是简单的某一个系统或产品能承载的，需要设计一系列的产品矩阵，包括基础的核算系统如ERP、成本结算系统、预算系统、报表系统，这个矩阵就是管理会计平台（以下简称管会平台）。
管会平台的主体或用户的不同使得所产出的管理报表（以下简称管报）指标也有所不同。用户一般分为外部和内部2个大维度。
1）外部用户
投资人偏向于分析企业的盈利能力和资本保值增值能力，如净利润率、资本保值增值率等指标；债权人则侧重分析资产负债水平和偿债能力，如资产负债率、利息保障倍数、权益乘数等指标。
2）内部用户
应收会计岗则侧重应收账款的质量、收入的趋势，如应收账款周转率、收入环比或同比、速动比率等指标；资产会计岗偏向于分析资产的利用率、所带来的价值，如资产周转率等指标；而企业管理层或决策层会关注企业经营活动和财务活动的一切方面。
管会平台在设计时应考虑满足这些不同用户的需求，并通过权限、角色实现千人千面的效果，不同用户展示不同指标集和报表。
管理会计不仅属财务一个分支，更是财务在企业管理中应用的升华，财务的4个功能层次形象筑起管理会计的坚实基础：
做好管理会计，核算是基础，分析是关键，管控是抓手，赋能是核心。
分析不仅仅是传统的报表分析，而是基于大数据、机器学习、AI等高科技手段，自动化、准确、智能的实现风险预警、趋势预测，引领、驱动企业发展。
举个栗子：每月关账后财务都要做财务分析，收集各种业务、财务数据，结合相关指标，以发现业务中的问题。如做杜邦分析法，分析净资产收益率。
继而计算总资产净利率，权益乘数，销售净利率、总资产周转率……通过实际与预测的横向对比、基期与历史的纵向对比，找出各种指标异动原因，实质是分析企业的赢利能力、营运能力、偿债能力。
但这些通用的指标需结合企业实际情况、历史数据，并体系化形成产品，才能分析出症结点所在，这也是管理会计平台建设的意义与努力的方向。
如何搭建管理会计平台（以下简称管会平台）呢？互联网管理会计平台，其实并不是一个单一的平台，而是由众多关联子系统构成，通过多个子系统间协同合作完成管理会计目标的系统集。
从前端用户的视角来看，获取管理报表是一个很简单的动作：查询相关主体公司管理报表或分析结果即可，但从系统角度来说，管理会计的建设过程实际涉及了众多财务子系统的协同、及复杂的系统逻辑。
一个典型的财务产品架构如下图，涉及多个子系统。典型管理会计产品分为生产端与消费端，架构图如下：
在简要介绍各子系统功能前，可以先看以下简化版的管会平台产品架构图，典型的管会平台产品架构可以划分为四层结构：支撑层、数据层、核心层、应用层：
用来支持管会平台的基础服务和基础设施，包括容器云、安全服务、存储服务、消息引擎、任务高度、短信服务、证书服务等。
汇集业务、财务数据，以大数据或数据湖的形式承载基础数据，包括ETL、BI、大数据等。
管会平台的核心模块，分为清结算、财务中台、ERP、预算、管报中心五大块；
1）清结算
主要由计价、清分、结算、对账组成，是业务活动在财务的2个反映之一，解决互联网业态中的成本费用结算，与传统企业的成本计量方法不同的是，一般是按个别计价法对不同时间段可以阶段性、阶梯性等复杂业态成本计量。
2）财务中台
主要针对业务中非审批类的收入、资产折旧、摊销，自动对账、生成分录，并传递至ERP，主要包括：入账规则、数据校验、分录生成、主数据等。
3）预算模块
预算功能，包含预算编制、执行等，结合BPM审批流，实现费用控制。
4）ERP
财务核心入账平台，包括总账、应收、应付、资产、财报等。
5）管报中心
管会平台核心输出层，包括生产端和消费端2部分，生产端分为指标集、规则引擎、模板、预处理、智能诊断等模块。消费端主要是管报产出结果的展示即驾驶舱、手工确认或修正。
管报中心是核心中的核心，后面第三章会详细展开。
通过支撑层、数据层、核心层提供的服务组合起来，对最终用户、运营管理人员提供的系统。在产品架构层面体现为前端展示层、业务域和过程域。前端展示层主要是结果展示的形式，如PC端的web页面、移动端的APP或H5、小程序等。
业务域是上游的各业务系统，而过程域是管会平台所依赖的流程工具、特征数据，如供应商、ORG、BPM等。
管报中心由生产端和消费端组成：
生产端流程图如下：
【指标集】：配置各种指标，如“速动比率”、“产品成本费用率”等。一旦配置不得删除，只可修改或禁用。上游是科目与计算规则，但校验关系不在此模块。
【模板】：指标、预警或诊断信息的集合，可导入或手工增加。在预处理和结果展示时，将会调用此模板。
【规则引擎】：由“科目规则”、“计算规则”、“指标规则”、“预警规则”四部分组成。
在每一层指标中，有实际值、预测值，二者之间的偏离度，就是预警条件；“好”、“差”就是简单的信息模板，可把具体原因也纳入进来。
主因判定实质是一个由上到下的递归过程，如此例中，A公司获利能力（即资本报酬率）相对较差(3.08%<7.41%)，这是第1层判断。
再往第2层，经过分析可知这不是因为总资产净利润差(2.55%>2.37%)，而是财务融资能力差(1.21<3.21)。如此类推，直至分析至底层科目级指标。
【预处理】分为“重分类”、“平衡试算”、“定时任务”、“结果存储”四部分，是报表产出的运算过程。其中“平衡试算”属前置数据校验，检查数据是否达到报表可用程度。“定时任务”与“结果存储”属技术性过程，“重分类”根据会计要求设置，具体由财务确定。
【智能诊断】是对具体的报表进行分析，由“诊断开始（数据准备）”、“规则判断”、“预警判断”、“结果确认”四部分。其中结果确认包含结果展示、消息分发、手工修正等。“规则判断”与“预警判断”是对【规则引擎】中的“指标规则”、“预警规则”的具象应用，实际应用中可引入AI、TensorFlow(机器学习)等技术手段提升诊断的准确度。
在生产端准确、及时生产出数据后，消费端就不愁无米下锅了。一般通过Dashboard或驾驶舱展示，这一块通常需要BI或数仓部门的协助，效果图如下：
综合以上，管会平台的每个子系统并非孤立的，通过产品架构相互关联。产品架构与技术架构相辅相成，产品架构决定需求和设计，技术架构决定技术框架和性能。包括AI在智能诊断上的应用、数据域的实现等。
好的产品架构将这些不同用途的功能进行聚类整合，因此，【才听途说】建议将管会平台拆分成多个子系统，明确业务边界，减少系统间的耦合，提供优质、的管理决策支持服务。
并根据前端业务场景的需求随时进行调整变化以适应业务的发展，如规则引擎部分基本可由前端配置即可，减少后端开发与产品上线时间。
不同互联网公司，业务体量甚至有成千上万倍的差距，如京东集团内不同BU的体量及发展速度造就其系统复杂度也差异巨大，高度复杂的管会平台甚至需要数百人的技术团队来设计、开发、维护。
不过，对于体量较小的互联网公司来说，几人的团队即可搭建一套系统并维护日常运营。
互联网企业作为金融科技业界引领者，建议在系统开发前期（从0到1），以MVP形式，小步快跑，快速迭代，尽快上线、降低开发成本，优先开发主要需求、及较重要的子系统，或并行实施几个子系统，如ERP的实施、清结算的开发、管报中心的开发可以并行。再做次优级子系统，逐步迭代。
随着订单量的提升及业务复杂度的增加，不同BU甚至不同BGBU的接入，管会平台复杂度将指数及上升，系统处理起来会越来越吃力，若无良好的规划，各子系统耦合度越来越高，杂糅在一起，系统灵活性越来越差，无法跟上业务的发展。
因此，管会平台的中长期发展（从1到100、到∞），极其考验我们的业务梳理能力，及对业务进行拆分、产品架构的能力。
特别是目前行业内还没有体系化的管会平台建设经验可参考时，更考验我们的综合能力，包括财务专业知识、业务理解力、产品规划能力。
但万事不要怕，只要抓住产品设计精髓，即设计的产品应满足逻辑完整、业务功能明确、可扩展（发展方向明确但业务边界清晰）、灵活（非耦合）等特点，一切将会迎刃而解。
蓝蓝设计的小编 http://www.lanlanwork.com
