本篇文章将分享 Web 端系统布局，从基本布局初识、网格、布局模块到栅格进行完整链路内容整合，以简单易懂的案例与大家进行探讨。

在以往的学习过程中，我发现市面上大部分文章对于 Web 端系统布局内容讲的比较笼统，一般提及较多的是网页栅格相关的内容，但是一些关联性和原子结构等相关内容较少。比如，了解布局时应该需要了解哪些方法论？什么是网格？网格与栅格之间是什么关系？栅格与布局之间是什么关系等。我会从这些缺失出发，结合工作经验与实际案例为大家进行分享。

用户在操作系统时所看到的页面框架其实就是系统布局，它是一个产品最外层的框架结构，一般包含了顶部导航、侧边导航栏、面包屑、图文、卡片、内容等元素。

对于设计师而言，想要了解一个中台，首先要了解它的系统布局，系统布局是页面设计的基础，它与页面的关系，就如同建筑与地基的关系。日常完成需求时，UI 界面反复的调试页面宽度与卡片比例会占用我们大量的时间。为了提高工作效率，并且把更多的时间放在业务、视觉创新等方面，我们就应该需要一套完整的布局规范。

对整个公司产品体系而言，内部员工与普通用户使用的操作系统达到几十甚至上百个，单一的页面布局满足不了各个子项目的使用场景。所以我们从前期的布局框架设计调研到产品业务的特性，定义了中台界面的几大类型，并且在我们的设计规范中定义了几大类型系统布局方式，根据其布局方式定制好栅格，方便日后在各个业务场景中使用，从而能够保持一致性、并且可扩展，方便快速迭代和维护。

了解布局

1. 布局方法论

视觉层次

对于中台的 UI 设计师们而言，良好的理性思维相对比感性的视觉思维更加重要，因为在 UI 设计师设计页面时需要把很多互不相关的元素有秩序的组织在一起，正确引导用户操作与使用。亨利·亚当斯（Henry Adams）曾经说过：「混沌是自然法则，秩序是人类的梦想」。人们总是喜欢秩序，因为秩序可以让事情变得更容易理解。这同样适用于数字产品的用户界面，当 UI 元素被有序组合和结构化时，人们可以轻松的使用应用程序和网站，并对产品感到满意，所以设计页面时需要结合视觉层次理论。视觉层次理论是设计过程的核心方法之一。最初是建立在格式塔原理的基础上，它观察到了用户对相互关联元素的视觉感知，并展示了人们如何将视觉元素归为一类。那么什么是视觉层次呢？官方概括：视觉层次结构致力于一种用户能够理解的方式呈现产品的内容，以便用户可以理解每个元素的重要性级别。它可以组织页面内容，以便大脑可以根据物理差异例如：大小，颜色，对比度，样式等区分对象。

苹果的设计一直以来都是引领着设计趋势，其设计被国内外用户所认可，所以就以苹果官网作为案例。其中，字重对比：苹果官网在字重上给人眼前一亮的感觉，它采用 Medium+Bold 的字重使得标题与详情内容产生强烈的大小对比，用户进入官网的第一眼便能了解核心内容。颜色对比：在颜色上使用黑色背景承托产品和内容，强烈的黑白对比增强了信息传播中的识别度和对比度。图文排版：在图片与文字排版中使用了文字层和图片层互相叠加的视觉效果，使得页面层次感更加的丰富。如下图：

格式塔理论

往往用户打开页面进行阅读或者操作界面时视觉的第一感受是产品的整体效果，而并不会感知到一些较细节的元素。往宏观来讲当人们感知到一个物体由许多元素组成的复杂对象时，人们会采用有意识或无意识的方法将这些部分安排到整个组织的系统中，而不只是简单的元素级。它适用于不同级别的感知，但是视觉部分似乎是设计师设计界面时最能体现价值的部分，这其实就是格式塔理论，格式塔（Gestalt）这个术语来自德语单词 Gestalt，中文翻译为「形状，形式」。

格式塔心理学家库尔特·科夫卡（Kurt Koffka）的一句话可以捕捉到这一运动背后的基本思想：「整体不是元素基因的总和」。官网概括：「在心理现象中，人们对客观对象的感受源于整体关系而非具体元素，也就是说知觉不是感觉元素的总和，而是一个统一的整体，部分之和不等于整体，因此整体不能分割」。格式塔理论中元素之知见的原则分别为临近，相似，连续，封闭和连接。

在我们的现实生活中有很多自然规律都遵守了格式塔原则，比如说每到秋天，北方的严寒气候不再适合大雁生存，这时候大雁便会飞往较暖和的南方，当人们看到天空正在南飞的大雁队伍，它们组织链接得十分严密，并且群体在往同一个方向移动，所以队伍的形状在我们的大脑中将它们视为一个群组的一部分，产生人字形或一字形的图形。

信息框架

刚刚我们也介绍了视觉层级结构和格式塔理论，接下来简单介绍一下信息框架，它也是在系统布局中需要考虑的内容。信息框架是将信息内容进行组织分层，一个产品的信息框架取决于其特有的业务，他与业务强相关并且需要了解用户群体目标。根据业务和用户目标将内容组织搭建信息框架，形成系统布局的骨架，方便用户在浏览或操作页面时能够快速找到重点内容，提升用户使用效率。我们用今日头条 Web 端和飞书 Web 端两个线上产品作为案例分析吧，今日头条和飞书属于两种完全不同类型的产品，那么其信息架构也完全不同。

今日头条属于门户类新闻客户端，主要是生产内容展现给用户，首先进入到产品映入眼帘的是无穷式的信息流，它不需要用户登录/注册作为身份门槛，而是直观的把内容展示给用户，推送用户感兴趣的内容，也不需要用户决策任何选择，用户只需沉浸式的阅读体验即可，目的是方便第一时间抓取用户、吸引用户达到留住用户的目的。当用户产生兴趣以后想要进入下一步操作如：点赞、评论时才会弹出登录/注册，一方面是获取用户的身份等信息，另一方面是间接性的把用户留下来。从产品业务属性来看，今日头条的布局把重要的内容放入中间，并且占有整个布局的一半大小，其次放在内容两侧；

飞书属于工具协作类产品，用户第一次打开产品需要注册才能使用。与新闻阅读类产品不同的是工具类型产品用户目的比较明确，所以首页做成一个功能介绍页面，作用是引导用户了解产品核心功能从而转化成产品的用户。当然功能介绍页也是一个网站的门面，首页想要出彩，不仅需要在布局上做的合理还需要考虑网站的色彩、插图等元素的统一性。在设计网站时，首页的功能介绍页一定要充分突出自身产品特色，强调出自身产品的优势和亮点，如飞书首页主要是想突出其产品能够提高工作效率，所以直接把「在飞书，享」slogan 这句话放在了首页的第一屏，辅助文案详细的介绍了产品的核心功能，直接抓住用户的痛点。用户完成注册以后，进入到功能页面，如右下图可以看出，其系统布局的模块分成三份，占面积最大的模块属于产品最核心的部分也就是聊天窗口，较重要部分是联系人部分，最小区域是功能 Tab 部分。

小结

所以对于设计师而言，在设计页面时必须熟练掌握一些基本设计基础知识，并且将这些知识灵活运用到实际的工作当中。比如设计师在搭建系统布局时需要熟知页面视觉层次、格式塔理论、信息框架等知识才可创建合理的布局基础。当然布局框架只是整个产品的基础骨架，在骨架确定之后，设计师才可进行下一步的设计，如统一的视觉表达元素，清晰的功能操作，流畅的交互表达。

2. 布局的设计原则

系统布局规范，需要通过统一的设计元素和间距规范去引导使用者们（使用规范的设计师）跨平台使用并且能够适配不同屏幕尺寸，目的是达到一致性，可适配、可控性原则。

一致性：对于界面来讲，界面中的元素和结构需要保持一致性，如：在使用布局时应当使用一致的网格，基准线和填充，在使用设计元素时配色、图标、文本等需保持一致。

可适配：布局是可自适应的，根据用户在不同的设计环境下能够通过交互动效、界面样式有效作出适配反应。用户操作后需给出即时反应。

可控性：当用户看到界面时应直观有效传递内容，如界面中模块区域明确、内容组织明确、表意明确都能使得用户快速理解。界面需要简单直白，让用户快速识别，减少用户记忆负担。

3. 适配方案

在设计过程中，为了减少设计师们的日常沟通和理解成本，在设计内部我们统一了一套设计画板尺寸为 1280。经过我们官方调研得出在中台系统中用户使用的电脑屏幕主流分辨率分别为：1440*900、1366*768、1920*1080、1280*800，而1280 是主流分辨率中最小且最为保险的的一个尺寸，在设计页面时设计师如果能够在 1280 尺寸下，缩小宽度或拉升页面宽度都能保证没有遮挡或挤压问题，那么设计是合理的。在我们的规范中页面再小于 1280 时需要吊起系统的横向滚动条。在中台系统中考虑到用户效率问题很少做响应式，所以常规情况下设计师会限定界面的一个最小值。如果设计师把画板设置为 1440 或者 1366 时可能会存在其在画板中页面大小正好合适，但是页面上线以后缩小浏览器可能会发生遮挡或挤压的情况。所以我们建议设计师们使用 1280 宽度画板画图。

4. 框架

首先先分析一下界面框架，我们将页面的用户操作行为进行层级区分。我们至下而上将元素进行层级分层，目的是把用户界面模块化。界面可分成背景区域、内容层、全局控制层、内容弹层，每一层都具备独特性，将界面中所有的信息层级提取分类并且按结构属性分层，目的是能够使得页面视觉和交互逻辑符合用户的习惯认知。之前我们有提到过视觉层次、格式塔理论和信息框架，设计师在创建这一步的时候可以用来指导搭建一套合理的页面信息层级，一个内容模块都属于一个容器，容器可以承载各种内容元素。

背景层

背景层样式固定，在界面中永远置于界面底部，并且一般会给予背景层中性色，作用是方便突出内容层和全局控制层。

内容层

视图结构中最核心和复杂的一层，他与业务强相关，内容层的容器承载了业务场景的用户需要获取的核心信息以及辅助核心任务的操作。容器承载了内容，从 Material Design 中的 Elevation（海拔）概念中可以了解到，它属于第二层级内容，基本布局结构有平行结构或者父子结构。如下图卡片属于容器，卡片中承载了数据图表等内容，整个卡片+内容就属于内容层。

