做中后台产品的设计，基本都逃不开导航布局这个大框架。

基于用户的 Z 字形扫描行为，重要的导航应当选择左侧导航或顶部导航。

可是横着竖着有那么大差别吗？被人问道为什么这么选择，该如何回答？

今天给大家些灵感，从以下四个角度分析一下：

• 科学角度
• 布局角度
• 尺寸适配角度
• 统一性角度

科学角度

JR Kingsburg 曾经做过一次实验（A comparison of three-level menu navigation structures for web design），研究 3 层导航中，哪种组合使用效率更高。

这三层中，每一层都有横向和纵向两种可能性，所以实验总共有 2×2×2=8 种对照组：

他为这 8 种导航布局做了不同电商原型，让用户来买东西，并记录各种数据，结果发现了很多有意思的数据：

综合这些数据，看起来整体表现较好都是「左上上」、「左左上」、「左左左」。

科学虽然很严谨，却缺乏灵活度，例如本次试验的场景单一（电商购物），而且用来测试的界面未免也太简陋了吧！

所以我们再从其他角度思考看看。

布局角度

从占据面积的角度来看，横向导航比纵向导航省地方，因为只要细细一条就好了。

然而，选项数量不多时横向是可以；选项多起来，横向导航就很拥挤了。

毕竟纵向导航方便滚动，横向导航很少有用户会尝试滚动查看的，「…」也不是什么方便的操作。

所以，如果确定选项少可以选横向，不确定或者数量多建议保险起见选纵向。

尺寸适配角度

任何导航，都要占据屏幕不少空间，这对尺寸适配都是一件麻烦事。哪怕产品并不需要为移动端做响应式布局，只要是网页端，就得考虑窗口尺寸的变化问题。因为设计师的 Mac 和大量用户的 PC 甚至平板电脑之间，展示上的差异真的不小。

横向导航占据空间最小，同时也是最难做尺寸适配的。尤其是如果上面除了导航之外，还放有各种 logo、头像、图标、搜索…各种东西时。横向导航一般都有三种状态：展开、折叠和收起。但是纵向导航就简单了，只需要两个状态：展开和收起。顶多再让展开状态的宽度能够自适应变化或手动拉伸就差不多了。

这么看来，如果产品需要考虑很多不同尺寸适配的问题，纵向导航是最简单的选择，除非横向导航的内容不多维护起来不麻烦。

统一性角度

我之前为了研究确定按钮放在左边还是放在右边好，做了一系列实验分析，结果得出超出我预期的结论…放哪都没多大问题，统一就好。于是，我想这个问题也可以类比一下。

大部分网站都是横向导航，所以说如果产品是以网页版为主，且用户会经常穿插跳转使用其它网页，那么也使用横向导航比较符合习惯。

而无论 PC 还是 Mac，系统页面的导航在左侧的情况比较多，所以说如果产品是系统软件的话，纵向导航比较符合习惯。

然而，更更更更更重要的是，千万不要同一个产品不同端或不同子系统的导航不一样！用户很可能一会儿用这个，一会儿用那个，结果操作习惯换来换去，人都弄晕啦！还有，就是改版换导航肯定要让老用户不满，好不容易养成习惯改起来容易吗？所以说，决定导航布局时还是要谨慎才好哦。

文章来源：优设  作者：体验进阶

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

B 端的一些业务场景中常会使用地图元素来展示信息，但是 B 端的页面情况较为复杂多变，与 C 端的百度地图等使用场景以及业务具有一定的差异性。在工作中，我们对于地图页面的布局、交互统一性上的研究还是较少，所以我进行了业务场景下的列表与地图的关系的设计沉淀。

常规地图样式

地图作为一种将地理信息以二维的手段展示的图像。日常纸质地图常常会分为两个模块：地图信息、列表信息。对于现 web 端的产品，地图也保留两者的信息区域并进行不同的布局排布，如百度地图等。针对 web 端的产品，因为有交互形式的出现，所以在地图上会存在更多的信息展示。

地图信息：

• 地理信息： 以可视化手段、数理的方式将地理信息处理后的信息。
• 打点地址：打点在地图上的位置分布，其可看作一个基于地理信息的可视化方式。
• 在图上显示点位的信息。

列表信息：

• 打点列表主要信息：运用列表的形式展示打点的初步信息。
• 打点的详情信息：针对打点有再次下钻的能力，来显示单个打点的详情信息。

现业务中常见地图设计

针对现在工作、学习过程中遇到过的具有地图元素的业务，我进行了整理并总结出了一些不同场景下存在情况以及现业务阶段存在的问题。

首先我总结了列表的信息与地图信息的关系，一共为三种不同的情况。

• 一对一：列表与点位一对一的映射
• 点位内容范围大于列表内容
• 列表内容范围大于点位内容

随后，我针对打点详情信息的复杂度进行了三种程度的区分：简单；复杂；极复杂（较少）

最后，我走查线上业务版本发现了一些现地图元素的一些问题。

1. 排版不统一

针对地图的两种布局，使用较为随意，并没有规定其合适的场景使用不同的排版形式。

2. 功能入口的交互不统一

针对于地图上的列表，常有功能有定位、查看详情，以及一些特殊场景下的特殊功能入口。然而，这些功能其入口常常不统一，点击列表，有时承载的是查看详情，有时是地图定位、甚者点击卡片不承载任何功能入口。

3. 地图打点与列表的对应混乱

有时地图上会存在多个列表的情况下，从而导致列表信息与地图上打点信息对应的混乱，这样会让用户感到信息的不明确。