全局控制层

全局控制层我们定义他在内容层之上，属于页面第三层级内容，一般在业务场景中对整个网站的控制以及导航功能如：Header menu、Sidebar menu 组件，如下图中 Header menu 浮在内容层之上。

内容弹层

当前任务或者内容相关的临时出现层，优先级高于内容层，一般承载当前需要临时处理的任务或者需要进行内容补充说明等功能。如：Modal（Dialog 各个平台叫法不一致）、Tooltip、Popover、Notification 等组件 。其中 Modal 是以滑出或者弹出的形式展现给用户。Modal 它包括两种类型，一种是模态内容层不可操控，被蒙版遮罩禁用，比如在业务中需要较为聚焦的分支流程操作时使用。另一种是非模态，吊起弹出层后不印象内容层操作。当然，Tooltip、Popover、Notification 都属于非模态，反馈较轻，不干扰用户使用界面。如下图的页面中的内容弹层使用了 Popover，在次页面它的功能就是加以补充说明。

网格基础

1. 单位

随着科技高速发展，屏幕分辨率也越来越多样化对于 UI/UX 设计师来讲必须熟练的基本知识方便日常工作所需。首先我们先了解一下屏幕中的一些单位。

• 「PX」pixel，像素，大多数电子设备成像的基本单元，同样尺寸的屏幕成像单元越细小、越密集的屏幕，分辨率就越高；
• 「PT」point，点，这个单位，就同时出现在 iOS、CSS、还有传统的平面设计里，与 px 相比 px 是相对单位而 pt 绝对单位，如在设计稿中如果导出一倍图 1px=1pt 那么导出二倍图就是 2px=1pt，它是一个绝对长度，为1/72英寸；
• 「PPI」pixel per inch，每英寸像素数，决定电子设备的物理显示尺寸，只有涉及到显示才有意义。该值越高，则屏幕越细腻；
• 「DPI」dot per inch，与PPI一致，唯一区别是它表示每英寸多少点，该值越高，则图片越细腻；
• 「DP」density-independent pixel，是安卓开发用的长度单位，1dp等于屏幕像素密度为 160ppi 时 1px 的长度，因此dp 在整个系统大小中是固定的。
• 「SP」scale-independent pixel，安卓开发用的字体大小单位，可以认为 SP=DP。

2. 像素密度

在高密度屏幕下每英寸具有比低密度屏幕更多的像素，可能导致开发实现稿的视觉不符合设计师心理预期，比如：相同像素尺寸的 UI 元素在低密度屏幕上显得较模糊，而在高密度屏幕上则比较清楚。同一物理尺寸（肉眼所见尺寸）下，低密度显示器的像素个数明显小于高密度显示器的像素个数。

其实像素是与密度没有关联，我们简称密度为 DP (读作 DIP，英文全称 Density-independent pixel )，它是可缩放的灵活单位，可在任何屏幕下现实相同的尺寸，如图显示，红色网格为像素密度，被放大内容为 UI 元素物理尺寸。

所以我们可以得出，DP 可以自适应屏幕的密度，不管屏幕密度怎么变化，实际显示的物理尺寸相同，DP 可以保证物理尺寸的一致性，所以 DP 是目前比较适合 UI 设计的单位。当屏幕的密度为 160 的一个物理像素时，1PD=1PX。要计算屏幕密度，可以使用以下公式得出：DP=(PX*160)/PPI。

3. 网格

关于网格

网格线(Grid Line)，网格线又称布局分割线，它是构成网格结构的分界线。一般在布局中它们是由行网格线和列网格线组成。如下图是模拟网格做了一个示意，其中橘黄色两根线分别是行网格线和列网格线。

网格轨道(Grid Track)，两个相邻网格线之间的空间。你可以把它们想像成网格的行或列。如下图橘黄色的行网格线和列网格线之间的空间既是网格轨道。

网格单元格(Grid Cell)，两个相邻的行网格线和两个相邻的列网格线之间的空间属于网格单元格。这是网格系统的一个「单元」。如下图橘黄色的行网格线和列网格线交叉处即是网格单元格。

网格区域(Grid Area)，由单个或多个网格单元格组成，它是可以用来摆放页面元素。如下图所示，橘黄色的行网格线和列网格线交叉处即是网格区域。

网格设置

在设计界面时可以通过网格定制能够使界面更加有序、整齐、规范，网格的主要用途之一是保持设计元素对齐和排序。通过建立一个网格系统，设计师可以为自己创建一个结构来适配不同的屏幕宽度。

在我制定的规范中一般会把网格的基数设置为 4，它不仅符合偶数的思路同时也能够匹配多数主流的显示设备，如中台系统的用户主流分辨率用 1440*900、1366*768、1280*800。我们可以通过设置网格规范帮助设计师快速搭建页面，使用有律可循的布局空间的设计给到开发减少沟通成本。下图所示设计布局网格由三个元素组成：列宽，间距，边距。

在 Sketch 中设置网格，在菜单栏中找「视图」-「画布」-「网格设置」-弹出浮层可设置网格大小，网格设置的基数设置成4，之后在设计界面时可按照网格基础的倍数作为组件的大小和页面元素间距分割，如下图：

我们放大页面局部大家可以看到，把网格基数设置成 4，每个网格单元格为 4*4 大小。同理，如果把网格基数设置成 8 以后，每个网格单元格大小为 8*8 大小。

定义布局模块

界面框架内系统布局是页面所有模块的组合方式，我们定义一个页面框架中基础模块和内容模块的数量最好不超过 3 个。经过调研和归纳总结出 3 大布局类型，分别是上下布局、左右布局、T 字型布局。

1. 上下布局

上下布局布局是 Web 端运用最广泛的布局方式之一，页面内容区以 feed 流形式展现，一般用在 Web 端官网首页。设计师普遍做法是对两边留白区域为内容区并进行最小值的定义，一般定义值为 1200 较多（具体宽度要设计师如何设置栅格，后面会讲到如何设置栅格），当留白区域到达极小超过极限值之后需要对中间的内容区域进行动态缩放或遮挡，此逻辑需设计师根据业务所需而定。也有少部分设计师会设计成全屏布局，内容随浏览器宽度自适应。

其优点是页面结构清晰简单，强突出内容区，但缺点是布局的规矩呆板，变化少。设计师如果不注意合理的视觉元素和色彩细节变化，用户很容易感觉到乏味，此布局适用于层级较为简单页面。

巨量引擎（Ocean Engine）是字节跳动旗下的营销服务品牌，整合了今日头条、抖音短视频、火山小视频、西瓜视频、懂车帝、Faceu 激萌、轻颜、穿山甲等产品的营销能力，为全球广告主提供综合的数字营销解决方案。我在设计此官网时正是采用了上下布局作为页面布局，顶部导航整合了所有子页面的内容，导航下方为主要内容区并且内容定宽，当时采用此布局原因第一是因为次官网层级较简单只有三个层级内容，第二是官网更需要的是突出内容区，所有页面使用次布局更为合适。

2. 左右布局

设计师在设计重内容，轻导航类型网站是常用左右布局作为基础框架进行页面设计。此布局把系统页面分为两大模块，其中设计师常见的做法是将左侧设置成导航栏模块并且固定，常常用来控制全局内容。而右侧区域设置成工作区域或内容区，内容区可进行动态缩放。

下图为飞书沟通窗口截图，由于关系到内部信息保密性我把内容进行了模糊，从外观结构上看还是能大致了解飞书结构是采用了左右布局，整个布局结构清晰有理也是符合左右布局特点。从交互体验分析左侧属于导航区，它承载了不同功能并且固定。飞书属于即时沟通产品设计师考虑到浏览器窗口有限所以对导航设计成较小模块，而右边为聊天窗口对于业务属性分析它更为重要，所以模块较大。其导航栏固定，内容区可进行动态缩放。

3. T字型布局

T 字型布局常用在 Web 端的中台系统中，因为中台系统业务结构复杂、层级多，而 T 字型布局能够解决复杂结构的问题。使用此结构能够把页面结构清晰化，主次更加分明。设计师常常的做法是将顶部作为一级导航栏方便控制全局，二左边设计成是二级导航并且固定导航栏固定，右边的内区域可进行动态缩放（一般会把其设计成栅格动态区域），内容随浏览器宽度自适应。

下图是 Material Design 设计文档，首先简单介绍一下 Material Design，它是由谷歌的设计团队创建的一种语言，宗旨是帮助设计师们创建易用性和实用性较强的网站和应用程序，其设计理念是将现实中的物理学带入进设计中。Material Design 设计文档中的结构使用了 T 字型布局作为基础布局。页面分为了三个模块，其中顶部导航作为页面一级内容进行全局控制，接下来左边为侧边导航作为二级内容控制页面，右边是内容区满足用户使用浏览。从放眼望去整个页面架构清晰明了。

4. 小结

以上为 Web 最常见的三大布局，但是需要大家在实际的工作中灵活运用。设计师在日常工作中可能会遇到更为特殊的业务场景，设计师可以通过整理基础模块然后分析其业务的信息框架，将模块进行相互组合、嵌套归纳可以总结出更多的 Web端布局框架并落地到业务中。

网页栅格

刚刚在定义布局模块中已经分析过了三大布局类型，接下要分享的是 UI 设计师更为关注内容「网页栅格」。网页栅格也是设计师口中常常提及的栅格系统。其实网页栅格系统是从平面栅格系统中发展而来，它延续了平面设计的方法与风格，在网页中使用栅格能够使得网页信息展现更加清晰明了、美观易读。

首先网页栅格系统基本由是栅格总宽度/页面总宽度（W）、一个栅格的宽度（a）、栅格与栅格之间的间隙（i）、一个单元的宽度（A）、外边距（M）组成。

1. 列宽

一个栅格的宽度（a），我们称之为列宽，一个列宽包涵了N个网格单元格（Grid Cell）我们也可以把它看成一个网格区域(Grid Area)，在上面我们已经讲到过网格的内容，主要目的正是为栅格做铺垫。其中我把一个网格单元格设置为4（原因在网格中也解释过，如果忘记的同学可以爬楼看下）。由此可见列宽非固定值，这样可以使内容自由适配任何屏幕尺寸。在栅格中列宽由屏幕尺寸决定。