根据以上存在的问题以及情况，我们总结了两点设计原则，针对地图模块进行了修改与推进。

• 清晰简洁：保证整体页面层级的清晰；地图信息的简洁，确保地图信息最大限度的展示。
• 对应明确：明确点位信息与列表信息的对应关系。

地图中排版以及交互逻辑

地图中常包含了四类元素：列表：主要信息、地图、地图打点、打点的详情信息。

针对以上问题，我们从三个点进行了整理分析：列表的交互形式、地图与列表的整体布局、地图打点的详情信息。

列表交互：针对地图列表，点击列表的主要交互操作分为三种

• 地图定位
• 查看详情
• 定位+详情

地图布局：为了清晰整体的地图层级，我们将列表与地图分为了两种不同的形式

• 以地图为底的列表浮层结构
• 列表与地图的左右结构

并且，根据整体的布局结构，我们将这两种布局形式中包含的隐形的逻辑从而进行了区分，将地图与列表进行了主从关系的分配。针对于第一种形式，地图为底，列表作为具有阴影的第二层结构，其包含了隐形的地图为主、列表为从的逻辑形式；

而针对列表与地图的左右排布结构而言，因为两者处于同其级别的元素，更具左右、上下的阅读习惯，其包含了列表为主、地图为从的逻辑形式。

而后，根据整体布局的逻辑形式，我们将上文总结的三种不同业务场景进行了分配，并提出了使用建议。

针对于地图（主）/列表（从）的布局情况：

• 使用场景：适用于地图点位内容范围大于列表内容。
• 列表交互：推荐点击单个列表首要交互为定位功能。

针对列表（主）/地图（从）的布局情况：

• 使用场景：适用于列表内容范围大于地图点位内容。
• 列表交互：推荐点击单个列表首要交互为 详情功能。

打点的详情信息：上文我们根据打点的详情信息分成了三类：

• 简单
• 复杂
• 极复杂

针对这三种情况，我们提出了三种情况下使用的交互形式。

对于简单的信息来说，可以推荐使用气泡弹窗的形式；针对复杂的信息展示尝试用右侧抽屉的形式以及替换当前列表；针对极复杂的场景如需要展示画布或者列表的话可以考虑底部抽屉的展示形式。

针对气泡弹窗以及右侧抽屉，我们也提出简单的使用建议。

气泡弹窗：

• 用于信息复杂度较低的场景，以简洁地图信息，保证完善展示。
• 不应该在小气泡中承载过多的信息，以滚动、切换等呈现。

右侧抽屉：

• 用于信息复杂度较高的场景。
• 建议在 列表（主）/地图（从）的布局中使用
• 不建议在地图（主）/列表（从）的布局中使用：此布局下需要保证图中仅有一个与地图所对应的列表(利用 icon 区分等形式)，并且此布局下地图点位数据会较多，若两个层级的点位同时显示会造成干扰。
• 若需要进行对于详情信息的编辑，建议使用蒙层；若需要使用地图，建议隐藏主列表，以保证复杂表单的输入过程保持专注。

小结

最后，根据上述总结的内容，我绘制了一张表格简单的流程图供大家快速的参考。以上结论，仅仅是一个初步的总结，对于更加的细节的点还需要继续进行研究迭代，例如简单于复杂的界限等。

文章来源：优设  作者：土拨鼠

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

接下来为大家分享一下我收集到的案例：