2. 水槽

栅格与栅格之间的间隙（i），我们称之为水槽，一个水槽宽度大于等于1个网格单元（Grid Cell）。在栅格中水槽为一个定值，宽度可以是N个网格单元，如网格单元格设置成4，那么水槽可以是4、8、12、16…N*4。

3. 栅格单元

1个列宽+1个水槽宽度即一个单元的宽度，一个栅格总宽是由N个栅格单元组成，次宽度不固定，由屏幕尺寸决定。

4. 栅格总宽

列宽+水槽再成以N即是一个栅格的总宽，公式为：W=(A*n)-i。

5. 栅格设置

经过调研我们得出常见的栅格分为 12 列栅格系统和 24 列栅格系统。其中 12 列栅格系统在流行的前端开发开源工具库Bootstrap 与 Foundation 中广泛使用，适用于业务信息分组较少、业务结构较简，单个盒子内信息体积较大的中后台页面设计。24 等分的栅格系统适用于业务信息量大、信息分组较多、单个盒子内信息体积较小的中后台页面设计；相对 12 栅格系统，24 栅格系统变化更加灵活，更适合内容比较多样复杂的场景。如下图分别是 12 栅格系统（左）和 24 栅格系统（右）。

6. 小结

在栅格系统结合布局结构和网格做了我做了一些知识结合，其实前面所讲的网格版块和布局版块都是为栅格做一个铺垫，利于同学们更加深入的了解网格、布局、栅格三者的关系。

写在最后

系统布局只是网页中的基础部分，但也是核心内容，一个产品布局需要根据其业务属性决定。布局搭的好相当地基打得好，但是同时在对美感的追求之上，还应当结合可用性来看待设计。在实际的工作中肯定还会遇到各种形形色色较奇葩的需求，所以希望这篇文章能够做的不是限制而是启发，大家可根据此次分享内容能够进行举一反三利用到实际的工作当中。

文章来源：优设

本文整理了人工智能行业中设计师需要理解的一些名词和内容。

一方面供自己学习思考，另一方面也希望能帮助到准备投入到人工智能行业的设计师。之前听有的朋友讲到，觉得自己没有计算机背景，有点害怕进入到这样一个领域来。

没有计算机背景没有关系，只要对这个行业充满好奇，一个个的问题解决掉，在你眼前的迷雾都会散去的。

先简单举几个人工智能在生活中有在应用的例子：

像现在有的超市寄存物件，开箱时采用的人脸识别；像家里购置的智能音响，时不时还能跟它聊上几句；像接听到的银行电话（是的，对方可能是机器人噢）；像在淘宝上咨询的客服小蜜；像你手机里的虚拟助手….等等这些都是人工智能在生活中的应用。

人工智能在设计领域的应用也相当广泛，具体可以看这篇文章：

这几个例子是在生活中比较普遍能接触到的，实际人工智能应用的领域还在不断的扩大，我们甚至都无法想象到，未来的生活会是怎样的状态和场景。

在这家公司之前，我做过语音交互类的产品交互设计。当时在定义人与设备进行语音交互时，会是怎样的一个交互场景。从说唤醒词到发出指令，从收到反馈到继续对话。唤醒后等待的时间、结束的规则等等这些。

而现在，我大部分时间是在设计工具，如何让使用者能快速的创建出一个智能机器人。如何让机器人的创建者方便快捷的添加机器人的相关数据和创建出对话场景。

所以在进行这些工具的设计之前，有些名词概念，会需要设计师来了解一下，能让我们更好的理解人工智能的一些原理以及能够让设计师具象化到实际的设计中，甚至能基于此技术/原理来进行相关的创新或研究。

整理内容如下：（内容基于工作及自身理解，如有概念理解错误，欢迎指正）

下面尝试用较易理解方式来解释这些名词：

与机器人进行对话，首先就需要让机器人懂我们说的话，这其中，就需要来关注到自然语言处理，通过自然语言处理技术，能够实现我们与机器之间「无障碍」对话。

• 自然语言处理（NLP）：是人类与机器沟通的中介，需要靠它来理解、处理和运用自然语言
• 自然语言理解（NLU）：指的是机器的语言理解能力，将人类语言转化为机器可理解的内容
• 自然语言生成（NLG）：指的是机器通过一系列的分析处理后，把计算机数据转化生成为自然语言内容，让人类可理解

我把这三者关系画了张图示，我是以这样的方式理解的

从图中可进一步看出，NLU 和 NLG 是 NLP 的子集，而 NLP 是人与机器沟通中很重要的存在。

涉及到语音就会经常听到 ASR 和 TTS

语音识别（ASR）：将语音内容转为文字

如微信里面，当别人发的语音信息不方便外放收听时，可以转为文字查看

语音合成（TTS）：将文字内容转为语音

如现在很多的阅读软件，支持播放，有的就是利用 TTS，直接将文本内容转为语音播放出来。

我试着将上面提到的 NLP 和 ASR、TTS 组合起来，关系可以如下图所示

当我们说一句话的时候，机器知道我们表达的是什么吗？

意图（Intent）:一个人希望达到的目的，或者解释为想要做什么，他的动机是什么。

如：

• 我对天猫精灵音箱说「声音太小了」，那我的意图是什么？意图是「将音量调大」。
• 「看下明天上海飞北京的航班信息。」 直接意图：查航班信息，潜在意图：「买机票」？

槽位（Slot）：可以理解为系统要向用户收集的关键信息。

如：

「买张明天从上海到北京的机票」

上面这句话中，获取到意图（买机票）；提取关键信息 时间（明天）、地点（出发地：上海；到达地：北京）
这些关键的信息就是槽位，当系统获知到这些信息后，就能去执行下一步动作。

还可以这样理解，当我们去银行营业厅办理卡的时候，会填写一张表，表每个要填写的选项，就是一个个的槽位。槽位就是为你服务的人员要从你那收集的关键信息。

实体（Entity）：用户在语句中提到的具体信息

实体这词放在生活中，我们很容易理解，就是实实在在的物体，像桌子、电脑、熊猫等等这些都是实体。

但是在人机对话中，机器理解人的语句内容，会识别出语句中的实体信息（如：地点、人名、歌曲名等），然后进行标记。

那槽位和实体是不是讲的是一回事？只是不同的说法？

我之前有一度陷入这样的困惑中，但其实这两者还是有所区别的。比如，一个实体是数字，但是在语句中，数字将代表不同的含义。

如：

人：有没有10元的鲜花？ 机器人：玫瑰花10元一支 。

这句话中，实体number「10」，但这个 10 在句子中表达的是价格，所以收集到的槽位信息是价格：「10元」

这样说可能还是不太能理解，那我们可以先了解下，在一句表达中，需要进行槽位信息收集，但机器如何知道「买张明天从上海到北京的机票」中，「上海」是城市，并且「上海」是出发地呢？

「上海」这个词会被建立在一个城市实体词库中，这是「上海」能被识别到是「城市」的原因。

其次，通过将解析槽位加入语料中，加以训练让机器学习相关表述结构，来获知该句式中，收集到的第一个城市是出发地，于是把第一个城市填到对应的槽位中。

使用什么工具来让机器知道，这个信息是要提取的信息？

解析器（Parser）：抽取/解析用户语句中的关键信息

上一个讲到实体，这里讲到的解析器则是这么个工具，用来抽取这些信息。比如会有些通用的解析器如时间解析器、城市解析器、歌手解析器等等。

解析器的类型也比较多，如通用解析器、词典解析器、正则解析器、组合解析器等等，这里就不再扩展开讲具体解析器，实在过于复杂了。

命名实体识别（NER）：用来识别具有特定意义的实体。主要会包括像机构、地名、组织等。

是不是发现，解析器和 NER 在做差不多的事情？我是这样理解的，解析器的话是一个更大的存在，其中包括了 NER。解析器下会有不同类型和不同功能的工具来实现关键信息的识别/抽取。

在我们与机器人对话时，一般会涉及到四个不同类型的对话，开放域的聊天、任务驱动的对话、问答（FAQ）和推荐。

上面是在有次分享中提到的，这四个不同类型的对话，在机器人平台中，会需要借助不同的功能模块来实现。

任务对话（Task Dialogue ）：有上下文联系，就像我们要去订票、订餐之类的一段任务型的对话。

我们公司产品中，任务引擎模块就是做这个任务对话的创建，比如，要订机票的场景。用户在这个订机票的场景中，会涉及到的对话内容、流程的设计。

知识图谱（Knowledge Graph）：这个可以理解为可视化关联信息。
比如：查询一个明星的身高、年龄，他的学校、他的女友，他的相关作品，这些基于这个人而构建的信息库，都可以通过知识图谱在做整理。并且在构建时能够做到可视化的了解。

要让机器人知道，它脑子里有货了！

训练（Train）：这个概念可以这样理解，比如你创建了个机器人，但是它什么都还不懂，于是你塞了堆知识给他，这时，它就需要自己训练学习了。训练好了，就能回答你塞的那堆知识里的问题了。

讲到这就忍不住想用这个学习的例子，来简单讲下一般机器人的创建流程。像我们在学校，会经历上课学习新知识-复习温习-考试-整理错题集，以此循环进行。

这个创建机器人的流程也是一样通过知识的导入/创建-训练-测试-优化-上线-优化，以此循环，不断强化机器人，让它越来越智能。

其他：

数据标注：将对话日志中的有价值数据做标注（标记/匹配/关联之类）。

因为人的表达万千，多种表达方式都代表的同一个意思。有时用户说了句话，是语料库中并不包含，于是机器人可能就答非所问了。

Ai 训练师们就可以将这些数据信息标注到对应的问题中去，这样当用户再用同样方式表述时，机器人就能如预期回答了。

讲到标注想到之前在朋友圈很火的你画我猜，谷歌推出的这个小游戏席卷朋友圈。他们用了个如此聪明的做法，其实我们参与其中的做法就是在做数据标注，而且还是主动提供数据的那种。

这也反映了，数据对于机器人的重要性，通过不断的进行数据维护和补充数据，机器人就会越来越理解人，表达也会越来越智能。就跟我们学习一样，不断学习才能够理解其他的含义，甚至当认知能力提升了，看待问题的角度才能不一样。

文章来源：优设