蓝蓝设计(北京兰亭妙微科技有限公司）是一家专注而深入的UI设计公司，公司对UI设计的追求一向很高，致力于为卓越的国内外企业提供卓越的手机 ui设计、软件界面设计、网站设计，用户研究、交互设计等服务。

--网站建设UI设计--

导语：TMS（运输管理系统）是一个物流运输平台，它是供应链管理系统（SCM）的一部分。广义的TMS平台涉及面较广，不同企业的业务模式不一样。本文所探讨的TMS是具有实际运营能力的第三方物流运营平台，它主要是一种通过技术的手段整合社会物流信息，优化配置物流资源，帮助货主降低物流成本并提供管理运输业务。下面从业务描述、系统架构和功能模块三个方面作一个简单的分析，一方面是梳理业务的作业场景，另一方面宏观认识产品的整体框架，分析具体功能解决的问题点。

一、业务描述

通常来说，整个运输阶段分为三个阶段来完成：

1. 第一阶段

货主提出运输需求，建立任务订单推给运营方。

客户下订单的方式有很多，比如电话、邮件、发信息、TMS系统、其他平台等。提出的任务需求，也称客户订单，它是货主和运营方的交互凭证，承担着需求描述、运单跟踪、应收结算等功能。

货主订单主要包含4方面的信息，收发货地信息、货物信息、用车信息、增值服务。

1. 收发货地信息，姓名、电话、地址，预计提货、到货时间；这里货主所约束的发货、收货时间，只是客户要求的时间，具体到运营方的业务运作，实际的发货、收货时间会有区别；
2. 货物信息，商品类型、货物重量、体积、数量，更详细一点到标准产品的单位；
3. 用车信息，车型，温控标准等。作为货主方可能对车型也不一定了解，所以这不是一个非填信息；
4. 增值服务，比如是否需要装货、搬货、卸货、货物保险等。

2. 第二阶段

运营方按照一定的运输规则处理，做这个规则处理的过程，一般称之为计划，计划的形式有多种，主要有拼单、拆单、规划线路图、地图合单等，然后再将计划好的这个订单分派给合适的承运方。

最常见的手段是拼单，又称零担运输。将多个货主订单合并拼成一个派车订单，一般规则的处理条件有：订单量、装载能力、价格、路线、发货时间、收货时间等。

计划的手段除零担集货外，还有大单拆分、长单分段等，主要目的来达到成本分摊的作用。计划的手段有智能计算，和人工处理+半自动计算。

1. 智能计算，自动的方式。在满足运输条件的规则下，自动进行拆分、拼单，生成计划单；
2. 人工处理+半自动计算，也是最常用的方式。比如可以根据我们LBS地图，将要发货的点映射到地图上，圈出相邻相近的发货地，再根据约束条件的计算，比如温控标准、要求运输的时间等，生成可调度的运输订单。

3. 第三阶段

承运方接受订单，并将订单分配给司机，由司机执行完成运输任务，这个阶段又称之为调度。运营方将计划的订单分配给承运方，生成最终的运输订单，它是运营方同下游承运方的唯一标识，这个凭证会关联到订单的跟踪监控和应付结算等功能。

二、系统架构

三、功能模块

1. 基础资料

基础资料的建立，对TMS的需求任务单和调度非常重要，只有建立了合作关系，才能在客户需求订单上选择到正确（有合作关系）的客户，在计划调度的时候才能匹配到正确（有合作关系）的承运方。

录入货主、承运方的信息，以便于后期订单的生成， 这些信息的维护可以保证每个订单都有归属客户，方便订单的管理。

1. 货主：有需求的角色，可通过供应链平台的商家端创建任务订单；
2. 承运方：负责承运能力的角色，提供车辆司机帮助完成运输订单；
3. 运营方：货主和承运方的桥梁，一边从货主获取用车需求，分配给相应的承运方；另一边将承运方的返回的任务状态信息回传给货主。

1）货主管理

客户资料会有专门的CRM维护。

2）承运方管理

有承运商、自营车辆和2C车主三种。 2C车主，个人司机管理模块，没有合作关系。个体司机加入平台，需要进行注册认证，只有认证通过后才能给这些司机派发运输订单。

司机的信息维护除了注册认证外，还有在平台的所有活动数据记录等。和承运方相比，此前不需要有固定的协议合同，相当于临时工的概念。

3）用户管理

运营方用户之间建立的合作权限关系。

2. 客户订单

在第一阶段，货主提出用车需求。需求订单信息包括收发货人信息、货物信息、用车信息和增值服务，详细描述在上面的「业务描述」中有说明。具体到TMS系统中，这里不但只是货主的信息录入，它还包括收发货人信息关联、地图定位、里程预估、上下游价格等。

客户订单它是货主和运营方的唯一标识，货主的订单状态有，待计划、待调度、已调度、等待提货，取货中、运输中、已完成等多个状态。

3. 计划运输

客户需求订单创建成功以后，就开始进入到运输业务的第二阶段，运营根据一定的规则处理，将订单进行自营车辆运输、派送给承运方或者转给2C车主，这边的基本流程为：

1）审单

TMS系统对客户的需求订单做分析，分析出有问题的订单，比如信息填写不完整、地址解析错误等。

2）计划

计划和调度是运输业务的第二个阶段，它关系到整个运输的最终成本控制，是整个运输过程最重要的核心组成部分。

计划的目的，是为了解决时效优先还是成本优先，更多的作业场景是在这两者间作一个平衡处理。运营方作计划的规则处理，会受到以下3个条件约束：

1. 车辆类型、装载重量、体积等限制；
2. 送货/收货时间；
3. 运输线路的稳定性。

常见的计划优化手段有：装载优化、路线优化。 运输计划的方式有很多，总之在满足时效的同时，成本最低是计划的主要目的，主要手段有三种：

1. 合并订单：资源最优利用：将众多非整车货主订单（零担）拼成一个整车运输订单，它实际是一种装载优化，根据车辆最大载重和体积限制，提高装载率；常见的做法是，基于已有订单分析，相邻相近的订单自动合成运输计划单。这样可以减轻货主方配送成本，司机单次配送的收入也会增加（2C车主），最终实现人和车资源的最优利用。
2. 路线优化：提升出行效率：基于提货点和卸货点的地理位置，寻找最佳配送线路，缩短车路程和时间，降低行车成本；常见的做法，地图规划、固定线路。使用地图规划的好处：根据货主订单的时间约定，以规划更合理的路线。
3. 规则派单：互惠共利：针对承运方、2C司机等分析，按照既定好的规则，派单给符合条件的承运方或司机，匹配因子包括：车型、司机、距离、满载率、价格等；如果运输业务数据量大，在满足货主和司机的要求下，可以最大程度解决效率低、成本高的问题，使得货主、司机、运营方三方共同得利。

关于城配：

1. 短途运输，城市配送。它是一种面向企业的计划性城配物流，主要有仓-仓、仓-店、仓-家等场景，相较于干线，城配运输对服务和时效性的要求更高；
2. 仓到店的业务场景，一般有固定的城配线路 ，类似于公交车的固定线路和站台，不同之处城配只提货一次，接下来的多个站点卸货。比如从某仓库提了一批货出来，按照规划好的路线送到各个站点，这里站点不仅限于门店，也有可能另一个仓库，或者盒马、全家等；
3. 城配计划：在满足时效性的前提下，需要规划车辆的装载率、用多少车辆配送哪些收货站点，最大程度减少货主的运力，继而减少运送成本。除计算的线路外，也可以通过地图展示的形式，人工进行规划。

考虑到TMS中订单量大、位置信息较为复杂，纯人力计划效率低，有时不能够满足客户的需求。

所以一些企业会根据订单结合计划承运方作出进一步的优化「智能调度」，利用算法围绕货物、车、路线、时间合理规划策略，实现最优资源的分配方案，完成最终的运输工作。

3）调度

把计划的订单进行派发给相应的承运方，这个过程称之调度。派发的渠道有三个，分别是自营、合作承运商和2C车主。

1. 合作承运方：根据已签订的合同，让承运方帮助提供车辆运输服务。承运商的运输订单，运营方对于实际的运输车型、司机信息都是不知道的，所以运输中出现的问题需要承运商对接。自营车辆、个体司机的身份信息较为完整，可以直接联系到。
2. 自营车队。效果最好的承运方式，有着控制力强、专业度高，协调方便等优点，也是成本最高的方式。
3. 2C车主。社会上的司机，一般临时紧急需要的一种调度运营方式。

承运方接单后，会将调度的信息同步到WMS，包含车辆提货时间、运送车型等。告知到仓库的目的 ，可以让仓库可以提前备货，节省提货时间。下面所说比价计价模式，就是在调度的时候，根据各个承运方给出的报价，会选择合适的、性价比高的承运方。

4）跟踪

订单跟踪是运输业务的第三个阶段，承运方已经开始执行配送任务，实时跟踪订单状态，并将状态信息回传给运营方和货主。实时获取订单的当前状态，比如位置信息、货物的温度等，也方便平台管理司机，以保障订单任务的顺利完成。

提货：

• 司机接受订单，根据提供的运输订单，到指定的地点提货；
• 司机在提货的时候，需要验货，比如重量、是否损坏等。

跟踪监控：

• 获取货物订单信息，根据距离信息判断，并更改订单状态；
• 比如估算司机到提货点、卸货点的距离，能够得出提货、卸货的时间；仓库可以根据车辆到达收货点的距离，提前做好货物入库的准备；
• 跟踪车辆在运送过程的温度，匹配货主订单货物的温控标准，对不符合的情况作出预警提醒。

签收：

• 正常签收。收发一致，发多少货，收多少货；
• 损坏、缺失。 涉及到赔偿，界定行为的过错方。根据订单的跟踪监控进行判定，比如货物在运输过程中，有一半时间温度不达标等；
• 拒收。原路返回。冷链运输中的生鲜、冰淇淋等产品，如果遇到化冻后产品就是报废处理了，所以不存在拒收，这种情况需要通过责任认定协商赔偿。

中转站：

• 干线运送有直达和中转。直达，即货品发车后，直接送到收货地址；中转，即运输的货物需要交接，交接的站点称为中转站；
• 中转站，在TMS运输中一般只作为临时性的寄存功能，交接的货物在中转站存放时间较短，不涉及复杂的入库出库，所以中转站只涵盖三个服务，收货、暂存管理、发货；
• 在实际具体业务中，为防止工作人员货物码错、出库错误等情况，会给到站的货物、容器打上唯一的标签。

5）回单

一种发货的凭证，证明对方已收到货，也是最终货主结算的凭证。

收货方签收订单后，司机需要上传回单并更改状态完结订单，考虑到线下是作业，回单的照片清晰、其他敏感信息等原因外，运营方需要再次确认后将回单再返回给货主。

回单也分电子回单和纸质回单，电子回单：大部分情况下都采用这种，司机将签收方的订单，拍照上传即可；纸质回单，需要将回单寄回给货主，当然回单还是会扫描记录到TMS系统中。

四、异常管理

在客户订单签收之前，都可以上报异常，上报异常需要对异常情况进行详细说明，比如货损损坏情况，进而进行协调处理，界定赔偿责任等。

上报异常的渠道可以通过电话联系运营方，由运营方的客服部门进行对接，异常订单也会进入到TMS异常管理中，并对异常进行记录、处理、跟踪工作。比如上述所说签收方在签收的同时发现问题，也可进行异常上报。

五、价格管理

1. 计费规则

• 单一计价，按重量、体积、整车来计量，体积的计价方式较为复杂，一般会通过一定的规则转换成重量计算；
• 分段计价，判断货物属于哪个区见，计算价格；
• 阶梯计价，分别对各个区见进行运算，最后将所有的区见相加，当然也有可能出现分段和阶梯的混合计价方式。
• 比价计价，同一批运输订单，不同的承运方给出不同的价格，价低者得。

2. 价格模板维护

根据不同需求维护不同的价格模板，方便使用和管理。上游价格模板，对商家进行收款的计价规则； 下游价格模板，对承运方进行付款的计价规则。

3. 价格模板应用

根据制定好的价格模板，规定价格模板的应用条件。对符合该条件的商家套用模板进行计算，价格模板的调用可以从不同维度，比如：线路、商家、货物类型等。不管下游承运商，还是上游的货主，不同的客户都会应用不同的报价模板。

六、结算管理

在结算管理中，对生成的订单费用进行审核，实际业务的变动对最终账单核算也会有调整，审核无误后生成最终的账单，然后由财务人员对照账单进行上下游的收款和付款。

• 应收：收取上游货主的费用，生成费用账单，财务进行收款；
• 应付：付给下游承运商的费用，也有可能是2C的司机，生成费用账单进行付款。

文章来源：人人都是产品经理   作者：亦果儿

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

业务场景拓展，字段增加又增加，原本眉清目秀的表单变得面目全非。

想要将这些复杂信息、组件组装成用户易填的表单，常常会让设计师陷入无限的纠结。本文章聊聊用户体验视角设计表单的思路，希望对大家有帮助，欢迎一起讨论交流。

结构如下：

• 表单是什么
• 表单的内容
• 设计思路
• 设计技巧

表单是什么

表单是数据录入、数据展示的重要工具。

生活中随处可见，比如面试要填表单、办银行卡要填表单、入库要填表单…

互联网产品设计中也离不开表单，如注册、登录、商品录入、功能设置…

表单的内容

表单主要由这四类元素组成：标签、输入域、操作按钮、提示信息。

1. 标签

标签文本主要是解释输入项的含义，一般不宜太长，需要简洁明了，快速让用户理解。

标签对齐方式有左对齐、右对齐、顶对齐、内对齐，都有各自优缺点，不同场景酌情使用。

2. 输入域

输入域是表单的核心，是录入信息的核心交互部分，为了不同信息更易录入会采用不同交互组件。比如：单行文本框、多行文本框、单选框、多选框、数字输入框、金额输入框、日期、日期区间、人员选择、部门选择、图片、文件等，具体组件可以去查看 Ant design、ElementUI 官网。

3. 操作按钮

操作按钮是表单信息录入完成后，继续或取消任务的触发器。

为了让用户视觉聚焦和更快完成任务，操作按钮分为主次按钮，通常主任务操作为主要按钮，次任务操作为次要按钮，并且一个场景中通常只有一个主按钮。比如，提交和取消，保存和取消等。

4. 提示信息

录入提示：帮助用户更具象的理解录什么怎么录。

帮助提示：表单中如果标签信息无法让用户理解，可以提供帮助信息让用户更准确的理解，通常在标签的前/后有一个帮助按钮，点击/鼠标悬浮按钮出现有帮助信息的弹窗。其他还有页面帮助信息，新手引导帮助信息等。

错误提示：帮助用户理解哪里错了和怎么做正确。

设计思路

表单设计目标：让用户更轻松获取表单信息，更容易懂，更快速完成表单信息录入任务，如果还能让用户过程很愉悦就更妙了。（用户体验视角）

设计方法：通过降低用户行为负荷，提高表单设计的用户体验。

行为发生的常规路径：通过视觉输入信息到大脑 （视觉）— 大脑消化信息（认知） — 采取动作（动作）。

视觉负荷：用户在屏幕上识别和寻找信息，都属于视觉负荷，信息获取越轻松视觉负荷越低。

认知负荷：大脑处理信息时理解、思考、记忆都属于认知负荷，复杂陌生信息的认知负荷需要消耗大量脑力；所以减少认知负荷的核心是减少用户思考，甚至是不要让用户思考，成为大脑潜意识认知的决策。

动作负荷：用户在使用产品时如果操作太繁琐步骤太多，有可能会中途放弃，这就是动作负荷带来的影响。所以在不大量增加视觉负荷和认知负荷的前提下，减少交互步骤可以降低动作负荷。

通过降低视觉、认知、动作负荷的“三招”，提升行为产生节点间转化率，让任务行为发生更容易。

误区：有些人陷入了设计极端，认为操作越少交互设计就越好，实际上用户能更好阅读并理解比少一步简单操作更重要。

补充：心理负荷在特定场景也是影响用户行为发生的重要因素，如隐私、健康、安全、财物等。

设计技巧

1. 降低视觉、认知负荷

表单的信息是视觉负荷和认知负荷的源头，所以如何设计信息易读易理解就尤为重要。

灰机的方法就是先盘信息，再梳理（该拆的拆，该合的合，该减的减），然后有节奏编排信息。

就像搬家后收拾房间，有一大堆东西需要整理，我们通常会先盘下有哪些东西，然后就是该丢的丢，该放在一起的放一起，最后分门别类放在房间的合适位置。

拿到表单信息后不着急动手，先了解此表单背后的业务场景，理解每一条信息字段背后的业务价值。这是有说服力设计的核心支撑。

通过拆、合、减的方法，归类组合信息。字段信息非必要就减掉，相关性高的信息放一起，梳理的目的是让信息归类更符合用户认知，让信息更易被用户理解。

技巧点：

• 文案尽量简洁并贴合用户认知，垂直业务的文案最好是业务语境的表述。
• 按业务场景合并包装信息，比如把复杂表单字段包装成A、B、C三个选项供用户选择，用户更容易理解和易用。

有节奏展示

信息有节奏展示有利于用户更高效获取、理解信息。毕竟如果信息像机关枪子弹一样连续涌入大脑，谁都没耐心看，并且大脑消化也跟不上。

技巧点：

• 信息录入先简单后复杂，先熟悉后陌生
• 先放必填基础信息，后放选填自定义信息
• 有前后逻辑关系视情况分步展示
• 信息能单列展示就不用多列（从上至下或从左往右，按一个规律的视觉流信息获取更轻松）

2. 降低动作负荷

通过减少用户行为成本，达到降低动作负荷的目的。毕竟录入信息方式越容易，就更容易完成表单录入。

技巧点：

• 能给默认值就不让用户选
• 能让用户选就不让用户输
• 平铺单选优于下拉单选（有限选项时）
• 输入时能智能联想就联想
• 能即时校验的早校验纠错

文章来源：优设   作者：灰机

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

Dashboard的含义

前言

Dashboard在B端设计的工作中是一个绕不开的话题，在此我根据自己工作中实际的一些经验总结给大家归纳出一篇更符合工作场景中Web端的Dashboard设计内容。

什么是Dashboard？

Dashboard的中文直译是仪表盘，最初与dashboard相关在界面出现的是苹果电脑系统Mac OS X v10.4 Tiger操作系统中的应用程序，用作称为“widget”的小型应用程序之运行基础。

B端常见Dashboard

2013年Stephen Few写的《Information Dashboard Design》中指出“仪表盘是为了实现某些特定目标而对重要信息进行的视觉传达，对一屏上的内容进行组织呈现使人一瞥便能掌握其所传达的信息。简单点来说就是：为用户提供全局概览，让用户快速掌握工作进展及进入工作状态并可以访问最重要的数据，功能和控件。

Dashboard设计案例

以下是Dashboard常见4点设计不是很好的案例，现在带大家一个个看下怎么才是更为合理。

案例一：右边Dashboard上的信息做了层级的区分，相对左边更加直观。

案例二：左边Dashboard颜色偏荧光色，色彩语言相对右边不适合长期工作使用。

案例三：设计方案时没有采用格栅格化解决适配对不齐等等问题

案例四：dashboard模块之间间距没有呼吸感。

B端Dashboard的功能分类

设计师需要了解的功能分类

B端设计中，设计师要实时了解哪些是重要内容以及核心数据。Dashboard可以直接传递出：“业务整体状况如何？有哪些关键指标？各指标的运行情况分别如何？哪些指标出现异常？需要用户做些什么？”。由此可知，B端Dashboard产品中大多数都以看为主，辅以功能控制。主要分为监控操作、分析处理两大场景。当业务较为复杂时，可以用战略概览场景提供快速入口。

1.监控操作：

使用户可以一目了然地检查其状态，提供关键指标实时监测并且告知异常状态。更重视实时观看状态。

2.分析处理：

通过数据图表，配合控件进行不同维度的数据分析。以数据为中心，并显示尽可能多的相关数据视图。

数据性Dashboard。数据概览可视化展示为主。帮助用户提供较为直观数据维度，更好分析决策。

综合性Dashboard，既有提供数据全局概览可视化，同时也能快速在页面进行操作完成工作。国内B端产品最常出现的Dashboard功能模式。本篇文章也是着重介绍如何完成这个类型需求

3.战略概览：

在复杂的业务中，可以呈现业务分散的重点信息，用户可以通过提供入口快速跳转至相关模块。

设计前分析

了解Dashboard的用户

B端设计过程中每多了解一个维度分析就更有利于下一步Dashboard框架搭建。因此在对Dashboard有了一些简单了解之后，我们再来了解下用户场景。例如：用户是财务人员审批商户充值申请。工作人员进入dashboard之后先是进行充值打款申请。那么设计时可以考虑在Dashboard中加入常用功能：充值。并且需要给到相应充值数据概览：账户余额。每个B端产品都有自己特定工作场景。因此从用户、场景和任务这三方面考虑，可以做到帮助设计师更清晰设计dashboard布局以及设计自查。

因此以上这些信息都是需要在设计Dashboard时弄清楚的内容。

信息处理

当弄清楚需要呈现信息内容后，需要进一步对信息做处理。从用户的角度，举个例子在FMS财务系统记账中，财务需要查看季度报表。那么数据的单位以默认季度呈现会更为符合使用用户需求，准确且高效。具体可以从以下四个维度来做进一步处理：覆盖范围、时间跨度、粒度、个性定制。一般核心指标不超过7个，确定核心指标的联系及优先级。

合理的信息结构能够帮助用户高效阅读，理解内容。如何将信息碎片有逻辑地组合在一起，合理呈现和布局，选择使用什么结构视内容而定。

举个例子：

对于管理者的角色来说使用Dashboard的诉求是：及时把控业务情况

信息处理内容：

1.掌握重要业务数据：经营数据，订单数据，客户数据；

2.了解员工工作进度；

3.处理急需解决的工作任务。

对于执行者的角色来说使用Dashboard的诉求是：高效完成工作任务

信息处理内容：

1.急需解决的工作任务：待发货订单，待退款，待跟进客户

2.了解自己的工作进度

3.经常使用的功能：发布商品，添加客户，开单

4.查看重要通知公告：公司发布的公告

了解Dashboard的表现设计类型

Dashboard表现结构常见两种类型：卡片型、流程型。

卡片型

最常见就是卡片型。即将有相关联的内容进行分组呈现，让Dashboard内容归类而不杂乱无章。

流程型

内容相互之间具有一定的逻辑关系，如地理位置关系、数字包含关系、对象父子关系等，这种结构可以让对象之间的逻辑关系十分直观。很直观的呈现了资源对象之间的相互关系。

Dashboard的设计

Dashboard的表现构成

国内B端产品一般是由以下这几个部分组成的。全局导航、数据概览、待办事项、常用功能、任务进展、平台推送、数据图表。下面带大家仔细看下具体每个部分具体如何设计。

1.全局导航

在B端Dashboard中，全局导航一般由三个部分组成。平台LOGO、功能入口导航、快捷功能导航。

1.1平台LOGO

一般这里都会放LOGO，对于一些壁垒标准化B端服务，这里通常是给好标准规则，后台自动配不同客户的LOGO。因此要考虑到区域的色彩是否适用各种不同LOGO。如果是OA或是定制化B端服务，那么就可以直接定制设计。

1.2功能入口导航

就是菜单导航，在B端Dashboard一般都是在侧边。建议最多不要超过9个，遵循7±2原则。尽量将同类型归类，好好利用下二级分类。另外入口不要太深，用户容易找不到入口。尽量设计优化合并来减少用户使用负担。

在国内B端产品中，最常就是将功能入口导航放在侧边。适用于更专注功能和快速操作的系统

优点：

拓展性，一级导航的数目可以展示更多；

层级清晰，一二三级导航都可以流畅展示；

操作效率高，用户在操作和浏览中可以快速定位和切换当前位置。

缺点：

视觉动线左右折回，比顶部导航更易疲劳，

内容区的排版空间更小，需要考虑适配问题。

在国内B端结构比较庞大的后台中,通常会将功能入口导航设计为混合模式。混合模式就是将功能入口分为顶部与侧边两边都有。这是因为侧边模式已经无法层级扩展性已经无法很好的满足产品架构了。

优点：

层级拓展性强，可达四、五级导航。

缺点：

操作难度上升、视觉动线更复杂。

还有一种模式：顶部模式，这种模式在国外产品中较多，在国内的B端产品中较为少应用。原因之一是起初最早的国内B端产品就采用这种排版模式，在国内形成了一种用户操作习惯。国外最常见的B端顶部导航：saleforces、hubspot、zoho。

优点：

沉浸感比侧边以及混合都要强，几乎不会对于用户的阅读行为有干扰，因为Web也有顶部浏览器菜单。

缺点：

一级导航栏的栏数及字段内容受限严重。国内B端产品会有很多快捷功能就更不利用采用这种模式

1.3快捷功能导航

一般包含：消息通知、账号信息、帮助中心、设置。在国内B端产品中基本上都是在右上角

2.数据概览

在B端Dashboard中，数据概览通常都是选取最关注的数据指标来展示，而不是全部数据；选取最关注的时间段，而非全部时间段。

构成：数据名称+数字

这个模块在设计表现上最重要就是信息层级的设计处理。如何能够让用户一眼就看到最关注的数据内容指标。设计时注意突出数据才是关键。设计时关键数字上就要字号大一点，甚至可以采用特殊的数字字体，例如DIN系列，来加强对比。

3.待办事项

待办事项模块通常是应用在执行角色的Dashboard中。节省工作人员寻找任务的时间，避免遗漏任务。

构成：待办事项名称+数字+可点击跳转的链接

待办事项的展示方式可以是数据可视化也可以是数据概览。但是有一点，数据必须是要能够点击的，因为待办事项就是要有入口去操作。同时也可以把待办事项平铺出来，平铺几个可以根据具体情况定。如果待办样式本身很多的情况下，可以采用tap切换的样式全部展示出来。

4.常用功能

用户高频操作快捷入口，点击跳转相应操作页面。这个模块每个b端产品都不一样，需要仔细反复斟酌是否是用户需要的高频功能。

5.任务进展

用户当前最关心的任务，常用进度条或者时间轴的形式表示。

6.平台推送

平台用来触达企业的信息，一般有产品更新动态，学习培训，客服，广告推送，活动消息（这个一般比较常出现在平台类的b端产品中）

7.卡片式数据图表

卡片式数据图表可以拆分成图表+辅助两种组成部分

7.1图表

B端设计师需要准确通过图表来表达出用户需要的维度信息。

7.1.1折线图

随时间（连续内容）而变化的连续数据，适合表现趋势。Y 轴刻度值选择要合理，以数据波动要最大化的显示

7.1.2面积图

面积图和折线图比较类似，针对只有单个数据类型有面积区域的表达效果比折线图好。数据类型尽量不要超过2个，有2个数据类型时，注意调整面积区域的透明度以及色系保持统一

7.1.3柱状图

通常用来统计累积叠加数据，数据之间能够非常清晰直观对比。柱状图的单位宽度不要是固定值，单位宽度之间间距在不同分辨率屏幕下的对比要合理。不用大圆角元素，不够严谨，太活泼。最多使用两种颜色，一种默认，一种hover或tap，保持界面统一性

7.1.4扇形图

有共同的上一级层级作为统计总合，数据之间平级且有占比。数据必须是正整数，至少两个以上数据，且用不同颜色表示

7.1.5环形图

与扇形图很相似，但是比扇形图更加直观浏览且不被抢视觉。避免过于太细太粗，控制好留白呼吸感

以上是常用的图形图表，绝不是全部。有兴趣的同学可以到以下两个网站可以利用碎片化时间扩展学习

EChart：

https://echarts.apache.org/examples/zh/index.html

AntV:

https://antv.gitee.io/zh](https://antv.gitee.io/zh

7.2辅助元素

卡片型图表的第二部分也就是辅助元素。辅助元素里面还有很多细节元素组成：标题、轴、提示信息、标签、气泡信息、功能（筛选、导出、保存）。当然在实际设计中，会根据场景去修饰删减一些元素，以此来减少冗余信息，帮助用户快速达成目标，在最少的时间内获取更多的信息。

7.2.1标题

标题是区分卡片信息，迅速让用户了解卡片图表的重要元素。通常需要斟酌严谨不重复，简洁概括。

7.2.2轴

轴上最重要的内容就是单位，将每个数据在同一轴上都是维持同种基准。便于进行数据测量。

7.2.2.1轴的细节

现在知道了轴由哪几部分构成，那么接着了解细节

轴线

轴线细节一般只考虑是否显示，在有网格线的情况下，可以考虑隐藏x/y轴线。通常显示数据的轴作为隐藏，突出视觉重点，减少不必要的线条。

轴刻度

轴刻度是轴线上的间距不宜过密，确保信息可读性以及呼吸感，根据 7±2 法则，在可见的卡片内尽量保持这个规则，可以利用抽样显示的手段来优化轴标签重叠的问题，这种一般是在连续性内容上可以使用。若轴上单位信息确实过多，虽然是连续性内容例如展示30天单位，由于本身卡片信息不是过于最重要层级，设计在相对狭小空间尺寸中，那么建议考虑在轴线上安排滚动条，并将重看单位放置前位。设计特别注意点，将滚动条设计作为辅助元素不宜抢视觉。

网格线

网格线是用来辅助图表数据直观对比的，增加数据更快速的阅读性。举个例子：数据展示轴线在左边。那么离左边最近的数据图形可能不需要网格线就能立即对应到相应数字。但是越靠近右边的数据图形就相对比左边的数据图形就比较难一眼识别。因此网格线也担任了刻度尺的功能。在设计网格线时要注意网格线更多是辅助的角色。表现类型可以选择虚线或是实线。但是要把握好颜色选用不抢视觉重点又能看到。

7.2.3提示信息

以对照的方式来理解可视化对象的项目归类信息，总结图形形状和文本组成内容。

7.2.4标签

在图表中，标签是对当前的一组数据进行的内容标注。根据不同的图表类型选择使用。

7.2.5气泡信息

当标签默认不显示，气泡信息一般是鼠标tap或者hover时，显示该位置的数据。在简洁的页面中，也能让用户直观看到信息对应数据结果

7.2.6功能

这个模块涉及的内容偏多，在表单页面更常出现，以后有机会可以单独说。一般常用功能如筛选、导出、保存。可以让用户控制和友好的体验

确定B端产品的设计风格

首先tob的产品dashboard说到底还是给使用用户所使用，也就是“人”。所以通常情况下dashboard除了传递出用户想要的数据信息，还要传递服务于人。此外最重要的是B端设计师需要理解项目背景。例如某个财务应用平台不属于科技未来感，而是突出一种安全，高效，具有客户亲和力的商业产品特性。那么关键词：服务、轻松、高效、亲和、精致。那么一个干净、相对轻量、统一的Dashboard UI界面就提炼出来。

色彩

常说色彩是一种情绪版，在Dashboard设计中，色彩也是映射关键词的非常重要一个环节

字体

B端产品一般都是以数据为主要信息源，针对一些关键信息指标时，可以采用特殊的数字字体。由于本身数字字体包内存不大，所以也方便调用。例如DIN系列等等

设计稿尺寸

本篇内容都是针对pc端内容，具体移动端以后有机会会分享。大多数B端设计师都知道以1440x900设计，但是在工作中会以埋点数据了解到事实上真实场景还是以1920x1080的尺寸为多数。毕竟时代不一样了。以1440做设计主要还是考虑从上下兼容的角度的。B端与C端不同，C端往往照顾大多数的用户群体或是主要消费力群体。但是B端一般不会放弃任何一个用户，哪怕定制化。这个在C端是不太现实的。因此适配对于B端产品来说也是尤为重要。

设计原则

上面的内容更多是阐述每个部分的内容，实际工作中设计Dashboard时不一定按照那个顺序进行，因此在此再强调下设计Dashboard的设计顺序以及原则。要先弄清楚目标用户以及使用场景，确定好关键的大约7个核心指标。将用户整个流程梳理流畅之后，再开始考虑Dashboard设计执行。

同时在设计执行上也要特别注意几个点：

1.突出核心指标（7个左右）

2.信息层级区分

3.减少用户选择，尽可能默认给到用户需要的数据维度

4.界面简洁严谨

5.避免过多颜色与不统一

6.数据维度正确图表选择

设计的注意事项以及建议

1.tob的设计师要了解业务所处的周期在什么样的阶段。在探索期建议dashboard的设计应用于市面上现成的组件进行搭建，以便与研发团队一起为业务助力。更好更快的发展。

2.在tob的dashboard设计中，设计师要特别注意数据表现的落地效果

3.当dashboard只在设计层面改版，并且改版内容过大时，推荐保留旧版入口，提前进行埋点用户以便应对用户对于大版本适应缓解焦虑。如果有新功能或功能调整要及时加入一些引导设计，以便减少用户的学习成本。关于引导设计的内容欢迎参考我的上一篇文章：《B端必看的引导设计（一）》

4.允许用户定制和共享dashboard，虽然不适用于所有的B端产品，如果类似于团队协作中多种角色共用一套的dashboard平台，可以考虑引入这个功能。几组定制模块可以满足于不同角色的用户需求，并且能够增加dashboard的使用率

5.dashboard关键信息数据尽量设计在一屏以内，作为数据可视化，内容快速浏览获知全局，并且完成任务是比较重要的。

6. 突出统计数据的变化并对异常情况作出反应

7.数字设置不一定要设置为右对齐，但是单位是金额，那么要将金额设置为右对齐，为了使用用户识别方便，快速比较。

8.设计完Dashboard一定要自查一遍，是否真的符合工作人员的使用场景。有没有理解不准确的地方。

最后

为什么b端设计师要懂得Dashboard，在很多b端业务场景中，有个特点，设计师常常会接到大量数据展示要求。如果设计师对dashboard缺乏认知，就有很大的可能性会造成信息杂乱，并且在Dashboard的界面中充斥着一些无关紧要的指标，这就是失去了Dashboard存在的意义。另一方面在b端产品中，Dashboard往往是以首页的形式出现的,是非常重要的。

文章来源：站酷   作者：一九互七

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

接下来为大家分享一下我收集到的案例：

--网站界面UI设计--

       数字信息时代,互联网和智能手机快速发展,促使界面设计成为热门行业。中国传统文化博大精深,蕴含多种多样的中国元素。本文立足中国传统文化和界面设计,从视觉和交互角度着手进行分析,通过论证中国元素在界面设计中的优秀表现,探讨如何使中国界面设计走在时代的前沿。

下面给大家分享一些“国潮”界面

--bs界面UI设计--