B 端工作看起来总是没有 C 端工作那么有趣，面临的限制比较多，面对客户（金主爸爸），很多时候总是左右为难。在实际工作中，面对这些情况该怎么办？笔者根据自己的 B 端工作经验，总结了一些交互设计的要点。

从事 B 端 SaaS 行业已经两年有余，从最开始面对需求的茫然无措，到现在已经有了自己的一些基本方法论，这期间经历了从有人带到自己摸索的一个阶段。

每天看看文章、看看书，大家讲的都是 C 端的产品，C 端的交互和体验；每天看同行们分析的不是如何提高用户活跃量，就是 APP 的设计风格。这在我一个 B 端交互看来，无比羡慕啊。

C 端项目的设计师感觉每天和一线用户打交道，忙得不亦乐乎，可以与用户直接对接，可以添加有趣生动的文案。

而对于一个做 SaaS 的 B 端来说，Boss 常说的话就是：

你这个颜色太鲜艳了。

我们是 B 端，你这种页面布局不合适吧。

这个文案太幼稚了，不适合我们产品的调性。

中规中矩就好，不要太跳。

整理了一堆的字段，画了无数的线框和流程图，却拿不出 C 端设计师才有的丰富多彩的作品集，

尽管如此，设计的原则是通用的，无论是尼尔森十大可用性原则，还是格式塔原理，在设计方案的落实上，都有着相同的方法论。

无意在此讨论 B 端和 C 端之间的差异，仅以此文章来总结下我自己的一些工作经验，如有错误，敬请指出。

从业务需求的对接，到界面交互的细节，从功能的设计要点，再到产品的发展导向，我总结出了以下几个方面，逐步展开：

• 提炼需求
• 减少出错
• 提率
• 提高通用性
• 中正原则

提炼需求

C 端设计师最开心的可能就是收到用户的反馈需求了吧，这样表示自己的产品还有人在用，然后建个群让用户开开心心吐槽，完了就从里面提炼适合产品的一些需求和建议。

而对于 B 端设计师来说，如何处理需求是其成长的第一关，尤其是 SaaS 行业，不会处理需求，产品的功能更新将会遇到极大的问题。

B 端的用户不像 C 端，虽然可以用用户画像来进行归类和分析。但是由于 B 端的直接用户是付费用户，付了钱的就是大爷，因此大爷提的需求你敢不应？

用户提的需求乱七八糟，有些是体验问题，有些是功能问题，有些就是属于比较极端的需求。那种传说中甲方要你做一个可以根据手机屏显示颜色而改变手机壳颜色的需求，在 B 端行业也是存在的。

那么问题来了，我们该如何处理纷繁杂乱的需求呢，我从收集需求-评估需求-需求落地挨个讲起：

1. 收集需求

如果你也打算像 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

当提供方向性需求的功能时，会招致大部分用户满意度的大幅下降。比如常见的在搜索中掺加广告、强制用户授权过多个人信息以及推送大量无用的消息等，会导致用户的反感。

2. 评估需求

通常需求的收集不是你一个人在进行，产品经理、老板以及其他同事也会帮助你收集，汇总到你这里的需求会开会进行讨论，下一步要做什么。

做之前首先要对需求进行评估，评估的原则基本是按照 KANO 模型来，但是也会有比较特殊的情况。

交互设计师需要注意的是，你除了需要关注用户体验的问题以外，还要与开发一起评估该需求的实现；你不懂技术没关系，开发会告诉你该需求的落地会出现什么问题，在实现上会有什么难度。这些在评估需求的阶段都要提出来，并且在交互层面解决掉，否则你画出了原型以后，开发告诉你这个页面必须要修改，否则开发成本过大，无法在排期内完成，这个时候你再去改交互稿将会费时费力。

评估完需求，定好下期开发的需求后就结束了么？

其实并没有，因为需求收集不可能是一个固定的阶段，它是渐进的、不确定的。因此收集需求和评估需求会不断在实际工作中叠加和重复，比如你制定好了需求优先级，已经着手开发了；这时候老板或者领导突然又增加了一个优先级很高的需求，所以你得重新安排这些需求。如何在敏捷开发中保质保量的完成工作任务，这是一场斗智斗勇的 battle。

3. 需求落地

前面讲到需求评估的时候，需要与开发人员一起评估技术难度。其实在你将需求落地为交互原型的时候，也需要持续沟通，这完全是为了避免因为技术问题而产生修改设计稿或沟通不顺畅的问题。

如果你是在做的过程中，持续与开发人员保持沟通，能了解到他们是如何实现这个功能的。当然，有些基本的设计原则所不允许的事完全不用屈服于他们的「淫威」，毕竟他们得按照你的方案来。如果开发懒惰而想通过最简单的办法来实现，用户体验又是极其不友好，那么请直接对其说「NO」。

比如常见的删除的二次确认等弹窗，一般最好的体验是在按钮旁边弹出；但有些开发懒得写弹窗，直接调用浏览器的弹窗，即浏览器顶部经常出现的那种确认弹窗，这个时候你要坚决告诉开发，这样搞是坚决不行的。

需求的落地伴随着竞品分析，判断一个需求是否靠谱、落地方案是否成熟的一个重要途径就是竞品分析，可以通过调查研究相关竞品是如何进行设计的。这对于我们有着非常大的帮助，可以避免很多的弯路，甚至能避免犯错，提高交互方案的可靠性。竞品分析又是个比较繁杂的事项，如果是有特殊要求可以做成报告的形式，如果仅是去参考对照的话只需要去体验竞品即可。

减少出错

B 端的业务比较重要，尤其是涉及到数据的增删改查和金额的计算，一旦出错，将会导致无法挽回的后果。因此在出错前和出错后，应该有相应的挽回机制。

1. 出错前

内容编辑类的功能应该提供自动保存草稿功能，防止没有及时保存而丢失内容；删除、禁止等较重操作应该有二次确认，防止用户误删。

对于操作流程应该建立明确的引导机制，长表单可以分开按步骤填写。

提示信息应该明确而及时。比如一个表单需要登录才能填写，在未登录的状态下，应该先提示其登录再填写否则用户在填写大量信息后，因为一个错误而前功尽弃。

系统内的禁止信息、警告信息、提示信息建立一套相应的规则。

2. 出错后

• 应该建立回收站机制，删除后可以找回；
• 可对用户操作进行建立回撤机制，用户如果操作失误，可及时回撤；
• 对系统的操作进行记录，明确到时间、客户端、操作者信息、操作内容、操作的类型（增删改）等。

提率

用户的时间就是金钱，这对于 B 端商家角色中尤为重要，大量订单的处理、表格化的导入和导出、批量管理和网站运营等方面，对于效率有着极高的要求，商家通过可视化界面来完成某项任务。

在这其中，影响最大的莫过于交互方式了，相信各位一定用过各大银行的网站，页面的导航关联性弱、结构不合理、提示不明确、交互流程过长，甚至有的网站光是登录，就得大费周章。

如何提率，我认为主要从以下几个方面着手：

1. 提高易用性

如果你的产品，让人看一眼就能上手，那么说明是非常友好的设计。易用性不一定意味着简单和低智，依据复杂守恒定理（泰勒斯定理），每个应用程序都有自己内在的、无法简化的复杂度。

所以，提高易用性意味着要设计合理的交互，易用性分为对新手（小白用户）友好和对老用户（专家用户）友好，包括数量最大的中间用户。

如果你的界面是仅仅对于新手友好，那么可能完成的任务都是简单而轻松的。但是对于老用户，他需要更复杂的功能来处理大量庞杂的任务；因此在设计的时候，既要提供傻瓜式的操作方式，也要对专家用户提供提率的工具。

2. 智能化

此处的智能化既包括通过大数据或者人工智能自动将操作步骤变得简洁，也包括诸如一些字段输入、自动定位、图片识别、OCR 等方式来使用户的效率得以提升的功能。

以前的用户要抠图可能会在 ps 中操作好几个步骤才能完成，但是随着机器学习技术的发展，ps 已经可以更加智能的抠图。当然，还包括其他功能的智能化。

在 B 端 SaaS 领域，智能化也是一个重要的趋势，针对不同的商家所面临的不同的行业领域，我们或许可以提供更加全面且友好的服务。

3. 场景化思维

如果你深入了解你的用户，去观察他们整个行业的运作模式，以及他们对于业务的处理方式，你就会明白你的产品的走向。

你需要深入每一个场景，比如，在户外旅游领域，发布旅游产品线路的可能是在办公室中的编辑人员，带队出行的是在户外场景中的导游，现场签到的可能是集合点的管理人员，而处理订单的又是另一个坐在办公室里的小伙伴。

他们需要协同工作，才能使各项工作顺利展开，发布活动-用户报名-订单管理-报名人统计-活动成行-集合点签到-带队出发-旅游结束-活动评价-领队评价-交易成功，这一系列流程中，面临的角色是复杂的，而意外也是常有的事。比如报名人无法参加活动而导致的退款、活动因为天气原因而无法成行、户外活动发生意外等。

你需要做的就是：

• 站在办公室编辑人员的角度上，你需要为他提供兼容性很高的编辑器和快捷方便的发布流程，比如在系统内接入微信公众号的管理，可以将系统内的文章一键发布到微信公众号上，也可以通过系统推送产品信息。你需要为其设计友好的相册和视频管理工具以宣传旅游产品；
• 站在导游和管理人员的角度上，你需要为其设计在户外场景（移动场景）下也能使用的签到工具、临时退款工具、活动消息通知工具等；
• 站在订单管理员的角度上，你需要为其设计规范的导出表格格式，也需要为其设计修改报名人和订单信息的功能，有必要时，你还需要为其设计单独的报名渠道和特殊的付款方式（线下付款）。

场景化的思维会让你设身处地为一线操作用户的体验而努力。因此，交互稿完成以后，彻底回退到小白用户的身份，假装自己是在某个场景下要做某件事，通过你的交互方案，能否顺利完成自己的目标。

提高通用性

此处的通用性是指，在 SaaS 软件领域，不同客户所面临的行业有一定的差别，可能这个功能对于 A 用户极其重要，但对于 B 用户，该功能并不重要。比如有的客户想要在前台展示某活动的报名人的姓名以增加真实性，用以吸引用户参加；但是有的客户就明确反对该功能，认为这个功能侵犯了用户的隐私。

诸如此类的需求相离、甚至相反的情况太普遍了。合适的解决方式是建立两套开关，一套是由 SaaS 服务提供商的统一后台来配置，用以区分比较大的行业差别，比如电商领域中，可以配置店铺类型为：美妆、服饰、食品、电子产品等；另一套开关在客户的站点后台，用以控制不同的站之间的差别，比如前台界面样式、交易流程、相关字段或菜单的前台显示等。

另外比较重要的一点，也是最基本的一点，软件设计中存在一个原则就是高内聚低耦合，模块化设计，用以提高系统内部组件的复用。

交互设计也是同样的道理，可以将你的商品视为一个模块，那么这个模块无论是添加到网站，还是小程序，我只需要创建一个商品即可，可以同步更新到不同的平台。

另外，订单的管理只需要添加相关的标记即可（比如来自小程序的订单标记为小程序，淘宝订单标记为淘宝等），一个平台发布，多个平台同步，有效提高了运营人员的效率。

同样的，如果你的 pc 端产品和移动端产品没有实质性的运营差异（即当成两种模式来运营），那么很多数据（如文案、图片、banner等）的获取可以采用同一个数据源 。

最后，提高系统内的一致性，减少用户认知成本。在同一平台内的页面，样式和交互上要尽量保持一致性，不要有的地方是总金额，有的地方是总价格，这会让用户犯迷糊。提高通用性，也意味着你需要关注并熟悉系统内不同功能之间的关联性，尽量做到统一处理。

中正原则

在进行商业化运作和产品功能的优化时，对于正向的用户需要激励，对于负向的用户需要限制。

这是我在读完有赞的白鸦写的关于有赞产品设计原则的文章后，影响最深的一个原则，他写到：

我们的使命是帮助每一位重视产品和服务的商家成功。「每一位」和「商家成功」是我们最重要的关键词，我们要服务的是每一位商家，然后帮助每一位商家成功，但是为了整个生态的健康，那些不重视产品和服务的商家，我们是（可以）不服务的。所以我们在产品设计原则上，在产品做一些功能的选择上，如果这个功能做完了会导致商家不重视产品和服务，我们是不会/能做的。

举个例子：消费者购买之后（可以）有一个评价，我们的购物评价是要么开启要么不开启这个功能。我们不接受商家去删购物评价，因为商家一旦可以删了消费者的差评，他就（很可能）不会那么重视产品和服务了。所以有赞永远不会提供删除商品评价的功能，商家要么就不开启。可以不用，如果要用就要接受有人说你不好，商家可以去跟消费者沟通，沟通完了消费者自己改，但是我们不提供让商家删坏评价的功能。所以，这就是最基本的有赞产品设计原则，我们只服务重视产品和服务的商家，我们所有的产品设计原则都是需要这样。

——《白鸦内部培训：企业服务类产品的底层逻辑和有赞产品设计原则》

更多内容请看：

我将其概括为一个产品的中正原则，即中立且保持正向原则。

一方面，对于企业未来的发展而言，正向的用户能带给平台无尽的潜力，平台可以和商家一起成长，而负向的用户，则会给平台带来隐患。比如，淘宝既限制商家的违规运营和欺诈客户，也限制 C 端用户的恶意薅羊毛，在商家和用户之间做一个中立者和调节者的角色。

我在做需求的时候，也遇到过很多的负向需求，这在商家看来是一个必须的功能，作为平台应该提供。但是若是提供给商家，则会对消费者的利益造成损害，删除差评就是一个很好的例子。

看了白鸦对于有赞产品原则的阐释，我觉得每一个平台类的产品，都应该保持自己的中正原则：

• 拥有数据的公司不要倒卖用户的数据；
• 搜索公司不应该干扰搜索结果的公正性；
• 通讯公司应该尊重用户的隐私；
• 平台公司应该在商家和消费者之间做一个良好的服务者和调节者的中间角色。

在 B 端行业，口碑传播是非常重要的一种被动营销方式，很多 B 端公司都是低调的潜行者，坚持中正原则，并不会损害自己的利益，反而会获得商家的尊重和消费者的信赖。

总结

啰啰嗦嗦说了这么多，比较细碎，不乏逻辑凌乱的片段，但也算是对自己两年以来对于 B 端交互的一些心得吧。

其实交互的原则基本都是通用的，无非就是根据平台属性做一定的调整，不同的是产品所处的行业，每一个产品都无法脱离其所处的行业而存在，这也是使用产品的具体场景。

因此做一个产品前，一定要了解行业，去熟悉行业的通用做法，了解行业的专业术语和规范，研究行业的所属群体等，这样你就会做出真正适合市场且能让大多数用户满意的产品。

文章来源：优设

在网页和移动端界面中，内容和信息是否能够经过系统性、有效的整理和组织，对于内容的可用性和实用性，都是意义巨大的。而在呈现信息的时候，视觉间隔是组织信息的关键因素。它说起来并不难理解，但是在实际的运用当中，却是千变万化，今天我们来梳理一下流行的视觉间隔的方法。

什么是视觉间隔

视觉间隔是一种布局元素，它有助于将内容分隔成为清晰的分组、选项和部分。它可以让设计师更好地组织内容的视觉体验，处理信息的层级，也有助于用户理解内容，明白内容之间的关系。

视觉间隔和页面上的其他内容在一起，构成视觉层级，这是它最重要的作用。在视觉间隔的帮助之下，用户可以轻松地感知内容之间的关系，明白各个信息片段之间的关系是相似，并列，承袭，从属，还是其他。

视觉间隔的可用性也同样重要：在很多时候，有的视觉间隔元素看起来是可点击，可交互的，这在移动端界面上，是非常重要的。

视觉间隔的种类

谈到视觉间隔，我们可以从两方面来进行拆解分析：视觉间隔的外观和功能。按照视觉特征，视觉间隔有5种基本的类型：

• 线条
• 色彩
• 负空间
• 阴影/体积
• 图片

下面我们分别针对这5种类型进行说明。

线条

很长时间以来，在排版印刷领域，线条就一直是一种用来分隔内容的方法。线条的分隔功能是认可度最高的一种间隔方式，用户几乎不用思考，就能够理解和感知它，并且发挥作用。

另一方面，这种间隔方式也很容易显得过于简单，并且和应有的形态相去甚远。这也是为什么设计师在想尽办法去寻求别的视觉间隔形态。太多的线条间隔会让屏幕上的视觉干扰太多，并且带来不必要的视觉噪音。

所以，能够将线条间隔用得微妙、恰到好处、出神入化，是设计师功力的一个重要体现。

在这个网站产品页面中，使用深色的线条间隔来分割产品信息，用来组织和间隔信息内容。

在这个页面当中，线条分隔了不同的内容区块，让页面的结构更易于被扫读。

这个电商网站将不同级别的视觉内容进行了分离，借助简单的水平线将价格、CTA按钮以及承载相关信息的表单分隔到不同的区域。

负空间

负空间，也就是留白，也是最为常见的一种视觉分隔元素。留白绝不是对空间的浪费，和屏幕上其他的元素一样，它同样发挥着重要的作用，拱卫支撑着整个用户体验。负空间是最为流行的视觉分隔之一，尤其是在极简主义风格为主导的设计当中。负空间本身遵循着格式塔原理，尤其是其中「接近原理」和「相似原理」是负空间在设计中，发挥分隔作用的核心所在。合理地运用负空间，还能强化页面的呼吸感。

上面这款旅行规划 APP当中，使用留白将不同的条目分开，没有使用额外的具体视觉元素，仅仅只靠留白。

Health Blog 的列表的排版层次是基于负空间来实现的，看起来清晰又充满呼吸感。

色彩对比

高对比度的色彩，同样能够带来清晰的视觉间隔效果。在 UI 界面中高对比度的色彩有着极为明显视觉表现潜质，它们能够增强网站的信息和内容的表现力，分割区块，营造氛围。对比度是影响页面和屏幕可读性的关键因素之一。在具体的应用当中，不同的色彩会有效地分离不同的选项、条目和区域，这意味着它作为视觉分隔的作用非常强。这也是近年来分屏式设计如此流行的原因所在。

这是一套移动端菜单的概念设计，强烈的色彩对比让信息清晰可见。

即使是在这样的柔和的设计当中，色彩的对比度也发挥了相当的作用：一方面，强烈的色彩对比让CTA按钮和输入框之间有了明显的区分，另一方面，右侧的主视觉元素的背景也同样借由不同色彩的对比，做到了突出的效果。

在 GNO Blankets 这个网站当中，强烈的明暗对比将网站元素分隔成为精美而清晰的区块。

阴影和体积

阴影和体积也是一种非常常见的视觉间隔方式，通过营造在「高度」或者说高程上的视觉差异，从而达到分层的效果，而这种设计也是符合人类一直以来的认知习惯。这种方法有利于保持整个设计的平衡和易读性，另一方面，它又能保持足够的微妙和自然，不会那么引人瞩目从而让人觉得出戏或者受到干扰。

这个APP的目录页面所有元素都采用了白色的背景，而阴影让布局呈现出了纵深层次，让内容足以展现又不显突兀。

这款提供定制化花束服务的APP也采用了类似的阴影元素，让整体看起来清晰又通透。

图片

图片在 UI 界面当中，同样也是一种非常有效的视觉间隔，尤其是在包含大量文本内容的界面中。无论是博客、在线媒体网站还是其他类型的网站当中，图片的间隔作用都非常明显。无论是照片、插画、3D图形，它们作为图片都可以很好的平衡文本内容，提高内容的识别度和可读性，有效地划分层级，并且提高情感吸引力。

这个比特币网站的着陆页就使用了带有3D效果「了解更多」动态图片，图片和文本在内容和功能上都清晰地分隔开来。

在这个餐厅 APP 当中，图片作为划分内容的关键元素而存在。

按照功能划分

如果从功能的角度上来划分视觉间隔，可以根据它所处的层次来进行划分。

全出血间隔

使用线条作为全出血间隔是最为常见的，它会很跨整个屏幕布局来作为信息层级的划分。

这个画廊图库 APP 的艺术家目录当中，使用线条作为全出血间隔，来区分艺术家。

这个名为完美食谱的APP也使用了全出血间隔线来区分内容。

在这个财务APP当中，也使用了全出血间隔线来区分条目。

在这个电影APP的结帐页面当中，也使用了线条来作为全出血间隔。

嵌入式间隔

嵌入式间隔的功能是将相关性较高的内容分割开，并且它通常会和标题或者其他的特定元素保持对齐或者对应，它们通常是进行某个大区块内不同组件的分隔，或者将多个同类的元素分隔开。

这个网站当中，使用横向的短分隔线来区分表单中的参数条目。

中间分隔

这种分割线通常会置于布局的中间某处，同样是分隔相关的内容，但是通常它们在属性上不一定是一致的，但是层级近似。

在这个出售草药的电商网站的右侧，使用中间分隔线将文本和可交互的区域清晰地分隔开。

值得思考的问题

上面对于不同类型的视觉分隔方式都有描述，在此之外，还有两个问题需要注意：

• 保持微妙：视觉分隔不应该醒目、太过引人瞩目，它们不应该分散用户的注意力，它们应该支撑布局的同时，微妙而不那么抓人眼球。

• 中等频率：这和上一点是相辅相承的，过多的分隔线会变成视觉噪音，让用户浏览的时候感到疲倦。因此，应该仔细考虑使用频率，尽可能使用负空间，而不是线条。不要过度使用太多色彩，应该尽量保持整体的协调一致。

文章来源：站酷

日常工作中，经常听到交互和视觉同学有着如下对话：

• 视觉同学：「这个内容我想换个位置，可以吗？」「我可以用另外一种布局方式嘛？」…
• 交互同学：「你这里的表达有些歧义，用户容易误解，需要修改。」「这里层级关系不太对，应该更强调XX内容。」…

可以看到，无论交互还是视觉同学的提问，其实都是围绕「信息」表达的逻辑。视觉同学设计过程中，应该如何理解交互稿件，并进一步体现交互的层级逻辑？是否可以对交互稿的布局进行调整发挥？我们通过案例来一起看看。

目前，页面类设计一般分为运营型和平台型。

运营型

关注重点：「活动利益点」「模块内容顺序」「视觉发挥空间大」

活动页设计中，信息的层级表达相对简单，一般分为主氛围图-体现活动主题、内容展示区-直接转化、尾部兜底区-相关扩展。这类型需求，重点在理解交互稿中主题的表达、内容区的分类及重点元素体现。视觉设计师在该类型的设计中，发挥度是很大的。

平台型

关注重点：「层级结构」「浏览顺序」「视觉在信息逻辑之上发挥」

平台类设计项目，交互设计师通过页面框架、模块设计来表达产品/运营的策划思路，涉及内容及模块更多，且包含着复杂的逻辑关系。一个优秀的平台视觉设计师，应当是通过好的视觉表达，按照交互信息层级关系，将信息内容传递给用户。这里视觉同学要避免两个误区：完全按照交互框架和排布，只是纯粹填色；从「好看」的角度重新布局，忽略交互层级关系。

案例

下图是美妆频道的一次改版，通过观察交互稿和视觉稿可以看到，这位视觉设计师在交互稿的基础上，采用了更灵活的视觉引导方式。这些改变是否有效传递了交互逻辑？视觉阶段的这些调整是否都合适呢？看完本文，你就能有一个清晰的答案了。

1. 元素位置及表意

浏览顺序 元素表意

这是一个新品速递模块的设计方案。交互稿表达的信息是：这个区块是用来介绍新品的，首先希望用户知道模块属性是什么，然后让用户快速了解推荐商品是什么，及为什么值得买。视觉稿较好的传递了交互层级及信息表达，首先突出了栏目名称让用户能一眼看到，其次是商品及商品特性展示；而稿件中的栏目名称位置和样式则在视觉上做了自由的发挥。

小结：模块中各元素的浏览引导（眼睛浏览路径）需要严格按照交互逻辑，元素的表达和位置可以根据逻辑发挥。

2. 模块比重及样式

下面这组案例，在信息层级上，视觉稿是否完整传递了交互逻辑？先自己思考一下吧~

模块比重 内容布局

交互层级来看，整个区域有2个模块「正在进行」和「品牌精选」，每个模块有4个等大的展示单元格。而视觉稿中，「正在进行」模块的单元格变成了两大两小。严格来说，这个调整是不符合交互逻辑的。

但是，视觉稿的输出效果明显更灵活，浏览层次更佳！那，能不能这么改呢？

这需要回到，为什么交互输出时，画成了等大样式。在交互环节，运营侧提出四个专题希望是相同层级，无优先级的差异。

这种情况下，视觉同学如果仍然坚持有层级差异的视觉感官更好，可以先和交互同学一起商量，从用户体验的角度来看，这个改变是否有严重影响，如果团队内部也都认为改动后的效果更佳，可以一起找到对应的运营同学，说明原因，建议他们进行调整；同时去了解这样的调整对业务方的业务表达是否有影响。

小结：视觉表达要关注信息模块的比重，视觉侧好的想法也要直接提出和交互及业务方讨论

上面这个案例也是关于模块比重的，最大的差异在于栏目名称及入口的调整。从不强调楼层名称变成楼层名称成为模块的视觉焦点，因涉及到模块比重，类似的改动也建议和交互设计师进行讨论。同样，该案例的改动，丰富了楼层样式，并通过标题模块强调了楼层的调性氛围，同时并未对用户阅读体验造成不好的影响，因此是个视觉提升交互表达的优秀案例。

对于同层级关系的单元格，我们也可以采用不同的操作方式，比如上面案例中，视觉环节使用了叠起的展示样式。相对于交互，优点在于增加了一种互动形式，而缺点则在于会对部分信息进行遮盖，不能直观呈现全部内容。这个案例的处理方式是，我们将两种方案的优劣告知运营方，运营方认为可以牺牲部分信息的呈现，而选择互动方式的不同呈现。

3. 控件样式

我们以TAB来举例，TAB形式体现的是并列关系的多个模块呈现，视觉设计师可以根据不同场景用不同视觉方案来呈现。

常规的视觉展示

场景化表达-日历

下面案例中，交互传达的是一周七天的食物推荐，在视觉阶段可以把TAB样式设计得更贴近日历，更贴合模块的主题表达。

场景化表达-餐桌

这个案例视觉侧在模块面积上进行扩大，影响到原首屏内展示内容的信息量。这种情况则需要与业务同学进行沟通，信息后置是否会影响他们在首屏信息的展示需求。一般活动类页面，首屏内容和页面长度的要求，相对宽松；如果是工具类/综合性展示页面，信息是否能在首屏出现，对页面点击和使用效率会有很大影响。

TAB的引导位置

下面案例中，因为TAB的位置发生了调整，用户的阅读顺序发生了变化。交互稿中，我们希望用户先看到TAB分类以了解推荐手机的不同纬度；而视觉稿中，优先让用户看到推荐商品，如果首轮推荐无兴趣，再通过TAB切换查看其它维度内容。

4. 元素顺序

元素的不同呈现顺序会体现不同的交互逻辑。

下图中的推荐区模块，交互上的顺序是图→人物→具体商品描述，首先强调的是商品，其次是用户的评价；而视觉稿上的顺序是人物→图→具体商品描述，首先调的是评价的人，再说商品是什么。两种逻辑其实都符合「食鲜者说」的逻辑，但从属关系是不同的。这里的逻辑决策是，如果评价用户是知名度较高的，可以通过人物为食物加分，则我们选择视觉稿逻辑；而如果我们是靠商品图本身致胜，评论者只是辅助决策元素，则选择交互稿逻辑。

5. 模块层级关系

模块间的层级关系，可以通过去色来快速判断，是否符合交互浏览要求。去除颜色和元素对界面视觉优先级的影响，更聚焦逻辑本身。

对比下面案例，去色后可以更容易看到，优化后方案更加整体，视觉引导也更加顺畅。

小结

交互稿中体现的逻辑，涉及到样式/位置调整的，我们应遵循原则：「在保证信息顺序、层级关系、信息占比逻辑正确的前提下，视觉可以进行专业的各种发挥」。

文章来源：优设

无论是2B产品，还是2C产品，用户系统都是基础。对于非互联网产品从业者，2C用户系统的场景和功能通过日常各类APP的使用，大家都非常熟悉。因此，笔者通过和2C产品的对比，谈谈2B SaaS产品的用户系统设计。

一、商业的本质差异，决定了产品的核心目标

2C产品面向的用户是个人，用户系统的核心是获客，因此大多2C产品的用户系统设计重点在于方便用户注册、登录，能够建立精准的用户画像，从而达到流量变现的目标。

2B产品面向的用户是企业，用户系统的核心是组织、员工精细化管理，提升人效，从而实现节约成本的目标。

二、业务场景的需求差异，决定了产品的细节功能

1. 注册场景

2C产品的注册主要用于个人用户注册场景，重点在于提供多种渠道的注册方式，如账号、手机、第三方社交应用（微信、微博等），其核心目标是既能方便用户注册，又能多渠道多平台账号打通。

2B产品的注册分为两部分：企业管理员代表企业注册和企业员工注册。

2B平台型SaaS产品，和2C最大的区别在于产品需要用户付费。因此，平台方为企业（平台租户）提供了注册入口，一方面需要方便租户能够通过其他渠道快速注册试用产品，一方面需要验证企业相关信息，识别该用户确实为潜在用户。

1）企业注册：

当企业管理员代表企业注册时，需要提供的注册信息：管理员昵称、手机号、邮箱、企业工商信息（名称、组织机构代码、地址、法人信息等）。

其中工商信息的完整度，不同的产品要求不一样，需要根据具体产品而定。如果方便注册拉新，尽量减少工商信息填写要求，如果产品安全性要求较高，可以尽量要求工商信息填写完整。

2）企业工商信息认证：

这部分并非强需求场景，取决于产品的安全性要求。一般安全性要求较高的平台产品，会在企业注册后，进入到企业工商信息认证环节。此环节要么是平台管理员人工审核，要么通过第三方认证验证企业工商信息是否合规。企业完成认证后，即可试用产品。

如非安全性要求较高的产品，可以直接跳过该环节，租户通过注册页信息填写完整后既注册成功。

3）企业员工注册：

• 注册信息：昵称、手机号、邮箱、其他个人信息；
• 被动邀请：一般B端产品多作为企业员工日常作业工具，因此多采用管理员开通账号制，管理员通过后台将员工信息注册至系统，员工即可登录。被动邀请制员工和公司属于强绑定关系，员工账号不可以独立存在；
• 主动注册：员工主动注册场景中，员工主动注册产品账号，然后再申请加入企业，由企业管理员审核通过后，和企业进行关联。该方式个人用户既可以独立作为平台产品用户，又能够以某公司员工的身份作为平台用户。钉钉即为典型代表，该类产品，一个员工可同时加入多个企业；
• 个人资料：员工注册后，该员工信息注册至系统，并能够在系统中展示、查询、完善个人信息资料。

2. 登录场景

登录场景比较容易理解，目前B端产品相较C端产品仍然比较传统，多采用邮箱/手机进行登录。

未来也希望可以实现，B端产品能够和更多C端产品平台打通，可通过通用的第三方账号进行登录，实现业务与社交的连接。

3. 用户画像

用户画像是2C产品至关重要的内容，只有精准的用户画像，才能更精准的服务好用户。无论是电商，还是资讯平台，基于用户画像的精准营销投放才是产品的核心。

2B的产品很少有讲用户画像相关的内容，事实上对于2B产品而言，用户画像也至关重要。

笔者目前从事CRM产品相关工作，CRM核心要解决的问题就是帮助你的客户获客，那么如何去建立客户的企业标签，去按照企业标签属性，借助大数据分析，帮你的客户找到他的客户群，是笔者近期在研究的课题。

• 建立企业属性维度标签：如行业、规模、业务范围、客群范围。
• 竞争企业标签关联性模型分析：便于了解市场环境、分析竞争企业，及时调整公司战略。
• 潜在客群（企业）标签关联性模型分析：利用数据分析模型，帮助企业识别潜在客户，提高企业获客率。

4. 组织结构

2C的产品从本质上来讲不存在组织结构，个人用户即为产品主体，但会存在群组/社群的概念。

2B产品的应用主体是企业，而组织结构是企业运营管理的必要手段和方式。因此组织结构管理是用户系统的重要组成部分。

1）建立组织结构

组织的单元是部门，因此管理员需要能够按照企业组织结构建立、调整（编辑、合并）、删除部门。

2）部门树结构

部门作为组织结构的单元，只是组织结构的分子，而要形成组织，就要按照企业的业务形态要求形成一定的层级体系。因此部门不仅仅只是简单的信息描述，还需要有层级描述，这就需要我们在建立部门时按照层级结构建立部门，定义清楚所建立的部门是上级部门、下级部门。

3）通讯录展示

管理员通过后台创建完组织结构后，企业员工可通过前台查询按照部门结构展示的通讯录。

5. 角色管理（该部分是2B用户系统设计的重点和难点）

角色管理是B端产品的特有功能，企业员工按其所负责的业务模块划分不同的岗位职责。

由于企业数据具有较高的安全性和私密性要求，按照岗位职责的不同，不同岗位的员工对于业务数据的操作/查看权限不同。

因此，我们设计了角色管理，该角色并非严格意义上的岗位职能角色，而为了区分不同的员工不同的系统权限所设计的系统角色，这就是RBAC设计。

1）建立角色

建立角色的主要目标即为建立一个用户权限组，该权限组内的用户具有相同的权限。

2）分配角色权限

基于角色分配系统权限，以实现不同的角色下的用户拥有不同的权限。

• 功能权限：用于设定该角色能够使用哪些产品功能，如果不属于该角色业务范畴内的功能可以直接对该用户屏蔽，避免过多的功能菜单干扰用户对产品的使用。
• 功能操作权限：企业管理越精细，员工负责的工作越具体，一个功能内，不同的人按照其职责进行不同的操作划分，为了保证数据的正确性和安全性，需要给不同的角色分配同一功能下不同的操作权限。
• 功能内的描述字段权限：一个业务功能中有不同的属性描述字段，但不同的角色关心的属性不一样，为了能够进行区分，需要给不同的角色去设定不同字段的读/写权限。
• 数据权限：企业数据本质上是企业资源，既具有私密性又具有共享性。一个角色具有该功能的一定操作权限，但是他能操作该功能下哪些数据？只能操作他本人创建的数据，还是能操作其他员工创建的数据需要通过数据？这就需要用数据权限来控制。这就要求当数据被创建，该条数据也需要相应的字段来描述该条数据的所属关系，该数据属于哪个用户，属于哪个部门，最终才可实现人和数据的关联，以实现基于员工角色的权限管理。

6. 员工管理

员工管理是B端产品的特有功能，员工是企业组织的重要组成部分，员工也是产品真正的终端用户。

B端产品从本质上是要能够帮助企业员工提升工作效率，提高企业人效，以实现企业管理者降低运营成本的目标。

1）新建员工

前面提到的用户注册即为新建员工的过程。包括被动邀请和主动注册两种形态，主要目标是将员工信息注册至系统，并建立员工和企业的关联关系。

2）建立员工汇报关系结构

为了实现精细化管理，企业内部一般按照组织结构设定员工的汇报关系，因此从CEO到基层员工会形成组织关系树，该结构可以和组织结构完全一一对应，即该部门下的所有员工均汇报给部门负责人，但也有部门内部分不同的小组，不同的人汇报给不同的小组负责人。

因此汇报关系和组织结构关系有一定关联，但并不是完全一一对应，所以我们需要设计员工汇报关系功能。

3）员工离职设定

为了保证企业数据的安全，员工离职后，需冻结员工账号，离职员工将不能以该企业员工的身份登录系统，以确保企业数据的安全性。

• 设定离职：将员工账号设定为离职状态，员工账号被冻结；
• 数据转移：员工离职后，其业务需要其他员工来接替，因此该员工在职时负责的业务数据需要被转移给新的用户，此部分功能需要在数据转移功能中进行规划。

至此，2B用户系统的功能基本设计完整，其重难点在于组织结构、权限控制，需要重点关注。

文章来源：人人都是产品经理

文章来源：站酷

当我们在谈 SaaS 的时候，在谈什么？

● 什么是 SaaS

● SaaS 产品的优缺点

● SaaS 产品的销售模式

● SaaS 产品指标

● SaaS 业务指标

● SaaS 收入计算

一、什么是 SaaS

这个模式让软件变得和水电气很相似，只需要每月缴纳固定的费用即可享受服务。

——马克·贝尼奥夫（salesforce 创始人）

订阅模式

SaaS（software as a service），软件即服务，是一种软件交付和销售方式——订阅许可模式。 

它基于云， 运行在远程服务器上，集中托管。因此不需要独立部署甚至物理分发来完成交付和使用，这意味着用户通过网络即可使用。

例如，过去你使用 office，需要买一张光盘或者在线下载，输入序列号（一次性付费），进行本地使用。如果要更新你需要重新购买和下载版本。而 SaaS 只需在线登录即可使用服务，无需安装和手动升级，并根据使用时间付费（按月/年）。

规模化和复利

SaaS 采取订阅付费（按月/年）模式，良好留存的情况下，当月/年的收入就是下个月/年的基础，不断累加下去（复合累积收益），形成良好的现金流。

也因此，SaaS 产品的收入具有了经常性、可预测性的特点。这使得，企业可以根据现金流进行规划，甚至通过融资，提前获取未来的收入，来进行产品的增长和扩张。

同时，对于订阅者而言，无需购买硬件和中间件（前期成本），以及实施、维护、更新、运维和管理成本（后期持续投入成本），只需要连接网络即可使用，致使决策和投入成本得到了大幅降低。同时，后期可根据业务的发展，升级套餐或增加数量，这些优势致使 SaaS 软件更容易拥有大量客户，形成规模。

从复利性角度，SaaS 产品的估值是经常性收入的若干倍。因此，SaaS 产品的改进，不仅仅是提高下个月的或者长期的收入，而是整个企业的市值，可谓“一本万利”。

开放和灵活

SaaS 会针对不同组织的诉求，提供多种套餐方案，通常在付钱前，用户可以进行免费试用，从而更好的判断是否满足自身需求。

同时，SaaS 会开放自己的接口（API），方便与其他软件集成，从而更好的满足客户业务。SaaS 厂商也会对接市场上跟产品业务相关的主流软件，从而提供更加完善的解决方案。

例如，你使用 53KF 云客服进行在线服务，同时打通 CRM 和订单系统，以及百度、腾讯、头条、360 等流量渠道，从而提供更好的客户支持和流量转化。

先进生产力

SaaS 产品的发展，是不断验证市场需求（PMF）、优胜劣汰的过程，其成功就代表着某种先进生产力（工具、流程或方法）。

从更大价值角度考虑，SaaS 卖的不仅仅只是工具，而是解决方案，融入到生产制造中去，协助客户获取成功。同时，对于厂商而言，也是更有价值、更有竞争力、更长久存在的经营方式。

从市场而言，SaaS 是一种众包模式，厂商觉得市场有大量的同类需求且长期存在，开发成产品进行运作。也真正有效的节省了同类诉求其社会资源的多次投入。

由于 SaaS 产品的有利可图，促使市场的激烈竞争，也锻造了厂商在其领域的专业化，提供更加有效的解决方案。

二、SaaS 产品的优缺点

优点/优势

● 易于访问。SaaS 通过网络提供服务，用户可随时访问，且数据储存在云端，实时同步。

● 免费试用。可以在付款前，进行免费试用，进行多家对比，选择最合适的。

● 费用便宜。使用订阅模式，价格取决于用户数量，订阅者无需一次性支付大量费用，降低前期购置成本。

● 支付灵活。按月/年进行支付，此外，订阅者可根据业务发展，增加或升级套餐，减少或降低套餐，甚至随时停止使用。

● 良好支持。服务的好坏决定了客户的订阅，所以 SaaS 厂商会提供更加友好、高质量的客户服务。

●  开放集成。开放的接口（API）可以与其他产品进行数据打通。

● 立即使用。无需安装和部署，有网络的地方即可使用。

● 无需维护。SaaS 统一运行在厂商的服务器上，由厂商统一维护、更新。

缺点/风险

● 数据安全。所有数据储存在云端和软件厂商的服务器上，可能会引发泄露等安全问题。SaaS 软件厂商，通常非常注重数据的安全性，因为数据泄露对于 SaaS 厂商的企业经营而言是致命打击。有些 SaaS 厂商也提供混合云服务，将敏感性数据储存在客户自己的服务器上。

● 网络连接。没有网络，将无法使用 SaaS 产品。同时，网速深刻影响 SaaS 产品的运行速度。

● 服务中断。软件厂商的硬件故障、网络攻击等造成的服务中断，会致使产品无法使用。

三、SaaS 产品的销售模式

通常来说，SaaS 的销售模式分为三种：

1、非接触（no-touch）：自助服务

1、低接触（low-touch）：交易型销售

2、高接触（high-touch）：顾问式销售

非接触（no-touch）：自助服务

理想的 SaaS 销售模式是客户自助完成整个服务，没有销售人员的介入。

这需要产品简单、价值明显、支付容易甚至售价便宜。同时，产品本身提供良好的支持（操作引导、使用说明、帮助中心以及反馈入口），从而允许客户自助完成服务。

非接触的 SaaS 产品，通过省去销售团队和支持性投入，采用低价，获取大量客户。同时，也因为价格便宜，无法支持销售和支持性团队的组建。

例如，某 SaaS 产品，10 月/月，一个销售人员的底薪 4000 元/月 + 五险一金和办公等费用，那么至少需要销售 600 个客户才能抵消成本，这是很难完成的。

低接触（low-touch）：交易型销售

低接触的 SaaS 产品，通常采用免费试用的方式，进行获客。然后，销售人员通过在线咨询服务（53KF 云客服）或者电话进行销售转化。

同时，产品在 onboarding 上需要投入大量的资源，从而降低用户使用摩擦，使得用户能够成功的上手并获取价值。

低接触的 SaaS 产品通常采用按月订阅的模式，其满意度决定了持续收入。因此，低接触的 SaaS 产品的销售，需要同时兼任“客户成功”的职能，提供良好的客户支持，从而保证客户持续的获取产品价值而不断续费。

高接触（high-touch）：顾问式销售

高接触的 SaaS，通常需要大量的人力投入，招标、拜访、出解决方案、商务谈判等等。

高接触的 SaaS 更多采用年度收费的模式。强销售决定了年收入的上限。因此，高接触的 SaaS 产品几乎是围绕销售团队的，市场营销的主要工作是为销售团队获得足够多且合格的销售线索；产品、开发更多的配合销售团队满足客户需求；客户成功团队接收后期服务、产品支持、关系维护以保证客户续费。

从我个人接触到的，低接触、高接触对于产品设计而言，在于主导权方面。

低接触会考虑更多的价值面（通用的最大化价值），从而会拒接没有未来（可能性和想象力）的单体诉求。

而高接触，更多来自客户传导给销售，销售传导给公司，公司传导给产品的业绩压力。所以，高接触一定是高单价，低单价的高接触在一定层面挣得是辛苦钱，无竞争力的劳动输出，而不是方案输出。

四、SaaS 产品指标（SaaS Product Metrics）

PMF（Product-market fit） 产品市场匹配

SaaS 产品的早期，更多的是验证产品与市场的匹配（Product-market fit，PMF），直白的说就是生产的产品是否具有市场价值，是否有人愿意花钱购买。

所以 PMF 是不断确认这三点的过程：

1、目标客户是谁

2、目标客户的需求（痛点、爽点、痒点）

3、提供的解决方案是否能挣到钱

PMF 通过早期付费客户来确定有利可图的细分市场。和他们不断交谈，收集反馈来迭代产品。

并根据付费客户特征，寻找客户共性，从而更紧密的围绕最佳客户打造产品、从而更明确的找到目标客户接触途径、从而更有效的设计市场营销宣传策略。

NPS（net promoter score） 净推荐值

通过 NPS 进行客户满意度调查，衡量客户体验，预测未来业务增长以及预防客户流失风险。

NPS 采用 10 分制，让客户进行打分。

打分者分类：

● 推荐者（dpromoter）：9-10 分，对服务非常满意，愿意持续使用并向他人推荐，从而推动产品增长

● 中立者（passive）：7-8 分，对服务满意，但忠诚度低不会主动对产品宣传，容易受竞争对手影响

● 贬低者（detractor）：0-6 分，对服务不满意，会对产品进行负面评价和传播，从而阻碍产品增长

NPS=(推荐者数/总样本数)×100%-(贬损者数/总样本数)×100%

例如，有 100 客户打了分，结果如下：

● 10 分：15 人

● 9 分：20 人

● 8 分：20 人

● 7 分：20 人

● 6 分：10 人

● 5 分： 10 人

● 4 分：5 人

忽略打 7-8 分的人数，9-10 分人数 35，6 分及以下 25 人，NPS=35%-25%=+10%

如果 NPS 是负值，那么业务收入可能将会减少，因为客户在不断流失。正值的 NPS，表明客户满意度高，未来具有可持续增长的潜力。

五、SaaS 业务指标（SaaS Sales Metrics）

单位经济收益：CAC：LTV

SaaS 产品的成功与 PMF 高度匹配之外，还需要一个切实可行的商业模式，即客户价值（LTV）大于获取成本（CAC），健康的增长意味有效平衡两者，从而确定这是一个有利可图的市场。

CAC（Customer Acquisition Cost）

获得客户的平均成本。

CAC= 销售和营销费用之和 ÷ 新增客户数量

LTV（Customer Lifetime Value）

客户生命周期内（从注册到流失）平均总价值。

LTV=（ARPA*毛利率%）÷ 客户流失率

ROI（Return on investment）
客户获取的投资回报率。

ROI=LTV：CAC

Months to recover CAC

CAC 通过 MRR 收回的平均月份。

Months to recover CAC=CAC÷（ARPA*毛利率%）

ARPA：每个帐户的平均收入，你的 MRR 除以客户数量，即所有客户的平均 MRR

毛利率=[（营收-成本）÷ 营收]×100%

David 在《SaaS Metrics 2.0–衡量和改进重要内容的指南》一文中指出，LTV：CAC ≥3，Months to recover CAC ≤12 月，通常被认为是良好的 SaaS 项目。同时也指出，很多健康 SaaS 在初期可能并不符合，但会在一段时间内通过改善业务逐渐接近这两条准则。

经常性收入：MRR 和 ARR

经常性收入（Recurring Revenue）是未来持续可获得的收入，就 SaaS 而言，经常性收入来自客户的订阅，具有稳定、可预测、高度确定的特点。

在 SaaS 业务中通常采用按月或按年合同：

● 主要按月合同及少量的年度合同，采用 MRR（Month Recurring Revenue 月度经常性收入）。MRR 用于衡量每月订阅收入，如果有一些年度订阅，除以 12，再分摊到每月来计算 MRR

● 按年合同及少量的多年合同 ，采用 ARR（Annual Recurring Revenue 年度经常性收入）。多年合同除以合同年限，再分摊到每年来计算 ARR

在 MRR/ARR 统计中，并不会计算一次性的收入。例如，定制功能费用。

经常性收入会不断推动这 SaaS 厂商的发展，也是验证产品是否具有可持续增长的指标。

流失（Churn）

SaaS 是订阅模式，在高留存率下，随着时间的推移，意味着更多的客户、更多的订阅，持续收入不断复合累积。所以，流失率对 SaaS 厂商是非常重要的指标。

在 SaaS 中有两种计算流失的角度：

● 客户流失（Customer Churn），取消订阅的客户数量

● 收入流失（MRR/ARR Churn），取消订阅的收入损失

那为什么会有两种计算方式？

例如，53KF 云客服的业务，是按照坐席收费，50 元/月。假如我们有 200 个客户，100 个大客户（每个大客户拥有 100 个坐席），100 个小客户（每个小客户拥有 10 个坐席）。

当月，我们流失了 10 个客户，那么月客户流失率为 5％。

如果，流失的客户中，有 8 个是大客户，2 个是小客户，那么 MRR 流失 45000 元，MRR 流失率为 7.45%。

如果，流失的客户中，有 2 个是大客户，8 个是小客户，那么 MRR 流失 14000 元，MRR 流失率为 2.55%。

所以，通过不同的计算方式，使得我们更加全面、准确的了解到业务中所发生的事情。

Customer Churn Rate

客户流失率，客户取消订阅的比率。

Customer Churn Rate= 期间流失客户数 ÷ 期初客户数    

MRR Churn Rate

月度经常性收入流失率，通过降级、取消而损失的 MRR 比率

MRR Churn Rate= 期间流失 MRR ÷ 期初 MRR 

Net MRR/ARR Churn

净 MRR/ARR 流失。

Net MRR/ARR＝期间新增 MRR/ARR 之和 - 期间流失和收缩 MRR/ARR 之和

Net MRR/ARR Churn Rate

净 MRR/ARR 流失率。

Net MRR/ARR Churn Rate=（期间流失和收缩 MRR/ARR 之和-期间新增 MRR/ARR 之和）÷ 期初 MRR/ARR

当收入增长超过流失的损失，在这种情况下，净 MRR/ARR 流失则为负值，称之为负流失（Negative Churn），表现在财务表上的就是收入的不断增长。

记住，在计算流失时，总是在特定的时间范围内，例如上月客户流失率是 5%。

六、SaaS 收入计算

确认收入（revenue recognition）

对于 SaaS 而言，确认收入是非常重要的财务知识，确认收入与合同金额、收款金额有很大的区别。

例如，按年收费的 SaaS 产品，年费 1200 元，那么：

● 合同金额是 1200 元

● 客户一次性支付年费，收款金额是 1200 元

● 在合同期间的每个月的确认收入则为 100 元。剩下的 1100 元则为递延收益

● 从企业资产负债表而言，剩下的 1100 元均为负债。因为服务还未完成，还需要投入 11 个月资源履行服务义务，甚至合同可能发生中止等情况，所以还不是确定的收入，需要通过后期的确认收入（损益表中的利润）来减少资产负债表上的负债

* 递延收益：指尚待确认的收入或收益。凡在期间内完成的服务所产生的收入，则为确认收入；反之，即使款项提前预收，但未在期间内完成服务，则不作为确认收入。

* 资产负债表：反映企业经营在一定时期内（月份、年度）财务状况（两个方面，一方资产、另一方负债和权益）的报表。

* 损益表：反映企业经营在一定时期内（月份、年度）利润（收入）或亏损（支出）的报表

总结

通过梳理总结，谈了谈 SaaS，这是在我当前知识体系范围内的总结，SaaS 是的庞大的体系，关乎个个层面：产品、营销、销售、客户成功、增长、定价、渠道等等。

如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。