首页

B端两大设计系统哪家强?

资深UI设计者

编辑导语:有效地利用 B 端设计系统,产品设计师将可以更高效地做出更好的交互设计。那么前段时间发布的 Arco Design 设计系统,和已有的阿里 Ant Design 系统,二者有什么区别呢?本文作者对两大设计系统典型页面发表了他的看法,一起来看一下。

简介

前两周字节发布了自己的中后台设计系统 Arco Design,在仔细阅读官网文档了过后,想和大家聊聊我自己对于 Arco Design 设计系统的与阿里的 Ant design 的一些对比和差异分析。

B端两大设计系统哪家强?来看这篇超全面的对比!

B端两大设计系统哪家强?来看这篇超全面的对比!

ArcoDesign 是一套设计系统的简称,是基于字节跳动所有的中后台产品。ArcoDesign 主要服务于字节跳动旗下中后台产品的体验设计和技术实现,主要由 UED 设计和开发同学共同构建及维护。

Ant Design 是阿里打磨出的一个服务于企业级产品的设计体系, 通过模块化解决方案,降低冗余的生产成本,让设计者专注于更好的用户体验

B端两大设计系统哪家强?来看这篇超全面的对比!

总览

Ant 和 Arco 两者的前端框架都是基于 React 和 Vue,设计价值观和设计原则也有所不同。Arco Design 基于「清晰」、「一致」、「韵律」和「开放」的设计价值观,试图建立务实而浪漫的工作方式。在「设计价值观」的坚持上,Ant Design 有四点与众不同:「自然」、「确定性」、「意义感」、「生长性」。

我的个人理解 Arco Design 是站在设计规范的基础出发点考虑,希望给用户传递出来的价值出发,让用户深刻感受到系统是「清晰」、「一致」、「韵律」和「开放」的,而 Ant Design 所传递出来的价值观似乎更加玄学或者说格局更高,上升到更高的思维境界,即大自然思想和社会责任。

当然这部分的内容相对比较虚,每个人侧重点想法都不同,大家可以自己去理解一下这部分内容。

B端两大设计系统哪家强?来看这篇超全面的对比!

B端两大设计系统哪家强?来看这篇超全面的对比!

B 端典型页面分析

接下来会从工作台、表格、表单几个典型高频的 B 端界面进行分析,看看两者的差别。

1. 工作台

1)布局

Arco 的卡片列布局灵活,基于 24 栅格进行布局,将整个栅格区域 2:2:1 的比例进行分割,信息卡片的宽度根据栅格宽度进行自适应,这样的工作台页面既灵活也能够满足业务需求。

Ant 的卡片列布局采用 3:2 比例进行布局,同样是基于 24 栅格。目前主流的 B 端页面都是以 24 栅格为基础进行设计。3:2 还是 2:2:1 这两种卡片布局方式没有绝对的优劣,主要是根据我们页面的信息量以及行业属性去确定。如果工作台所展示的单个信息量较多可采用少列大宽度进行布局,满足信息展示的最优布局。

作为 B 端的工作台页面,核心诉求是能够清晰找到用户想要的信息,想要做的内容,所以我们设计师要优先保证用户能够快速定位到核心的信息,快速到达要到达的功能。

2)信息展示

Arco 针对同系列的模块设计了两种尺寸的间距,例如欢迎问候信息与下方的数据信息之间是大间距,数据信息与下方的团队动态最近项目之间是小间距。

格式塔心理学的接近原则指出:接近的事物会被认为是同一个整体,拥有相似的功能或特征。所以在这里设计师通过两种间距的留白对我们视觉进行暗示,强调信息之间的关联程度,便于区分信息层级。

Ant 在卡片方面没有为卡片间距设置两种尺寸,从上下到左右都是一种尺寸,这样做的好处可以让视觉更加对齐,显得页面更加规整,不好的一点就是内容区域外间距与卡片之间的间距一样宽视觉上并没有聚焦,显得内容区域很散。标题方面没有进行加粗重色强调,将内容进行突出,使用户更加聚焦于内容。

B端两大设计系统哪家强?来看这篇超全面的对比!

3)导航方式

两个系统默认都采用侧边栏导航方式,侧边导航在国内的 B 端产品当中最为常见的。将菜单栏放置在左侧,页面布局上基本为左右结构,将导航菜单放置左侧固定。侧边栏导航扩展性强、展示灵活、能够快速定位,缺点是不易阅读、阅读沉浸感低。

B端两大设计系统哪家强?来看这篇超全面的对比!

Arco 导航区域与内容区域都使用同类浅色,采用线的方式进行分割,整体视觉比较清爽。Ant 导航区域使用了传统的重色与内容区进行区分。

目前的设计趋势流行浅色导航,有几个产品的 WEB 端进行了一系列的大改,YouTube、Twitch、Twitter 都进行了重新设计,他们不约而同地将块面去除,去掉多余的的灰色,通过留白和空间将页面拉开。这否是下一个 WEB 端所要追寻的趋势,我还不得而知,但是对于导航层级多的侧边栏导航,我仍然建议使用深色背景区分导航栏。

B端两大设计系统哪家强?来看这篇超全面的对比!

B端两大设计系统哪家强?来看这篇超全面的对比!

有一个细节,在页面背景有一个以登录的用户名形成的一个背景水印,在 B 端的页面中,对信息的保密程度要求很高,这里是为了防止公司核心数据资料泄露,在截图的时候会有水印的存在,增强了信息的保密级别,这是一个很好的设计洞察点。

B端两大设计系统哪家强?来看这篇超全面的对比!

2. 表格

1)表格样式

表格作为组织整理数据的手段,可以有效地向用户展示数据信息,是 B 端产品中出现最高频的模块之一。

用户主要通过表格浏览获取信息、对数据进行筛选、排序以及相关业务处理等更多复杂操作、对比数据的差异与变化(关联和区别)。好的表格信息展示设计,应当是能够辅助用户高效便捷地实现以上场景中的诉求。

Arco 和 Ant 的表格设计样式与市面上多数产品都类似,采用表格列无分割线条、表头与内容左对齐、数字右对齐的方式。

B端两大设计系统哪家强?来看这篇超全面的对比!

合格的表格设计要定义合理的表格行高,在具体设定表格行高时,由于表格中以文字信息为主,我认为可以参考文字排版的常用做法,将整个表格的行高分成文字行高、文字与分割线间距离,即上下间距两部分来考虑。

文字行高可以设定为字号的 1.2~1.8 倍,文字与分割线间距离可以设定为字号的 1~1.5 倍。

B端两大设计系统哪家强?来看这篇超全面的对比!

2)信息展示

表格行高决定屏幕内能呈现的行数,即用户在一屏内能获取信息的数量,主要影响用户纵向对比数据的效率。

在 B 端用户使用场景中,数据量极大的表格的展示问题是体验优劣的关键因素。对于 1920*1020(包含该分辨率)以上的大屏用户,对于一屏显示行数的感知不强,但对于 1366×768、1280*720 等这类小屏,显示行数有限,用户进行纵向数据对比的效率就会有所降低。在设计前,应当充分了解目标用户的行为诉求,了解目标用户设备屏幕分辨率的占比分布情况,有针对性的设置行高。

B 端产品的特点之一是通用化,覆盖用户角色多样。然而用户个体对于表格信息呈现密度的诉求经常是有所差异的。产品为了让不同用户都能获得较好的体验,可以考虑把表格疏密度的设置开放给用户,建议不是完全开放给用户去调整尺寸,而是给出一定阶梯度的快速选项,例如舒适、标准、紧凑三种高度来满足用户需求。

Ant 的表格功能很齐全,很多功能都是 B 端产品的痛点,例如表格可以通过调整单元格行高来调整密度,紧凑模式下可以显示更多的数据。

B端两大设计系统哪家强?来看这篇超全面的对比!

3)操作路径

作为一个查询表格,我不是很理解为什么 Arco 将查询条件放置在表格右上角这么隐秘的位置,而将明显的左上角放一个添加按钮,如果存在多个查询条件是不是要从右往左放置呢?这里我不是很理解,大家也可以说一下自己的想法,相互探讨一下。

B端两大设计系统哪家强?来看这篇超全面的对比!

B端两大设计系统哪家强?来看这篇超全面的对比!

Ant 的表格使用路径符合 F 型视觉动线布局,在 B 端的市场中这种表格的设计方式已经符合用户的操作习惯了。

B端两大设计系统哪家强?来看这篇超全面的对比!

在 2006 年时候,尼尔森诺曼发表了一篇人们如何扫描和阅读网站习惯的分享,他们通过研究发现,用户倾向于一种 F 模式去查看网站。F 模式,能很好地帮我们创建好的视觉层次结构设计,因为这是人们可以轻松扫描设计一种布局,它能让大多数用户感到舒适,因为我们用户一直从上到下,从左到右阅读。

在设计之前,我们先要去确定哪些内容最重要,明确信息的优先级,只有清楚知道你希望用户看到什么,才能将它们放在用户视线热点中。

个人认为在表格设计的完整度和设计的合理性方面来看,阿里的 Ant 系统做得比字节的 Arco 更好。

3. 表单

表单在界面中主要负责数据采集的功能,任何一个表单都可以被拆解成三个最基本要素:

标签(标题)、输入框和按钮。

B端两大设计系统哪家强?来看这篇超全面的对比!

B端两大设计系统哪家强?来看这篇超全面的对比!

1)表单布局

Arco 的表单属于复杂表单,当表单条目数在 7 个以上,可归类到复杂表单,这时候就需要根据表单的复杂度、逻辑性、关联性进行判断,选择合适的分组方式,进行归纳简化,降低表单填写负荷。采用 3 列布局,便签与文本框上下左对齐,这样的对齐方式有利于用户浏览的效率、对齐的美观以及国际化拓展页面的对齐问题。

Ant 的表单也是较为常规的布局方式,有一点差异就是文本框并没有右对齐,这里阿里自己也做出了解释:文本框是根据需要填写的字段进行长度展示的,需要填写内容比较长的文本框就会比较长。实际业务中,大部分 input 所需填写内容都存在理想长度,input 的宽度应该向用户暗示所需输入内容的长度来减轻判断负担。

2)标签对齐方式

Arco 和 Ant 都使用了顶标签的形式对齐。

标签分为左标签、右标签、顶标签三种,不同的对齐方式,使用场景不同。

B端两大设计系统哪家强?来看这篇超全面的对比!

该如何选择呢?我们需要从 3 个方面进行考虑:操作效率、标签长度、屏效、视觉对齐。

① 操作效率

根据 Matteo Penzo 的研究总结得到的浏览时间表发现,标签移动到输入框的时间,顶部对齐最快只要 50ms,其次是右对齐 240ms,左对齐耗费时间最长 500ms。

因此当以操作效率为主时,推荐使用顶对齐的方式。

B端两大设计系统哪家强?来看这篇超全面的对比!

② 标签长度

当标签长度超过 8 个字,或者需要考虑中英文双版本时,推荐使用顶对齐的方式,其容纳的标签文字更多,拓展性更好,比如 Ones 的建任务的标签,就采用标签顶对齐的方式:

B端两大设计系统哪家强?来看这篇超全面的对比!

③ 屏效

如果只考虑屏效,那么标签左对齐右对齐均可,但是如果还考虑表单录入效率,那么推荐使用标签右对齐的方式,比如蜂鸟汇报:

B端两大设计系统哪家强?来看这篇超全面的对比!

颜色主题配置

Arco 的颜色主题配置可以说是让人眼前一亮了,可调整的范围非常广非常牛逼。可以编辑的维度从基础的颜色、字体、阴影、 到组件的按钮、导航、分类、表格 一共有接近 40 款组件的样式,并且都是可以进行可视化编辑与实时预览的。

如果你用了 Arco 过后,或许不用苦苦地站在前端后面,让他帮忙调整页面,作为设计师自己就能够搞定,并且每一个组件可以调整的粒度是非常之细,包含各种宽度、图标大小、颜色、投影,等等…在这里可以编辑自己的主题,也可以在商城社区查看到别人发布的主题,真的是很方便啊。

真的有些 amazing!假如你需要去设计一套官方的设计系统,完全可以通过 Arco 进行设计和预览、落地。

B端两大设计系统哪家强?来看这篇超全面的对比!

Ant 并没有做这方面的功能,颜色主题配置这一块确实是 Arco 很大的亮点。

B端两大设计系统哪家强?来看这篇超全面的对比!

总结

无论是 Arco Design 还是 Ant Design 设计系统,都代表了字节跳动和阿里两家互联网巨头公司在 B 端领域的沉淀和竞争。对于 B 端交互设计师来说,两个设计系统都值得我们去研究和学习,建议大家都去看看设计规范里面的内容,对于我们认识和熟悉控件以及和开发对接都很有帮助。

文章来源:优设 作者:哄哄
分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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



B 端设计总结·前言:设计体系

ui设计分享达人

众所周知,黑帕云这样的产品几乎使用了所有类型 B 端的组件。

由于我司设计资源有限,所以在拥有了组件库、设计师定好了设计规范之后,作为产品经理就直接可以手撸设计稿了。

这是是前面一文《 B 端产品中,一个 Epic 基本功能设计的过程》 提到,作为一个长大了的产品经理,有时候没有资源给你做交互没有资源给你画 UI 的,你要自己学会自给自足。


这个系列就是作为产品经理的我,在这两年中“自给自足”做设计的的一些总结与发现。

自给自足的前提是,前面说的组件库和设计规范,即拥有一个设计体系(Design System)。


01.什么是设计体系?

关于设计体系的定义和内容各家都不同,我找出来了以下案例供参考。


《设计体系:数字产品设计的系统化方法》

Tilio(一个写作和笔记应用)联合创始人,有十年 UX 设计经验的阿拉·霍尔马托娃在《设计体系:数字产品设计的系统化方法》一书中这么定义:

设计体系是为了实现数字产品的目的而组织起来的一套相互关联的模式和共享实践。
模式指的是界面中那些重复的要素:用户流程、交互方式、按钮、文本框、图标、配色、排版、文案,等等。
实践则是我们如何创建、捕获、共享和使用这些模式,尤其是在团队协作时做这些事情的方法。


书中将设计体系分成以下几个部分:

设计目的、设计原则、组件库、样式指南,以及用于提高设计师和开发人员沟通效率的工作流程和实用工具。


整理之后,可以参考下图:




Salesforce:Lightning Design System


Material Design


可以发现,以上设计体系无论如何定义概念,都是由设计原则+设计指南+一些基础的元素(比如 Design Token、Material Foundation、Icons)+组件库+其他资源工具构成。


形成这些内容的目的都是为了给自己产品建立一套保证设计质量、提升设计决策、提升沟通效率的“工具包”,从而让产品形成自己的符合设计原则的风格。


所以设计体系是什么不重要,重要的是如何在遵循设计原则下,能够高效做出高质量的设计。



02.设计原则(Design Principes)

一个开源设计原则和方法的网站 Design Principle 这样定义设计原则:

Design Principles are a set of considerations that form the basis of any good product.

译为“设计原则是构成任何好产品的一套基础考虑因素。”


比如 Salesforce 的设计原则是:清晰、高效、一致、美观。并且优先级由前到后。


可以理解为 Salesforce 会追求清晰大于高效、一致、美观,比如在产品设计中,让用户清楚的看到、理解、自信地去操作要比任何事情都要重要。

这个准则很容易理解,可以推论出 Salesforce 在度量体验时,将“易用性”放在了第一位,即作为一个 SaaS 产品,不能有任何让用户产生疑惑的地方。如果在设计上的美观而要牺牲清晰,这就是不可取的。



03.组件库

有了设计原则之后,下一步是需要一个组件库。这里说的组件库囊括了无论是原子化的颜色、字体、阴影、Icon 这些基本的元素,还包括了已经封装好的组件,如 Button、Alert、Toast、Text Input。


关于为什么要组件化,也不多说了,之前看过一篇阅文体验设计 YUX 的《组件化思维—— 适应并推动业务及产品变革的设计案例》写的非常清楚。

接下来我通过 Minecraft 这个游戏来总结了组件库。

玩过生存模拟类游戏大家都知道,在游戏中会有一些可以靠双手劳动得来的基础材料,比如砍树砍来的木头、地上捡的石头、挖矿挖的燧石。这些基础材料可以合成一些简单处理过的材料,比如把木头合成为木板。然后可以再把半成品进一步加工,比如木棍。


在 Minecraft 这个游戏中,如果玩家要制造一个弓箭,需要一个弓和一个箭。弓和箭的合成又需要一些半成品和成品或者原材料来加工制作,如下图:


对应在设计组件库中可以对照查看,一个完整的页面是可以通过一些元素、控件、组件、大组件组成:


04.适用人群

在系列开始之前,先声明一下文章的范围和适用人群。

关于 「B 端设计总结」这一系列,主要是我个人在已有了我们的设计规范和组件库后,“自给自足”的情况下探索出来的一些组件使用规则,更偏向产品经理或者交互设计师来参考。

所以系列中不会写设计规范,比如说字号、颜色、间距等等这些属于设计规范中内容。而是基于已有的规范,总结之前我们功能中涉及到的该使用哪些组件,也可以称之为狭义上的设计指南(Design Guidelines)或者设计模式(Design Patterns)。

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷 作者:高拉

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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



B端数据可视化组件设计规范:平台级项目复盘

ui设计分享达人

关于数据可视化项目


在贝壳,有店东、圈经、CA等多种服务角色依赖数据信息作业,各种各样的数据被用于管理、分析和制定目标。但是,房产垂直领域的数据非常庞杂,数据体量也在急剧增长,图表的应用场景越来越复杂,除了pc和移动端的数据看板,还出现了线下门店大屏场景。


与此同时,数据展示一直处于无可视化规范的状态,导致频频出现“数据堆叠”“数据出界”“数值无单位”等可读性低的问题。因此,把这些复杂、抽象的数据,通过更直观更容易理解的可视化方式展示出来,建立一套专注于房产领域的可视化组件规范,变得尤为重要。


图1 数据部分展示现状


Kecharts项目从汇总和梳理数据展示问题出发,聚焦并抽象问题点,旨在建立起统一的可视化规范。同时,我们还对极端数据的展示进行计算规则处理,从人工配置的效率考量,系统性地帮助用户进行高效分析和决策。


1.从不统一到有规范


数据规范的第一步,解决“知道什么数据用什么图表,了解颜色的使用规范、数据排版展示的要点、适配性原则”等基础规范,从配色、布局、基础展示规则上,满足数据展示的美观度和可读性。



2.极端情况的处理规则


最难解决但也最有价值的痛点是:数据体量大、维度多带来的“不确定性问题”,想要把海量、高维的数据以准确有效的方式展示,需要建立高质量的交互和配图规则。因此,我们在梳理基准展示规范的基础上,也对极端情况进行了一系列的规则处理。



3.人员可配的高效性


数据往往是由平台自上而下传达到城市,再由专业的商业分析师对数据进行分析和处理,很多数据需要人工绘制和展示。因此,Kecharts在设计数据规则展示的同时,也要考虑数据的可配置输出规则,尽可能减少人工操作成本,降低由于人工分析水平不同导致的报告质量方差。



一、建立图表可视化

基础规范


建立基础可视化规范,是为了将图表展示拉到基准线水平,也是当前要做的第一步。基础的规范建立,可以让图表迅速换身衣服,第一时间提升用户的感受。所以,第一步首先解决配色的使用、基础的布局、图形的基本表达等方面的规范问题,满足数据的基础美观度



1. 配色

更科学的配色带来崭新的视觉感受


图2 配色色板图示(局部)


优化前,Kecharts各种配色之间关联性低,与整体平台的表现层形式不统一。优化后色板的样式与KeDesign贝壳设计系统,“UXD笔记”公众号后台回复“贝壳”,领取VI规范文档)无缝融合。现有配色方案饱和度更协调,阅读体验更友好。


由于数据体量大,我们尝试将8种常用色扩展成10种常用色以及24种扩展色来更好地满足业务需求。并且根据不同品牌主色,进行明度调整。除此之外还增加了更沉稳的商务主题以及暗黑主题配色,满足特殊业务场景的使用。


图3 配色的概念图


2. 布局

更合理的布局带来清晰准确的表达


基础布局

图表的构成,由一系列独立的图形与法元素结合而成,如包含标题区、操作功能区、面包屑、图例区、单位区和图表区,通过合理的基础布局增强图表的秩序性一致性,同时规范标题、图例等元素的展示适配规则。


图4 数据基础布局规范(局部)



精细图形

整体的图形展示细节也做了统一调整,从整体排布、字体、字号、圆角、描边粗细、数据轴、标签等方面进行了优化设计,使整个图表看起来更加精细。


基础的配色、字号、布局调整之后,基本满足了数据的展示基准,从基础合理性展示和视觉感提升上,有了一定的改良。


图5 基准规范后的对比



3.适配

更灵活的规则带来细腻的交互体验


图6 栅格化设计图示



定义图表的适配规则

定义四种图表卡片的适配方案,当图表放大或缩小到某一区间时,内部布局会根据图表大小变化进行有权重的删减,使图表在多种区间内能够将核心数据表达的更清晰。


图7 栅格化设计图示



二、极致探索

极端情况规则


满足了数据的基准展示,并没有达到完整的可视化展示规范,海量和高维带来的展示问题依旧存在。所以,在建立基准规则的基础上,结合贝壳数据的特色,需要集中处理极端情况带来的问题,从基准线提升到具有易用性的“标准线”。

图8 以饼状图为例的极端情况分析



1.解决数据量过载

导致的不确定问题


过滤数据

首先从底层数据进行过滤,过滤底层占比0%的数据,减少数据呈现量。将占比为0%的大部分数据在图表的可视化展示中去除,转移到图例中展示,满足了用户需要完整数据的诉求外还大幅度提升了图表的可视化程度。


元素优化

优化标签、线条、指示等元素的展示规范,从定义边界位置、规范标签的展示内容上,对图表内元素的极端情况做适配处理。


智能检测

为了消除信息过载带来的标签碰撞,我们制定了标签的智能检测规则,当两个标签重叠超过1/3时,自动化地隐藏部分标签,被隐藏的部分可以通过悬停展示详细信息,不经意间大幅度的提升图表的展示美感和用户的浏览体验。

图9 饼状图为例的处理过程


2.拓展通用性极端处理规范


从单点问题扩展为通用性规范处理,在不同类型图表的极端情况处理过程中,从全局的角度出发,对极端情况下出现的核心问题做汇总并抽象,在颜色、碰撞、超图形等方面,输出极端情况处理规范。


图10 通用性智能检测规则(局部)



三、提升人工配置

的高效性


数据分析和传达的过程,依托于人工过滤、处理、绘制和展示,考虑数据的配置输出,人为水平难以把控,尽可能减少人工不必要的操作成本,从而提升数据报告产出的质量。


在配置自由度时结合产品定位、属性和功能进行思考。用户希望数据通过配置层处理后转化为可视化图表。普通用户期望通过简单的操作快速搭建数据看板;高级用户希望对可视化图表有精细化的自定义需求。


我们尽量用智能处理代替人工对数据无效数据的筛选,对数据的展示做智能的适配,如指标卡的展示,前置设置了一系列的展示模版,在用户选择指标数据的同时,会根据指标的数量做自动化贴合排布。与此同时,保留了一定的人工可配置自由度,支持用户可自由配置指标卡的细节展示等。

图11 指标卡用户配置示意



因此,针对大量杂乱的数据,数据的呈现通常需要两层呈现给用户。第一层是数据库和数据源,会自动过滤掉存在的垃圾数据和无效数据


第二层是数据分发层,尽可能的通过自动化的配置去辅助操作员进行数据的分发和最终数据面板的呈现效果。通过简化操作流程和匹配人为操作习惯,降低学习成本,提升操作效率,为操作者提供“顺其自然的设计”。


图12 数据处理分层图示



结语


Kecharts的初衷是保证数据的真实、高效展示数据、遵循美学原则。我们遵循数据能够真实呈现的原则,在可视化表达中确保不遗漏、不误导,确保数据准确性

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷 作者:大魔V

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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

B端设计规范

资深UI设计者

1.准备工作


设计工具

Sketch

精不精通Sketch,就看插件用的溜不溜,推荐个网站:http://sketch.cm/

无论是学习Sketch,还是搜插件、找素材,都是Sketch使用者的优选项。

Sketch是OS X平台独占,需要下载Sketch可以到这个网站去下载。

这里推荐个Mac平台应用的下载网站,使用Mac的小伙伴可以去这里下:http://xclient.info/

我个人是很推荐使用Sketch做UI设计的,软件本身已经提供了大量的IOS和Android系统设计资源,配合各类插件,几乎无所不能。



Photoshop

相比于Sketch来说,体型胖了点,在UI设计上略逊一筹。不过因为Sketch是OS X独占,所以因为平台限制的原因,用PS设计也没有问题。

我很久没用它做UI设计了,也没啥可推荐的了。



Adobe XD

全称为Adobe Experience Design;这是一款集原型、设计和交互于一体的小清新时代风格的设计软件。虽然有人说,Adobe XD将会是Skech的劲敌。然而在windows系统当中,Adobe XD的确是产品原型设计领域最顺手的设计软件。它使用简单,界面整洁,虽然之前一直使用的是Axure 8.0,但看来,Adobe XD在界面、素材以及设计操作上的确甩了Axure好几条街,至少它成功的吸引到了我。



做好版本管理、文件归档的工作

专业水平不仅体现在设计能力之上,优秀的管理能力也是重要的职业素养。

合理规划好设计版本,进行明确的文件归档工作,有助于提高设计师的工作效率。

这里不赘述了,每个人有自己的版本管理方式,不过目标只有一个:清晰高效




2.关于手机的基础概念

这里的概念性内容不要强行记忆,理解即可,它是做移动UI设计的理论常识。


手机分辨率

手机屏幕的像素点数。比如750*1334、720*1280等等,细分还有物理分辨率和逻辑分辨率,这里不扩展讲解了,想了解自行百度吧。

手机分辨率牵扯到的就是工作时设计稿的尺寸,只要记住设计尺寸就可以了。


屏幕尺寸

手机对角线的物理尺寸,单位是英寸。IPhone 6/7/8的尺寸就是4.7英寸……

屏幕尺寸和设计其实关系不大,主要是用来计算屏幕密度的。


屏幕密度(DPI或PPI)

每英寸的像素点数。简单理解就是屏幕密度越大,画面越逼真细腻。

下面是屏幕密度的计算方法,范例是5英寸,分辨率为1920*1080的手机:



屏幕密度牵扯最多的是安卓系统,安卓手机屏幕本身的密度种类非常多,这也是导致了安卓系统需要提供多套切图的原因。(使用SVG格式图片可以解决多套切图和适配的问题,这个我们下面会提到)




3.基础设计规范——IOS系统

这是苹果的开发者官网:https://developer.apple.com/

这里有持续更新的最新设计规范和资源模板,虽然是全英文的,但并不影响阅读。

设计师应该学会从官方获得设计资料,这比其他途径获得的资料更加全面和权威。


最新系统版本:IOS 11.4.1

中文字体:苹方黑体

英文字体:San Francisco

官方系统设计模板下载:

https://developer.apple.com/design/resources/


官方系统设计字体下载:

https://developer.apple.com/fonts/


下图是截止到目前,可能还需要支持的机型和对应的设计尺寸:




设计稿尺寸

只推荐750*1334的尺寸来做设计稿,这是向上向下都最容易适配的尺寸,包括用这个尺寸去适配Android版。

除了IPhone X的比例特殊外,其他的IPhone比例几乎差不多的,比较容易适配。



Sketch设计

使用375 * 667尺寸即可,开发在Xcode里也是使用这个尺寸。

导出的@2x图适配IPhone 5/5S/5C/SE   6/6S/7/8

导出的@3x图适配Iphone 6/6S/7/8 Plus    IPhone X



Photoshop设计

画布就建成750 * 1334尺寸的即可,在这个前提之下,

导出原尺寸图片加后缀@2x,适配IPhone 5/5S/5C/SE   6/6S/7/8

导出1.5倍图片加后缀@3x,适配IPhone 6/6S/7/8 Plus    IPhone X



常用数据

下面的内容苹果官方提供的模板文档其实都有对应的数据,可以去官网下载。


字号使用建议(这个不是硬性规定,根据视觉效果酌情使用)

导航文字            34-38px

标题文字            28-34px

正文文字            26-30px

辅助文字            20-24px

Tab bar文字       20px



图标尺寸建议

APP应用图标,建议使用1024*1024尺寸去做,逐级缩小去应用到各种场景中。

SKetch已经提供了IOS和Android系统的APP尺寸图标模板,直接使用就可以了。


界面适配

程序内部的功能界面:这种界面通过写成自适应的界面可以很好的适配各种机型;如果有特殊的布局要求,也可以让开发根据特定机型去调整,不需要单独为各类机型再做设计稿。


覆盖全屏类的界面:比如闪屏、启动页、引导界面、插画页面等等,这类覆盖全屏的界面必须要单独为IPhone X的比例重新绘制或者调整设计稿。

其他的IPhone机型,遇到这种界面,整体放大缩小、微调之后按照各机型的设计尺寸输出对应的切图就可以了。


IPhone X的安全区域:IPhone X的安全区域就是扣除顶部刘海状态栏和底部虚拟home键之后,中间的内容显示区域。如果你不得不使用IPhoneX的尺寸做设计稿,请一定设置好参考线,不要把内容做进这两块区域内部。

IPhone X规范:iPhone X 人机交互指南及其设计细节



简单理解APP构成

下图是IOS开发工具Xcode里的一个空白页面,图片的文字标注请仔细阅读。

本质上,开发写APP界面和设计做设计稿是一样的,只不过两者实现方法不同。



APP的构成远远要比上图写的复杂的多,我们这里使用最简单的理解方式。



设计稿的标注

根据上图我们可以理解设计稿和程序之间的关系:

设计稿里的按钮、文字、图标、列表、背景色、线条等等所有的设计元素,

在Xcode里都有对应的控件,设计元素必须使用对应控件,才能在APP的界面里显示出来。


设计稿的标注,实质上是标注的各类控件的属性以及相对于其他控件的关系:

设计稿中:

文字的自身属性:颜色、字号、字体、行间距、对齐方式、透明度;

图片的自身属性:宽高、间距、距离、透明度。

至于标注在上篇文章有详解:一款APP从设计到切图标注适配全记录,这里就不累赘了!




程序的对应控件

Label的自身属性:颜色、字号、字体、行间距、对齐方式、透明度;

Image View的自身属性:宽高、间距、距离、透明度。

实际上各类控件的属性也要比这个复杂的多,这里是最简单理解的举例说明。


如今使用本地化插件Sketch Measure,几乎不用手工标注,标注导出HTML后,扔给开发,他们想看什么属性自己点击查看就是了,所以我们这里了解下标注原理就行。

而一些线上工具的插件,比如蓝湖、墨刀、Mockplus等等,功能更加丰富,各位根据自身情况灵活运用吧。

Sketch Measure去http://Sketch.im下载





设计稿的切图

IOS目前常用的还是输出2套PNG图片。@2x、@3x的后缀,是为了在Xcode导入图片资源时,识别对应机型所用的图片。

Xcode里提供了相应的位置,相同命名图片会根据后缀填入到对应的位置。



目前Sketch提供了PNG、JPG、TIFF、WebP、PDF、EPS、SVG格式。

但是对于UI设计来说,常用的图片格式就以下几种:


PNG      常用图片格式,没什么解释的,目前大部分产品还在使用此格式;

WebP    安卓的图片格式,同等质量图片下体积非常小,非常推荐给安卓使用;

SVG      矢量格式,完美解决适配问题,但也有部分缺点。

想具体了解WebP和SVG,可以查看之前的文章。



切图输出规范

前提:同一类型、位置的切图,请保证切图尺寸、规格一致,图片尺寸为偶数大小。


1.有操作功能、可点击的功能性切图:最小点击区域问题

苹果官方提供的能准确点击的最小点击区域:88 * 88px;

小于这个范围也可以点击,但是点击不灵敏,体验较差。

对于比这个范围小的可点击按钮,周围需要用透明区域填充后再输出切图。



解释下为什么用透明区域填充来扩大点击区域范围:

图标这东西,对设计师来说没区别,都是图片。

但对开发来说,可操作和不可操作的图标是两种类型的控件,图标的样式不过是传给该控件的显示图片罢了。


可操作的功能图标在Xcode对应控件是UIButton。

对控件来说,如果不在代码里明确固定控件的大小、点击区域等等各类属性,设计师传给我多大的图,这个控件就会被这张图撑到多大。


你给我一张40*40的按钮切图,如果开发什么都不做,那这个UIButton在手机界面里就被撑到40*40的大小。

我也可以在Xcode里写几行代码,固定图片的大小就是40*40,扩大UIButton这个控件的大小变成88*88,这样这个控件的点击区域也扩大了。


但是一张规范的切图就能解决的事情,为什么还要在代码里再手动加几行呢?

一个可点击按钮需要加一行代码,整个APP就可能多加上百行上千行的代码。


规范的切图也是可以提升产品开发效率的。


2.非功能性切图,比如列表图标、说明图标等,按统一规格的最小尺寸切。

这么切还可以减少一些程序因图片资源大小导致的体积大小问题。



这类切图,对应的是UIImageView控件,就是一张图片,无操作,只是占位和显示。

所以你按照相同规格,最小尺寸切就可以了。


有朋友问:一定要切正方形的吗?如果图标都是30*20的,那我统一切30*20的行不行

答案是:可以,这个没有完全的硬性规定。虽然我是设计师,但也会去写一些IOS程序。正方形规格切图就是为了方便开发,当然还是推荐你使用正方形规格来切图。

但实际开发过程中,只要保证同一位置,切图规格统一就可以。


切图输出状态:

同一按钮、元素的不同状态,要明确命名对应状态之后,分别输出对应图片。

下图示例按钮的选中状态多出现在游戏APP中,这里仅表示说明。




命名规范

不要使用中文、特殊字符,请使用英文、下划线、数字对切图命名,数字不要打头。


命名方式尽量清晰,推荐采用:种类_位置_功能_状态

示例说明:

btn_homepage_seach_normal@2x.png


开发看到就会明白:这是位于首页,处于正常状态的搜索按钮2倍切图。



4.基础设计规范——Android系统


这是Android Material Design中文版的地址

https://www.mdui.org/design/


Android的英文版地址

https://material.io/


最新系统版本:Android 9.0

中文字体:思源黑体

英文字体:Robot


Android不整理各类机型的尺寸规范了,数据零散,难以整理。所以我们从屏幕密度这里理解设计规范就可以了。


Android手机屏幕密度

上文我们提过屏幕密度的计算方式,安卓手机因为各种屏幕尺寸和分辨率,导致如果单纯按照数值计算,可能屏幕密度种类会多到让设计师崩溃。


所以为了解决这个问题,安卓手机出厂时,屏幕有自己初始的固定密度,系统会根据这些屏幕密度自行适配,下图是对应的屏幕密度表:




Android的开发单位以及设计尺寸


正因为Android手机分辨率多样,为了保证同一设计在不同屏幕密度的手机上显示效果一致,Android系统使用了下面两个单位:

dp:android开发单位,相当于比例换算单位。使用该单位,可以保证控件在不同密度的屏幕上按照比例解析显示成相同视觉效果;

sp:android开发文字单位,和dp类似,也是为了保证文字在不同密度的屏幕上显示相同的效果。


当屏幕密度为MDPI(160DPI)时,1dp=1px

当屏幕密度为MDPI(160DPI)时,1sp=1px


按照上面两个公式的换算,同样dp大小的图片在不同屏幕密度的手机上如下图所示,

基本可以保证图片显示效果在各类手机上相同。




设计稿尺寸

通过上面的分析,在xHDPI这个密度等级下,倍数关系为2,推荐使用720*1280尺寸做设计稿,换算方便,适配容易。


不过目前的现状是,如果公司的产品有IOS和Android两个版本,基本上设计师只会做IOS的版本,然后套用给Android,这样做也是可以的。两者的切图,在这个设计尺寸之下是可以通用的。



设计稿的标注

推荐使用dp和sp进行标注。但是呢,如果你用720*1280做设计,使用像素单位标注,现在也不会影响什么。

因为前面已经提到过IOS的标注了,这里也就不再赘述了。



设计稿的切图

理论上,对于Android系统来说,如果你想完美适配各种机型,应该为不同的屏幕密度提供不同尺寸大小的切图,而Android的开发工具也为不同的屏幕密度提供了对应的资源文件夹。


但实际上,并不需要提供上面密度表那么多套的切图,程序安装包的大小基本就是由于图片占用了太多的位置。

所以需要提供多少套图片,请和公司的开发沟通,确定你们的产品实际支持哪些屏幕密度。



图片格式

WebP和SVG

我个人是推荐现在为Android系统使用WebP格式,体积小,显示效果好;

而SVG这种矢量图片格式完美解决了Android多套切图的问题,一套切图,完美适配各种屏幕密度。



最小可点击区域

48dp:这和IOS的最小点击区域性质是一样的,都是考虑到手指点击的灵敏性的问题,设计可点击控件的时候要考虑到这一点。


更多的注意事项和IOS切图是相同的,这里不再赘述了。




5.UI设计师的职业道路

如今的移动UI设计行业已经很成熟了,针对移动UI设计的便捷工具层出不穷;移动UI设计的理论体系知识也已经渐渐完善。但这些都是外部因素,社会发展了,我们跟着一起向前适应就好了;


但对于设计师工作能力的提升,还需要有明确的方法体系,更要有清晰的职业规划!

很多设计师工作了几年,却一直在原地踏步,苦苦挣扎,甚至没有职业目标。


目前我工作5年,就从我自身的体会来分享我自己的方式,当然资深的、精英设计就别跟我较真了,我代表的是那90%还在向上努力爬的普通设计师~


工作能力,不仅仅指的是自身的专业技术水平,还包含了各种综合性能力,请务必对自己有明确的职业规划和能力发展轨迹。



工作0~2年

这个阶段对于新人来说,是一个设计能力和工作经验的快速积累过程,不夸张的说,这两年内的经验可以决定你之后的职业发展道路是否顺利。


此阶段目的:提升设计专业能力、完善理论知识、积累实际项目经验

这个阶段就别想着一专多能了,先把那个“一专”搞好就可以了,当然不是不让你学习别的知识,而是说重心应该发在提升目前的专业能力上。


提升设计能力:

一方面,通过公司的实际商业项目提升能力,这个没什么可说的;


另一方面,业余时间务必进行大量的作品练习,无论是临摹、还是重设计都可以,目的就是一个:量大 从优!

临摹请用高质量作品,临摹一堆垃圾还不如不做,临摹请务必做到99%以上的相似度,不然那不叫临摹,临摹的过程是考验软件功力、设计技法能否完美复制的过程。


重设计请使用成熟知名产品,不要重设计一堆垃圾应用,成熟产品每个界面的布局、样式、功能、逻辑都是经过深思熟虑后呈现给你的。

重设计的目的是要体会产品背后反映的设计意图,不是为了重设计而重设计。

所以重设计之前请自己思考原产品这么做的目的再动手。


完善理论知识:

没有理论体系方法的支持,在设计道路上是走不远的。

现在关于UI设计的知识网站已经很多了,当然不局限在这类专业性网站上。

人人都是PM、UI中国、25学堂等等很多这类网站都是学习理论知识的好地方。

当然,你也可以关注我嘛~(给自己打个广告,吼吼~)



工作2~3年

3年对于互联网从业者是一个坎儿,其实这是相对于职业规划来说的。

通过前两年的积累,对于UI设计本职工作已经可以胜任了,接下来的要考虑的是个人的职业发展规划了。


此阶段目的:拓展技能、明确职业目标、为进大厂做准备


拓展技能:

这个阶段可以考虑“一专多能”的多能了,作为UI设计师,可以学习的东西实在太多了,交互、动效、产品设计、开发等等。

不要求你达到那些专业从业者的地步,你要学到专业程度,还干什么UI设计啊。

目的是为了拓展自己的技能树,为自己提供更多的竞争力,这个习惯要一直保持伴随之后的工作……


明确职业目标:

设计师最怕的就是迷茫,如果说前两年因为刚入行,对行业,对自身都不完全了解,那情有可原。但工作两年后,对自身的情况再不清醒那就说不过去了。


可以从以下方面考虑:

是始终坚持在一线岗位的设计技术大牛,还是想做设计管理者,亦或者想从UI设计师转职成交互设计、产品设计等等。

工作两年已经对自身,对行业有理解了,自己的能力是否适合设计岗位,对设计的热爱是否能经久不变都可以作为参考调节了。


为进入大厂做准备:

刚工作,可能限制于能力实力问题,委身于小公司。

但是!虽然我们身在小公司,但心要在BAT CAO  TMD,

Apple、Google也不是不可以!

Skr!Skr!


这阶段可以为大厂准备一下,当然不是让你工作两年多就去面试啊,如果你的能力特别突出,就当我放屁吧~

意思是,可以以进入大厂为目标,综合性的考虑自身的缺陷并尽量弥补。


千万别以为就在小公司将就着干吧,反正拿的钱也差不多,大公司的滋味你是体会不到的。

拿同样的薪水,在小公司和大公司的感受可是完全不同的,小公司对个人的眼界、人脉、能力提升的帮助都不可能和大公司相提并论。




工作3~5年


对互联网人来说,3年一个坎,5年一个坎,都是职业规划的节点时间。

3到5年的设计师,如果你真的用心工作了,一个人可以实实在在的顶起来一个项目。

我们上面说,为进入大厂做准备。在这个阶段,可以考虑进入一些中大型企业,提升个人的综合能力、拓展人脉。

部分企业也比较喜欢要这个阶段的设计师,有工作能力,职业道路又刚开始,搞不好可以在公司培养起来。


此阶段的目的:提升综合能力、拓展人脉圈子

这时的个人专业水平其实已经不是问题,继续在工作中磨练积累就可以了;

这里需要的是打开个人在职场上的道路。

说实话,即使是互联网行业,搞技术除了要保证自身技术过硬之外,会不会发展人脉,能不能提升综合能力才是最后职业道路能不能走远走高的决定因素。


提升综合能力:

与各部门的沟通能力、对设计资源的协调能力、在公司业务上的话语能力、对项目的把控能力等等,都算综合能力,这是对内部的能力。

不要以为对设计师来说,我闷着头接需求,做设计就可以了。

这样的设计师,也许你可以踏踏实实当个接需求的小设计,但你永远也只是一个这类的设计,对于有更高更强的职业追求的人来说,没有帮助。

所以,张开嘴、迈开腿,一步一步尝试去推动自身进步吧,这个没什么技术性方法,必须要自己亲自去做。


拓展人脉圈子:

人脉对个人职业道路的帮助,远远要比专业能力的帮助要大的多,这是对外的能力。


设计师的圈子,说实话不算大。搞技术的,本身就坐办公室,而做设计的人本身性格也有一部分原因,但还是请你努力拓展自己的人脉。


对于自身的专业圈子,努力分享自己的设计经验、工作心得,总结自己的体会,发布到各类设计专业论坛上,积极的帮助别人,这都算一种拓展方式。

时间久了,就会结识非常多的设计界朋友,设计大牛也会逐渐注意到你,这些都是你职业道路上的宝贵资源。


还可以认识几个不错的猎头朋友,有好的职位,他们都会优先想到你的。


作者自述

这也是我写的最后一篇关于基础规范类文章,也算是整理一下工作到现在的基础常识类内容,以后不再写这类基础文章了。

人总要进步的,设计师还是要靠干货作品来撑腰的,对吧。

以后发的内容都是我做过的实际商业项目,我会把设计经验和工作方法融入到这些作品实例里来写,这总比我单纯讲理论知识要强。




文章来源:站酷 作者:Z085740511 

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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


B端产品界面高屏效初探

ui设计分享达人

背景

在 B 端设计领域中,不管是内部用户、产品、设计师、开发,还是外部产品、设计师等,总能听到关于界面「屏效」方面的诉求或吐槽。


undefined


「屏效」狭义理解是「界面过度留白」;广义理解,「屏效」源自谐音“坪效”,指的是每坪的面积可以产出多少营业额(营业额/专柜所占总坪数)。而「屏效」对于界面而言可以指屏幕单位时间、单位面积内的信息可以带来多少商业效益/效率提升。


为了探索在 B 端产品中用户为何对「界面过度留白」或「屏效」问题如此敏感,于是我们展开了「屏效」专题的设计探索与实践。「屏效」专题探索主要以「探索」与「实践」相结合的方式展开,将实践过程中反复验证有效的设计策略沉淀成设计手册,同步将部分功能进行工程化,确保可以开箱即用。


undefined


探索阶段-为谁在何时何地设计

用户声音|不同的故事相似的诉求

面向内部设计师和终端用户投放的《高屏效诉求》《中后台产品满意度调研》问卷中认为提高屏效能极大提升用户体验的设计师占 58.14%;认为提升屏效对体验有提升的终端用户占 50.6%。


undefined


外部知乎上针对《Ant Design 4.0 设计价值观》的 13 条反馈里,其中就有 2 点提到关键字「效率」。


undefined


通过了解不同用户和产品类型发现,不同的用户在工作场景的产品使用中有着相似的特征:


undefined



案例收集|发现问题,大胆假设

纵观 B 端产品界面,发现普遍问题和收录在解决屏效问题上实践得比较好的案例,为了逐步突破问题,选择以数据产品中覆盖率极高的表格为设计切入点,通过线上跨产品多端地毯式的体验走查,发现表格三个层次的问题:


undefined


视觉、交互层在无需理解业务场景和用户目标的情况下,都较容易发现,属基础问题,但很多「过度留白」的屏效问题往往是信息被组织方式的差异导致的「过度留白」。

综上我们提出假设:为提高屏效,可从视觉、交互、信息三个层次解决

视觉层为提高信息查阅速度,可以通过提高信息密度;交互层为提高操作速度,可以缩短当前手势到目标之间的距离;信息层为提高信息被理解的速度,可以通过重组织等方式。

基于假设,我们进行了进一步的桌面研究,查阅论文等书籍,寻找设计理论的验证和指导。


竞品分析|寻找实践证据,谨慎验证

我们知道视觉上界面留白过多(过疏会增加滚屏成本,过密因易串行而影响阅读效率),以表格「行高」为例,探索各表格在字号、字高和行高的关系,因为不同字体的同字号实际像素高度会有差异,因此选择的是字高(即文字垂直高度的视觉大小)而非字号或字行高,决定留白的两个重要因子是字高和表格行高,以次推演,界面元素和元素间距的留白关系,探究在视觉层怎样的留白率能保证甚至提升屏效。


undefined


以数据产品中的表格为例,通过直接和间接竞对的方式,分别从数据的查阅(视觉)、分析(交互)维度进行功能点和设计细节上的比对,来看看优秀产品是如何解决屏效问题。

直接竞对:内部用户口碑较好的产品 A、B外界竞对:同领域的 Tableau、网易有数、金山、微软表格;间接竞对:谷歌邮箱、AntD 等的紧凑主题的常规列表(一维表格)


undefined


通过竞品分析可以发现,数据分析领域的表格留白率普遍较低(信息密度高),尤其是金山和微软的电子表格,其次是同类面向数据用户的 Tableau、网易有数,而谷歌邮箱等工作台常用的常规列表紧凑版本中,留白率和数据领域的电子表格不相上下。


紧凑版的使用场景也常常是面对数据量巨大的信息呈现,通过切换紧凑主题,提升信息的快速浏览,而这也非常适合数据分析场景中巨大的数据量呈现。因此我们的产品在留白率的提升空间极大,而在实际案例实践中,也已经将表格行高优化至 30px,克制的使用留白。


除此外,竞品其他层次的设计也做了比对,总结来看整体设计做法:高密度、少屏数、少留白等。


文字陷阱:中英文字高不等于字号


举个容易犯错的竞品参考是,谷歌在紧凑版主题下字号 12px,列表行高是 28px,但在 AntD Table 中同样的 12px 和列表行高 28px 就会发现非常拥挤,缺乏呼吸感。


undefined


原因在于谷歌的 12px 是英文字体,实际字高只有 10px,而 AntD Table 的语境是中文字偏多,实际字高有 12px,所以留白的差异在于一个是 18px(28-10),一个是 16px(28-12),这也是为什么决定决定留白的两个重要因子是「字高」和表格行高,而非「字号」和表格行高,进一步推演,决定界面留白的是「元素视觉高度」和「元素间距」。


论文查阅|寻找理论证据,谨慎验证

研究表明,低密度认知负荷低,但高密度任务完成率高,用户更喜好

参考资料:论文《基于眼动的网页对称性和复杂度对用户认知的影响的研究》

对于信息,用户需要需要阅读(视觉),思考和理解(认知),需要点击按钮、操作鼠标和打字(行动),在人机工程学中,统称为负荷。即认知(记忆)负荷、视觉负荷、动作负荷,即分别对应用户体验设计的三个层级,信息/视觉/交互。而负荷所花费资源从多到少依次为:认知 > 视觉 > 行动。


认知负荷,举个例子,看了但不一定懂了。你是否有这么一种体验——刷抖音,虽然很多(信息密度小,输出效率低),但可以一直刷下去并且刷很久;而看一门 C4D 教学视频,即使就短短十来分钟(信息密度大,输出效率高),但是却要看上半天。因为刷短视频时,你的输入效率远高于作者的输出效率,而看一门 C4D 教学视频时,你的输入效率远低于作者的输出效率。可是,输出效率是客观的,输入效率是主观的。如果输出效率很高,你可以通过提高自己的输入效率(比如让自己成为 C4D 专家)来跟上作者,从而变强;否则输出效率很低(信息质量低),你的输入效率很高(很专业),信息于你而言都是无效的。


假设负荷总量不变的情况下,那么以上三类场景界面需要对用户负担分配大致如下,官网品宣类需要低认知成本,低视觉负担,视觉要求高,用户才会被吸引过来阅读,甚至酷炫的交互更能增加互动体验而带来的趣味感,比如苹果官网,信息量极少、图版率高带来极具艺术的视觉体验、进而吸引用户愿意跟随屏幕滚动渐进式接受信息,而 B 端应用因为是专业使用,首先认知方面随着员工的专业度提高而降低,因此可以通过提高视觉负担,来降低行动负担,进而减少操作用时,当然最佳情况是三个维度能整体降低负担,让总负担降低,就需要更多设计巧思了。


undefined


面向内部设计师和终端用户投放的《高屏效诉求调研》预设解决方案中,设计师常用的 Top 3 做法为:【信息层】隐藏不必要信息、【视觉层】提高布局紧凑度、【交互层】减少点击跳转。


undefined



实践阶段-如何设计

通过以上的探索,我们可以确定的是,B 端产品面向专业人员的工作界面设计中,提高屏效可从视觉、交互、信息三个层次进行,视觉层-高密度,即提高屏幕信息密度;交互层-低跳转,通过减少页面跳转、手势与常用操作的距离等;信息层-有效性,通过重组织或辅助信息帮助用户理解,甚至提供帮助手册等以提高用户专业能力。


undefined


基于以上的总结,对产品进行优化。下面以一个简单案例进行设计策略的解读。一位运营同学想对比 A、B 两不同人群在相同维度(白领-有信用卡)下的人数差异,寻找运营机会点。


如下表格经过高屏效策略优化前后对比图,优化前相同维度下不同人群数量的对比需要视线来回跳动比对,而优化后的表格内容,更符合用户看差异场景下分析目的数据查阅,视线锁定相同维度,即可快速比对数值大小。


undefined


下面以视觉、交互、信息三个层次解剖设计过程背后的思考。


视觉层|高密度-克制的留白

眼动理论:研究表明,人眼最小可视视角 0.3 度,水平最大眼动舒适转动区 30度,垂直最大眼动舒适转动区 55度。可得出人眼最小识别范围 12px,水平视野舒适眼动宽 1200px,垂直视野舒适眼动高 2200px。参考资料:论文《基于眼动交互的用户界面设计与研究》


undefined


如图,缩小表格行高的同时,目标信息之间的眼动距离随之缩短,在眼动舒适区内看到更多信息,便于信息的高效获取。


undefined



交互层|低跳转-高频信息前置

理论基础:菲茨定律是用来预测从任意一点到目标位置所需时间的数学模型,它由保罗·菲茨在1954年首先提出。这个模型考虑了用户定位点的初始位置与目标的相对距离、目标的大小、移动的最短时间。三者之间关系公式为:T=a+blog2(D/W+1),W为其中目标的大小;D为到目标的距离;T为移动到目标所用最短时间。参考资料:菲兹定律


undefined


表格单元格借助交互状态,增加悬浮出现的信息组件,前置显示目标单元格明细信息,同时通过交互出现的指示器辅助行列信息的获取,高频操作考虑手势位置放置,缩短与操作目标的距离,以提高整体操作效率。


undefined



信息层|有效性-信息重组织

理论基础:交互设计四大策略「组织、删除、隐藏、转移」参考资料:《简约至上》


undefined


用户为了对比 A、B 两不同人群在相同维度(白领-有信用卡)下的人数差异,但内容的重组织方式让两数据行需要频繁点击滚动条来查看,根据用户目标,将关联性大的数据放置相邻列(即将要对比的人群放置列头),即可快速查阅,减少眼跳距离。


undefined


结语

设计趋势中常见的大字体大留白界面,但在 B 端场景中,面对紧张的工作节奏,时间和注意力变得尤为可贵,相对而言,基于复杂度守恒定律, B 端信息量大且高频访问的产品中,「用得快」要比「看得美」更重要,「高密度」「低跳转」诠释的即是「空间换时间」,少一次点击,少一次跳转,少一份等待,就多一份时间和效率。


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷  作者:Ant_Design
分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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



B端产品之权限设计(RBAC权限模型)

资深UI设计者


一、前言


随着互联网的快速发展,B端行业也逐渐崛起,很多企业管理中使用的软件我们通常称其为B端管理系统,而在B端系统中“权限管理”是必不可少的功能,不同的系统中权限的应用复杂程度不一样,都是根据实际产品以及需求情况而设置合理的权限。而我们现在对于权限的设置基本上都是建立在RBAC权限模型上的、扩展的,下面我会通过介绍RBAC权限模型的概念以及结合实际业务情况列举权限设置的应用。






二、什么是RBAC权限模型?


RBAC是Role-BasedAccess Control的英文缩写,意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What进行How的操作,也就是“主体”对“客体”的操作。其中who是权限的拥有者或主体(例如:User、Role),what是资源或对象(Resource、Class)。


简单的理解其理念就是将“角色”这个概念赋予用户,在系统中用户与权限之间通过角色进行关联,以这样的方法来实现灵活配置。


RBAC其实是一种分析模型,主要分为:基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。


RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语:

  • 用户:系统接口及访问的操作者

  • 权限:能够访问某接口或者做某操作的授权资格

  • 角色:具有一类相同操作权限的用户的总称





1)RBAC0

RBAC0是RBAC权限模型的核心思想,RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成:用户、角色、会话、许可。用户和角色的含义很简单,通过字面意思即可明白,会话:指用户被赋予角色的过程,称之为会话或者是说激活角色;许可: 就是角色拥有的权限(操作和和被控制的对象),简单的说就是用户可使用的功能或者可查看的数据。


用户与角色是多对多的关系,用户与会话是一对一的关系,会话与角色是一对多的关系,角色与许可是多对多的关系。






   

2)RBAC1

RBAC1是在RBAC0权限模型的基础上,在角色中加入了继承的概念,添加了继承发的概念后,角色就有了上下级或者等级关系。



举例:集团权责清单下包含的角色有:系统管理员、总部权责管理员、区域权责管理员、普通用户,当管理方式向下兼容时,就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限,且上层角色可拥有额外的权限






3)RBAC2

RBAC2是在RBAC0权限模型的基础上,在用户和角色以及会话和角色之间分别加入了约束的概念(职责分离),职责分离指的是同一个人不能拥有两种特定的权限(例如财务部的纳入和支出,或者运动员和裁判员等等)。

用户和角色的约束有以下几种形式:

  • 互斥角色:同一个用户在两个互斥角色中只能选择一个(也会存在一个用户拥有多个角色情况,但是需要通过切换用户角色来实现对不同业务操作)

  • 基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的

  • 先决条件约束:用户想要获得高级角色,首先必须拥有低级角色


会话和角色之间的约束,可以动态的约束用户拥有的角色,例如一个用户可以拥有两个角色,但是运行时只能激活一个角色。




例如:iconfont和蓝湖的用户与角色就采用了约束的概念,超级管理员只允许只有一个







4)RBAC3

RBAC3是RBAC1与RBAC2的合集,所以RBAC3包含继承和约束。








二、为什么要引用RBAC权限模型?


RBAC中具有角色的概念,如果没有角色这个概念,那么在系统中,每个用户都需要单独设置权限,而系统中所涉及到的功能权限和数据权限都非常多,每个用户都单独设置权限对于维护权限的管理员来说无疑是一件繁琐且工作量巨大的任务。


而引入角色这个概念后,我们只需要给系统设置不同的角色,给角色赋予权限,再将用户与角色关联,这样用户所关联的角色就直接拥有了该角色下的所有权限。



例如:用户1~用户8分别拥有以下权限,,不同用户具有相同权限的我用不同的颜色做了区分,如下图:




在没有引入RBAC权限模型的情况下,用户与权限的关系图可采用下图的杨叔叔展示,每个用户分别设置对应的权限,即便是具有相同权限的用户也需要多次设置权限。





引入RBAC权限模型及引入了角色的概念,根据上面表格的统计,用户1、用户3、用户5、用户8拥有的权限相同,用户2、用户6、用户7拥有相同的权限,用户4是独立的权限,所以我们这里可以根据数据统计,以及实际的需求情况,可以建立三个不同的角色,角色A、角色B、角色C,三个角色分别对应三组用户不同的权限,如下图所示:




对应的上面的案例表格我们就可以调整为含有角色列的数据表,这样便可以清楚的知道每个用户所对应的角色及权限。




通过引用RBAC权限模型后,对于系统中大量的用户的权限设置可以更好的建立管理,角色的引入让具有相同权限的用户可以统一关联到相同的的角色中,这样只需要在系统中设置一次角色的权限,后续的用户便可以直接关联这些角色,这样就省去了重复设置权限的过程,对于大型平台的应用上,用户的数量成千上万,这样就可避免在设置权限这项工作上浪费大量的时间。







三、引入用户组的概念


我们依旧拿上面表格案例举例,虽然前面我们应用的RBAC权限模型的概念,但是对于大量用户拥有相同权限的用户,我们同样的也需要对每个用户设置对应的角色,如果一个部门上万人,那么我们就需要给这个部门上万人分别设置角色,而这上万其实是具有相同的权限的,如果直接采用基础的RBAC权限模型的话,那么面对这样的情况,无疑也是具有一个庞大的重复的工作量,并且也不利于后期用户变更的维护管理,那么针对相同用户具有相同的权限的情况,我们便可以引入用户组的概念。


什么是用户组呢?用户组:把具有相同角色的用户进行分类。


上面我们的数据表格案例中的用户1、用户3、用户5、用户8具有相同的角色A,用户2、用户6、用户7也拥有相同的角色B,那么我们就可以将这些具有相同角色的用户建立用户组的关系,拿上面的案例,我们分别对相同角色的用户建立组关系,如下:

用户1、用户3、用户5、用户8→建立用户组1

用户2、用户6、用户7→建立用户组2


因为用户4只有一个用户,所以直接还是单独建立用户与角色的关系,不需要建立用户组,当然尽管只有一个用户也是可以建立用户组的关系,这样有利于后期其他用户与用于4具有相同的角色时,就可以直接将其他用户添加到这个用户组下即可,根据业务的实际情况而选择适合的方案即可。




通过案例表格的变化我们就可以直观的看出权限设置变得清晰简洁了,通过第用户组赋予角色,可以减少大量的重复的工作,我们常见的企业组织、部门下经常会出现不同用户具有相同角色的情况,所以采用用户组的方式,便可以很好的解决这个问题,给具有相同权限的用户建立用户组,将用户组关联到对应的角色下,此用户组就拥有了此角色下的所有权限,而用户是属于用户组的,所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组,一个用户组也可以包括多个用户,所以用户与用户组是多对多的关系。






四、引入权限组的概念


权限组与用户组的原理差不多,是将一些相对固定的功能或者权限建立组的关系,然后再给此权限组赋予角色,目前我所接触的B端项目中使用权限组的概念的比较少,可简单的看一下关系图










四、功能权限和数据权限


B端系统中一般产品的权限由页面、操作和数据构成。页面与操作相互关联,必须拥有页面权限,才能分配该页面下对应的操作权限,数据可被增删改查。所以将权限管理分为功能权限管理和数据权限管理。


功能权限管理:指的是用户可看到那些模块,能操作那些按钮,因为企业中的用户拥有不同的角色,拥有的职责也是不同的。

数据权限管理:指的是用户可看到哪些模块的哪些数据。


例如:一个系统中包含多个权责清单(清单1、清单2、清单3),系统管理员能对整个系统操作维护,也就可以对系统中的所有清单都能操作(增、删、改、查);假如分配给总部权责管理员的是清单1,那么他将只能对清单1进行操作(增、改、查);普通用户也许只有查看数据的权限,没有数据维操作的权限(查),这里的操作是系统中所有可点击的按钮权限操作,列举的增删改查只是最常见的几种操作而已。









五、实战案例总结


我目前所做的项目是一个关于权责管理平台的B端系统,关于系统中的权限需求我这里简单的介绍一下,并采用上面所总结的RBAC权限模型对实际业务需求进行设计分析:

01:不同的区域管理员的权限各不相同(说明会存在不同的用户具有不同的权限,那么我们就可以采用角色对其进行规范)

02:有大量的用户具有相同的权限(例如组织、部门等)(说明存在相同权限的用户,那么我们就可以采用用户组的概念)

03:上级管理员拥有下级人员的所有权限(说明存在继承关系)

04:不同用户所看到的数据和能编辑的数据不同,一些机密性的数据只允许部分人员看或者编辑(说明存在约束)


05:会存在临时性的用户(说明需要支持新建新角色)

06:同一用户会存在多个角色(多角色求合集或者切换用户角色)



简单说明一下,我所做这个项目的人员管理是在另外一个系统中管理的,权责平台只是调用另外一个平台的组织结构树即可,所以权限设置模块没有做人员管理的模块


根据上面对需求的分析,整个权限管理模块中我们需要建立用户组管理模块、功能角色管理模块、业务(数据)管理模块、权限设置模块,下面就对每个模块做更细致的页面展示设计分析



1)用户组管理模块

用户组管理主要是对具有相同权限的用户分类建组,所以页面中我们需要有新建用户组的功能,每个用户组下我们需要关联对应的组织、部门、岗位、人员,让这些具有相同权限的用户在同一个用户组下,如下图:





2)功能角色管理模块

B端项目中一般会建立几个默认的角色是不支持用户修改、删除的,例如最常见的系统管理员,而也会需要有其它角色的需求,所以此模块需要支持用户新建角色,功能角色是对大模块的页面和操作的权限设置,操作权限的颗粒度可以细分到每个页面的每一个按钮的操作,如下图:






3)业务(数据)角色管理模块

业务角色是对页面中的数据饿查看的权限设置,而对于系统中的普通用户查看系统的权限是常用不变的,所以我们考虑默认有一个普通用户的角色,其它业务角色用户根据实际需求情况自行建立即可,由于我们权责系统的特殊性,我们需要满足用户对部分数据可编辑且对部分数据的字段可编辑,按照常理来说,编辑的操作行为是属于功能权限的设置,但是这里的操作行为是建立在数据的基础之上的,所以如果把这里对数据的操作权限在功能角色模块中设置,就会显得混乱,所以我们直接在业务角色模块中加入对数据的可编辑权限,这里在设置的时候更方便灵活





4)权限设置模块

权限设置模块只需要设置权限分配的对象,选择对应的用户或者用户组,关联对应的功能角色和业务(数据)角色即可,这样就形成了一条完整的闭环的权限设置






对于06同一用户会存在多个角色,我们系统是采用切换角色的模式来实现的,因为不同角色中存在互斥的情况,以及所涉及的领域不同,操作权限差距较大,求合集不利于控制权限,所以只能采用切换的模式实现

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷  作者:设计小余
分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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


B端产品设计规范之数据展示

资深UI设计者


数据展示有哪些?



01.徽标

是收纳消息数量的样式,一般出现在图标或者头像右上角。



02.标签

数据展示里面抽取出来的共性特征,将它们转化为标签。标签样式有线框、带不透明底或者面性。



03.走马灯

相当于c端的轮播图




04.文字提示

可以出现在鼠标悬浮按钮时候的行为解释说明,也可以是文案或者导航图标的解释说明。鼠标移入时候出现移出时候消失。



05.气泡卡片

比起文字提示可以承载更多内容,相对弹窗,气泡卡片操作更轻盈。




06.标签页/选项卡

标签页可以帮助用户在一个页面内快速切换不同类型内容,提升单个页面整体的扩展性。标签本质上就是内容区的导航。



07.折叠面板

折叠面板可以更好的收纳内容区域,提高页面利用率。可以和表格结合使用,折叠表格部分详情内容,使得纵向空间更节约。




08.表格

表格是数据展示的重要内容。当有大量结构化数据需要展示时或者需要对数据进行排序、搜索分页时可以用表格进行展现。


当笔记本过小,表格展示不全时候,可以固定首尾重要信息进行滚动。


带排序的表头,可对数量或者金额进行排序。


带分组的表格,建议带边框并且用色块区分表头和内容。


单元格可编辑


批量选中时只会选中当前页,因为分页还没加载出来,为了给用户正确的引导,可以给上提示性文案,例如“已选中XX项内容”。


如果当前页批量选中的数据量不满足要求,可以改变分页器,增加当前页数据量,从而增加选项。


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷  作者:最多三分糖

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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



交互深耕-B端设计师要懂的信息架构

资深UI设计者

信息架构这篇是本人在现阶段觉得较难学习与阐述的知识点,网上关于信息架构的知识内容也是参差不齐。在学习与探究的过程中查阅了很多资料,反复修改多次,尽量用直白的语言结合实例来阐述信息架构。目录如下:

大家可以根据上述目录来进行选择性阅读,当然全文阅读也是极好的~





1.1 前言

这篇文章的起源,来源于最近看到的话题“B端设计师会被组件库取代吗?”。从表面上看,在组件库越来越完善的时代,很多页面设计依靠组件库就能够快速搭建。


那么在这种情况下,B端设计师存在的意义和价值到底体现在哪里呢?其实B端设计的重点并不在页面的视觉上,视觉只是作为设计师最终输出成果的一小部分。个人认为B端设计师工作重心体现在做「正确的设计」,比如以下几个方面:

1.这个设计能否完成对应的商业目标和产品目标;

2.我们的信息呈现是否合理以及能否解决当前需求;

3.用户能否在页面上快速找到想要的信息;

而想要弄清楚并解决上述这些问题,在众多的话题阐述之下,我发现其论述本质上都逃离不了「信息架构」这个概念。因此我认为设计师都需要对这个概念有充分的认知,这能够帮助我们做出正确且出色的设计。


1.2信息架构概念

关于信息架构的概念,在百科上面的定义大部分都比较晦涩难懂,比如维基百科和百度百科的解释:

相信大部分人都很难明白其中描述的意思。在这里换种思路,将信息架构拆分为信息与架构去理解。

信息指的是内容的载体,常见的文字、图像等都是信息;架构的含义则形容对应的组织和结构。那么信息架构就是将信息通过一定的形式组织起来,然后呈现出来。其本质就是研究信息的表达与传递。

通俗点讲,信息架构就是让用户可以更容易的理解我们的产品,让用户在使用我们的产品时可以更顺利、更自然。因此信息架构没有一个具体的呈现形式,它更多的是体现在产品设计的各方面。具体主要表现为组织系统、标签系统、导航系统和搜索系统。





为什么需要信息架构?我们都知道B端产品设计的核心是「降本提效」,在设计这一侧的可以将其理解为降低认知成本,提升使用效率。

降低认知成本需要我们更好的表达信息,让用户能看明白我们的产品能够做什么,如何用;提升使用效率需要提升信息的传递效率,让用户能够很容易的找到需要的功能;


而信息架构从本质上来讲也正是研究信息的表达和传递。因此我们需要通过它来帮助我们更好的完成B端产品设计。如果没有信息架构来作底层支撑,那么我们在页面上看到的可能就只有功能的堆叠,让产品陷入难以上手或者不知道怎么用的尴尬境地。

一个强大信息架构是产品质量的保证,是作为设计支撑点的骨架,它会减少可用性问题,提升整体导航行,创造对用户友好的体验。比如举一个工具层面的例子:

PS的工具栏堆叠在界面各个部分,而Figma的工具栏则集中在右侧且只出现当前需要的功能。很明显Figma在信息架构中的信息组织部分做得更为友好,PS则会显得逊色一些。这也是我们在学习PS的时候会显得比较吃力的原因之一。


可以说良好的信息架构是高效用户体验的基础。视觉元素,功能,交互和导航都是在信息架构的基础上构建的。因此想要做出体验好且合理的页面设计,我们就需要参与到信息架构这个过程中来,和产品一起完成对应架构的梳理。而不是只完成从原型到页面这个部分。


如果想要搭建一个好的建筑,我们需要知道其建造的目的,是按照什么样的结构搭建,内部有哪些系统,以及最后呈现的模样。


那么信息架构也同理,我们首先需要知道信息是为了什么目标服务,然后我们通过怎样的结构来组织这些信息,以及过程中会用到的信息元素,最后如何呈现它们。这都是我们在搭建信息架构中需要进行的必要步骤。如果某些环节没有做好或者没有了解透彻,那么在输出信息架构时往往会出现方向或者策略上的问题。接下来我们看看这些步骤是如何具体呈现的。


3.1 信息获取:先理解业务,再谈架构

B端行业对于业务理解的要求是比较高的,只有在理解业务的基础上,将业务需求转化为对应的设计目标,我们才能够输出合理的信息架构方案。

个人认为理解业务的基础,就是能够用一句话讲清楚当前设计的产品。这句话可以描述为:谁在什么地方想要完成什么目标。比如「用户想要不出门就能够吃到东西」,这就是外卖软件提供的产品服务。


虽然看上去这句话很简单,但其中包括了三个要素:用户、场景和目标。因此我们在分析和梳理业务的过程中首先要弄清楚的就是这三个要素。


3.1.1用户:分清购买者与使用者

用户永远是排在第一位的,也是我们首先需要弄清楚的。在B端设计中,本质上可以分为两类角色:客户和用户。比如我们常用的钉钉或企业微信,购买客户是企业,实际用户是员工。

对于企业:「我想要有一款软件可以更好的管理员工」

对于员工:「我想要这款软件能够更好地提高工作效率」

客户决定了我们产品的购买(部分情况下也兼顾使用),而用户则决定了后续产品的复购率。因此在业务理解中,我们需要弄清楚当前产品所处的服务阶段,比如初期为了打开市场肯定更倾向于客户,而中后期为了提高产品的使用体验又会偏向于用户。


因此我们首先需要弄清楚的就是当前产品是为哪些「目标用户」服务,这也就决定了我们在设计信息架构时对应的不同侧重点。


3.1.2场景:需求源于场景

场景是指需求产生的某种条件,这个条件包括但不限于环境、时间、地点、空间等,只有上述条件满足,这个需求才能成立。这里可以把场景理解为产生该问题的原因

比如当用户提出「她需要一件衣服」,那么我们就需要弄清楚用户为什么需要添加衣服,是她感冒了自身觉得冷还是因为外界环境冷。这两种场景涉及到的解决方案是完全不一样的。


在平日的工作中我们可以通过以下两种方式来更好的了解业务场景:

1.通过业务方文档进行业务背景的初步理解。业务文档中一般都会包括需求背景,我们可以通过文档进行初步了解。

2.通过业务沟通进一步加深业务背景的理解。由于很多B端业务离设计师本身的生活比较远。因此对于需求背景中不理解或者比较模糊的部分,我们可以通过与业务方或产品多次沟通来挖掘最底层的背景。

毕竟需求背景是理解业务的重要步骤,我们只有知道需求产生的原因,才能够针对性的给出解决方案。


3.1.3目标:业务目标和设计目标

目标决定了我们的产品最终的方向。我们首先接触到的一般都是业务目标,而我们要做的就是将业务目标转化为我们此次的设计目标。


A.业务目标

业务目标就是此次业务想要解决的实际问题,它通常是一个宏观上的描述。比如打车软件的业务目标简单概括来讲就是让用户能够更快速地打到车,减少等待焦虑。我们一般通过文档或者沟通来了解该目标。


B.设计目标

设计目标是我们基于业务目标而给出的设计策略,是一种更具体的实现方式。比如我们要让用户快速的打到车,那么这个时候我们的设计目标就是通过将用户位置和司机位置进行快速匹配,并通过超时补贴红包的方案来降低用户焦虑。从而实现业务目标。而这一过程涉及到的信息点就有:司机位置、乘客位置、等车时间、补贴金额等元素,并需要思考它们之间的关系和呈现方式。


可以发现从业务目标转化到设计目标这个过程,实际上就是在确定功能和信息点的过程。这样才能让我们更好地设计信息架构。


3.2信息架构核心:信息组织

从前文可以看出我们会在整体设计过程中出现很多的信息元素。如果不经过对应的组织和处理,直接堆叠在一起,那么信息含义会比较乱且难以调用。比如下方:

而右侧图片信息的组织过程可以理解为通过将零散的数据信息进行分类再以某种结构化的形式将它们重新组合排布的过程,直白一点就是先分类,再结构化呈现。我用一张图来表明这个过程:

那么这个过程中「信息组织」和「结构呈现」到底应该怎么做,也就是接下来要讲的组织方式和结构类型。


3.2.1组织方式:模糊分类和精确分类

组织方式可以分为精确分类和模糊分类。精确分类就是我们会利用物体本身物理属性来进行分类,比如位置、字母表、时间、类别、层级等方式进行组织。一些工具类应用例如滴答清单内容信息都是按照时间来进行组织的:

而模糊分类则是按照更为主观的逻辑对信息进行分类, 如主题、任务、用户、隐喻等来进行归类,比如我们常用的APP商城是按照不同的主题类别来进行区分的。

但在很多时候,产品倾向于将两种组织方式结合起来形成复合型组织方式,从而能够使我们的整体组织形式更符合用户的使用习惯。比如蓝湖的信息组织,其中既包含了模糊分类(按使用类型等分类),也包含了精确分类(按上传文件时间等)。

其实在大部分B端产品中,大都按照模糊分类来进行处理,比如按照任务、流程等方式。而精确分类更多用于在页面内的局部信息模块,比如创建时间和文件大小等。


归根结底,我们分类方式的选择需要结合我们前面提到的用户、场景和目标,这样才能让我们的分类更具说服力。


3.2.2组织结构:选择合适的结构类型

当信息按照分类维度组织后,我们接下来就是把整体信息进行结构化,这样才可以将信息整体连接起来并呈现出来。一般分为以下四种组织方式:


A.层级结构(最重要的结构)

这是信息架构中最为常见的结构,也是比较符合用户认知的结构。有时也称为「树状结构」。以子父节点的形式一层一层延展。

层级结构的优势就在于可以承载复杂的多层级内容,通过层级递进的方式将复杂的多层级拆解得更简洁。


但我们需要把控好内容的广度和深度,广度指的是在层级结构中每一层的数目,最好控制在7个以内。如果广度太宽意味着每个页面会给用户展示太多的信息,增加寻找内容的负担。深度为纵向结构,建议一般3层,最多不超过5层。过深的层级会让用户点击很多次,且不容易被用户发现。比如飞书的基本信息架构也是主要以层级结构来进行的。


B.矩阵结构(多维度结构)

矩阵结构是各个节点都相互连接的一种信息架构方式,通俗来讲就是用户既可以通过多个维度去触达同一信息,也可以从单个维度连接多种信息。

这种结构其实就更类似于我们在做相关功能时:比如当你进入电影全屏时想要退出时,既可以通过点击按钮退出,还可以通过键盘的Esc返回到,通过多点触达同一操作。


又比如我们的联系人功能,我们既可以通过输入数字拨打电话,也可以查找联系人进行拨打,还可以查询电话记录进行回拨。

矩阵结构最重要的意义在于给用户提供多种路径,使用户能够在不同路径中寻找各自想要的东西。


C.自然结构(随机性)

自然结构不遵循任何一致的模式,节点都是被逐一连接起来的。

自然结构一般都具有随机性和不确定性。这种更倾向于泛娱乐化的C端应用。比如我们常见视频网站的在推荐流都是应用的自然结构。比如打开B站等视频平台,你很难猜到刚进入看到的是什么。

但一般自然结构不会单独存在,比如B站在自然结构中也绑定了层级结构来进行层级上的划分。


D.线性结构(单一性)

线性结构是非常单一的一个结构,整体是一层一层向下递进。比较强调先后顺序的一种结构。


这种结构通常用于我们常见的软件安装程序等,也可以用于部分功能结构,比如网站的视频发布,一般都是经过上传-编辑-发布这三个步骤来依次进行。

大家可以发现在进行信息架构时,我们在很多情况下可能会运用多种组织结构方式,我们需要根据对应的用户决策场景来考虑让最适合的几种方式相结合。但最终目的都是为了让用户能够更快速的获取信息。


3.2.3注意事项:关注用户心智模型

在信息的组织过程中,我们需要注意用户的心智模型。比如当我们看到红点就知道有新信息通知,看到下拉箭头就知道可以展开。这是互联网产品在无形中给用户建立的底层习惯认知。用户目前对于普遍产品的一些基础布局、功能名称和交互逻辑都形成了一定的习惯,这都属于用户的心智模型的内容。


因此我们在组织信息时尽可能不要去打破用户常见的心智模型,否则必然会导致用户的不习惯。我们常见的「扫一扫」功能,微信、支付宝和QQ会隐藏在「+」号里面。而微博和抖音却分别放置在了「我的」和「搜索」里面。

这样会导致用户难以发现该功能。因为用户接触新的信息时,会以最初接触的局部信息为依据展开并形成初步认知,用户认知中的信息组织逻辑和实际信息的吻合度越高, 他在进一步查看或寻找信息的过程中体验会更顺畅, 反之, 若一开始形成的认知与实际信息的差异过大, 在后期的信息搜寻过程中则容易遇到困难。而这个吻合程度其实就是用户心智模型。


虽然建议在一定程度上遵循用户心智,但并不是说绝对遵循。对于用户不熟知的场景或者某些专业术语,我们需要通过灵活有效的提示(比如标记注释等)来引导用户就可以了。比如我们刚才提出的抖音扫一扫,它的应用场景其实是用于抖音官网后台登录,且在后台登录时已经给出了对应提示,那么这样的设计也是合理的。


3.3信息架构支撑:标签、导航和搜索

当经过上面的信息组织,其实我们已经能够归纳出一个大体的信息架构框架。但在信息组织之外,我们还需要关注以下三点:标签、导航和搜索。这对于信息架构的完整性也有非常重要的意义。


3.3.1 标签系统:让信息识别更通用

标签系统,通俗来讲就是要我们对当前整个系统信息节点的命名,从而让信息的呈现更容易识别。拿个最简单的例子来进行说明:

可以看到左侧和右侧关于卫生间的信息标示,可能左边你能一眼区分,右边可能就需要反应半天才能猜出到底代表什么含义了。


这其实就是关于我们的信息命名是否能够被大多数用户所接受的场景,也就是我们标签作用所起的作用。标签可以分为图片和文字标签,都需要考虑用户对该信息命名的认知程度,也就是前面提到的心智模型。那么如何能够更好的去定义标签名称呢,这里需要注意2个方面:


A.优先选用被行业广泛接受的词或图标

在进行标签定义的时候,尽量选择已经被用户所熟知的词语,比如「工作台」「通讯录」等已经被运用得非常熟练,对于类似功能就直接以该形式命名,比如我们的设计软件中,很多图标和功能名称都是通用的:

这样做能够很大程度减少用户的学习成本。因此在B端设计中我们也需要注意到我们所在的行业,哪些名词已经达成了共识,就无需再造新名词。


B.不确定的词语可以参考竞品或调研来决策

当某类功能或场景的标签难以确定时,我们就可以尝试去找一下竞品是否有类似功能,或者找该行业的领头羊(比如聊天工具的巨头微信),那么在进行标签定义的时候,可以参考它的命名体系。因为它已经替我们教育了一部分用户,会间接降低学习成本。


如果某些标签在上述过程中还是无法确定,那么我们结合自己经验或者与咨询业务相关人员来进行讨论,在必要时候可以在标签旁边添加注释来进一步说明。


3.3.2 导航系统:让用户不迷路

导航系统其实应该是大家比较熟知的一个系统了。就像使用导航系统来规划行程一样,导航系统都会存在于每个网站中。比如我们常见的侧边导航、顶部导航等。

因为网上关于导航系统已经有很多资料的讲解了,在这里阐述下四类导航的含义:

1.全局导航:位于页面最上层的导航,用户几乎在页面的每个地方都可以看见,是最高层级的导航系统;

2.局部导航:位于最高导航的下级子类导航,子类导航并不是必须的导航,根据场景进行取舍;

3.情景式导航:通过点击文字链接进行跳转的导航,比如在个人资料里面植入其它网站的链接地址;

4.辅助导航:这里包括网站地图,网站索引,网站指南等辅助类型的导航。


辅助导航的网站指南包括新手引导和演示教程等。现阶段更巧妙的功能引导,是当用户在进行某些功能的操作时及时进行提示,这样不仅达到了为用户引导的效果,还减少了一连串的新手引导对于用户的打扰。比如figma在进行组件更新后,只有当你调用组件功能时,才会及时进行提醒。


3.3.3 搜索系统:让用户轻松找信息

搜索,是我们平日最常用的查找信息的功能,它能够帮助我们快速进行信息的检索。虽然搜索功能非常重要,但并不是每个系统每个页面都需要搜索。我们决策是否添加搜索时需要考虑下列三点:

1:内容复杂度:当前页面承载的内容复杂度如果较少,对于简单内容页面往往不需要搜索;

2:内容性质:当前页面的性质是偏向于用户浏览还是查找,根据用户行为来决定是否需要搜索;

3.搜索场景:如果搜索场景很简单,考虑是否只用筛选或分类就能够解决问题;反之如果搜索内容很复杂,我们还可以搜索结合筛选来更好的查找信息;


上述3点决定了我们是否需要考虑搜索功能。而关于搜索的其他细节点,比如搜索规则和搜索结果等,在这里不做进一步的阐述。在这篇文章中更重要的是弄清楚我们何时需要搜索功能。


3.4信息架构表达:视觉化你的架构

我们通过上述方法已经知道如何梳理信息架构了,那么我们应该如何呈现它呢。这部分其实也是很多资料中比较模糊的点。

在学习的过程中,发现部分资料认为信息架构就是单纯的指思维导图,但实际上信息架构并不能单纯只用思维导图就能够完全表示。

因为信息架构包含了很多部分的内容。只能说思维导图可以是信息架构的一种表现形式,其可以帮助我们在思考阶段梳理整体产品的信息构成。


这里抛出一个很有意思的观点,那就是「功能结构图」和「信息架构图」到底什么关系,这里用两张图示例:

可以看到,功能结构图更多体现的形式是功能阐述,一般形式为名词+动词,比如头像设置;而信息架构图重点呈现的应该都为信息元素,一般为名词,比如头像图片。

但在大多数时候我们看到的产品架构图,其实更偏向于功能结构图和信息架构图的结合。因为在很多时候阐述信息构成时需要依赖功能进行辅助说明。


因此这篇文章讲述的信息架构更偏向于基于产品的整体架构。其实信息架构对于呈现形式并没有特别的限制,只要能够帮助你清晰表达产品整体结构就行。《信息架构:超越web设计》第4版中其实也并没有对表现形式这一块进行严苛的定义,其用「显示信息元素间的关系——站点地图」的说法概括了信息架构的呈现形式,其表达如下:

可以看到其表达形式包括思维导图和流程图等形式:思维导图的优势是能够总览全局信息,查看信息的深度和广度,而流程图的优势则更能够表达整体的逻辑关系。


因此信息架构的呈现需要根据你的产品场景选择合适的视觉框架表达。不必让形式限制了我们的发挥,而是应该形式追随于我们的架构表达。其只是一个信息梳理结构的说明结果(类似于中间态),我们需要借助它来更好的阐述思路与沟通想法。


3.5信息架构之后:让信息具像化

在输出信息架构之后,其实这里想聊一聊页面的呈现。因为当梳理好大的框架后,剩余的页面细节其实都需要通过原型图来进行体现。这个过程是从框架到页面的阶段,其实对于设计师来说也是很重要的部分。在这里根据自己的理解列出了以下几方面的注意点:

A.页面能够让用户看懂

这其实就是涉及到我们的信息组织和标签系统。如果当我们的某个页面不能让用户第一时间获取到该页面表达的信息,反思一下是在哪个方面做得不好。是标签系统含义模糊呢,还是信息的组织分类方式不对。从页面呈现倒推信息架构。

综合来说就是设计时的排列要考虑用户的心智模型(比如网页的常规排版和通用名词定义等),对于某些难以理解的地方给予用户帮助和解释。虽然B端产品想要完全避免学习成本是不可能的,但我们可以尽量减少其学习成本。


B.考虑用户的视觉动线

当我们在进行信息排列时,这时需要思考的就是用户的视觉动线,也就是我们常说的视觉浏览「F模型」和「Z模型」。对于不同的信息流来说,采用不同的动线模型能够让用户更好地查找信息。

F模型和Z模型的使用区分其实就是在使用场景上,对于内容页面来说F模型会更为合适(比如文章或者搜索结果),适合文本类的内容。但对于非文本的页面,则更适合用Z模型,Z型模式的设计跟踪了人眼扫描页面时的路线——从左到右,从上到下,能够更好引导用户的视线。


C.掌控好适度的信息层级

B端由于在视觉的发挥空间不多,那么相对来说保持良好的信息层级能够让整体的体验变得更为良好。

不管是原型图还是视觉,整体的视觉层级要体现得更为清晰。按理说最好的视觉层级控制在三级左右。如果发现视觉层级过多,需要考虑是不是因为信息架构设计时纵向层级过深,通过调整架构的形式来更好的呈现信息。以及对同页面的信息进行重要程度分级。


当我们做完或者听别人阐述对应的信息架构时,该如何评判呢,到底怎样的信息架构才算优秀呢。个人认为可以从3方面去进行判断:

业务层:

1.设计目标合理:能平衡商业目标和用户的目标,保证客户和用户都有较为良好的体验;

2.核心任务目标:能够让用户顺利完成产品的核心任务,需要通过用户测试来进行验证

结构层:

1.平衡广度和深度:在进行功能使用时不会隐藏的太深而找不到,是否有冗余步骤

2.保证拓展性:当前信息架构在面对未来新增或者删减信息时能够稳定拓展

体验层:

1.保证易读性:用户不经过介绍,通过页面信息呈现能够看懂该产品是用来做什么的

2.保证易查找性:用户在需要某个功能时能否快捷的找到,是否有多种查找方法(比如搜索或筛选)


合理的信息架构需要具备以上条件,我们需要在做设计呈现时也尽量保证以上条件。但在很多情况下其实并不能完全满足,这个时候我们需要根据业务目标的重要性来选择某些点进行满足。


梳理一下整体文章的架构,其实是按照「是什么-为什么-怎么做」的形式来进行拆分的:

这篇文章想要表达的观点,不是让设计师独立去梳理整体信息架构,而是让设计师拥有信息架构意识,了解其是如何进行并产生的。这样你在看到整体架构时,有足够的理论支撑去判断它的好坏,并通过自己的理论认知去理解和改进不好的地方。


当我们对信息架构有足够的认知时,我们在设计页面时才能有合理的思考方向,做出「正确的设计」,避免成为无情的作图机器。信息架构作为产品交互视觉最底层的支撑,只有骨架搭好,对于用户的使用体验才能够有本质上的提升。


注:文章中不可避免会存在不足之处,如果对文章中内容有更好建议,欢迎随时交流。


  参考资料:

《web信息架构》第四版

《信息焦虑》

《用户体验要素》

《信息架构设计》

「从设计前/设计中阶段,了解信息架构知识点」

「互联网产品如何搭建信息架构」

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷  作者:进击的M

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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

提高操作效率的B端设计

资深UI设计者

我从自身实践的B端项目经验中总结了几个最典型实用的b端的交互设计,来提高用户的操作效率。

目录:

一、简约至上

二、提高用户的操作效率

三、智能化操作设计



       在设计领域已经有很多经过时间和实践检验的定律法则来作为设计的指导原理,它能够帮助设计师更快更有效的将需求转化成合理的界面,并且可以有预见性的去提高产品的用户体验。被推崇的有尼尔森十大原则、用户界面设计的八项黄金法则等。但是实践出真知,一切的方法论都是源自不断实践中提炼和优化的。从原则的输入理解,到实践内化,就是自身不断进步的过程。站在巨人的肩膀上,我们应该总结更多属于自己的设计方法去解决问题优化设计。我从自身实践的B端项目经验中总结了几个最典型实用的b端的交互设计,来提高用户的操作效率。


一、简约至上

      

       1951年威廉.埃德蒙.希克首先提出,认为人们从数组中选择目标的时间取决于可用选项数量。这表明提出的选项数量与随后的选择反应时间之间存在线性关系。从广义上说,界面越复杂,用户就越难找到自己的核心操作点,功能越多,就越难发现真正对用户有价值的东西。

        2011年Giles Colborne在《简约至上》,提出“交互设计四策略”,即:合理删除、分层组织、适时隐藏和巧妙转移这四个令交互设计最大程度简单易用的策略。其本质上就是消除多余的信息干扰,保留了用户主操作流程的心流。

       作为设计师我们利用“删除、组合、隐藏、转移”,不单单是为了简化而简化,我们首要明白的就是要在对用户真正重要的事情上节省他们的脑力。需要把组织成功的标准清晰地构建在产品的简单上。一次交互就是用户与设备之间的一次对话,提高效率就是要节约他们的认知成本,学习成本,操作成本,衡量的指标就是完成某个目标的时间。

      B端管理项目有大量的表格处理,一个表格对应的数据项有很多,遵循简约至上的原则我们不会把所有字段都展示给用户看,只会优选跟业务最核心、用户关心的数据来展示给用户,让他们看到的尽量简约的表格信息。即使是最常用的查询工具,我们也会根据优先级排序,把常用的展示出来,其他的折叠收纳,用户想用到的时候可以展开更多查询条件。我们无时无刻不遵循着这个设计原则。

 


二、提高用户的操作效率


1、快速定位目标信息


       在信息量大的B端系统里,快速找到目标信息是最常用的功能。除了导航上的搜索,我所负责的项目几乎在每个信息页面中都使用了查询,筛选、排序功能,这也是常规表格对信息处理的一种快捷方式。常规的信息定位有搜索、查询、筛选、排序,不同的方式数据的检索模式也不同。根据不同业务场景,合理的使用才能帮助用户缩小信息范围,找到目标信息,提高用户完成一个任务的效率。


搜索:是用户指定任意条件(文本、语音等),平台对此条件进行检索后,展示对应内容。搜索由用户自定义条件,主动表达意图 ,目的性明确。由于搜索行为是用户主动表达意图,往往一个简短的关键词并不能完整表述用户想法,因此,搜索结果的内容通常包含多种类型从精确到模糊的展现规则。


查询:是利用关键字、词组对系统内的相关信息进行多条件组合检索。同时用户也可以输入指定条件的信息作为搜索项,但由于查询功能无法对非结构化的文件内容进行查找,所以输入条件不够精准将无法查询到最终信息。


筛选:是平台为用户提供指定条件,用户可以选择查看符合一类或多类条件下的内容。投顾项目一般都是先大范围查询,再从查询结果列表中,进行表头(快捷、对应、条件更明确细化)的信息筛选。


排序:是根据已设定的内在逻辑,将一组“无序”的记录序列调整为“有序”的记录序列。




2、缩短操作路径


        缩短操作路径简单的说就是减少操作的步骤来提升操作效率,是基于对用户、任务及环境的清晰理解的前提条件下,对用户操作的路径进行优化。我们可以从以下两方面入手:


2.1、通过预测用户下一步的行为

        通过预测用户下一步的行为,对用户进行直接引导,缩短用户的行为路径,减少操作步骤。比如在一系列连贯的操作流中某个链路执行出现问题时,用户下一步的行为是需要及时查看错误内容并处理相关信息,在执行结果中增加一个快速查看的按钮,引导他去查看和处理问题。这比他去菜单中重新查找对账信息效率要高很多。



2.2、通过用户操作路径分析减少操作步骤

      涉及到大量的信息管理时,那对于信息的快速处理就涉及到批量操作。通过用户操作路径分析,用户勾选批量执行的操作频繁,单项处理在较少情况才会用到。针对此分析,我们找到了一些具有共同批量操作特点的管理页面,对其进行操作路径的优化。批量操作可完全合并成一个执行触发点。将这个执行点,单独成一个tab切换页,细化操作为另一个切换页。tab页面的设计,也为错误信息的显示腾出了空间,整个页面清晰可对比。经过操作路径的验证,这个按钮使用率极高,明细操作几乎没有使用到,也缩短了管理页面的操作时间。




3、减少记忆负担


       减少记忆负担,是减少用户在操作时,需要记忆的信息量。一方面我们需要,简化多余的信息,减少用户对页面的认知负荷,另一方面我们可以设计记忆性功能可以帮助用户记忆。


       为什么要去减少用户的记忆负担,一方面,缩短整个操作的时间快速达成操作目标,另一方面,降低记忆数据量,有助于提升用户使用的愉悦感。从心里学来讲, 人们往往更容易记住那些自己喜欢的事物,而对不喜欢的东西记起来比较吃力,在信息大爆炸时代,我们要记忆的很多信息如登录号、证件号、密码、账户号等,这些信息有的不但复杂,而且对用户来说枯燥无味不想记忆,有一种天然的排斥感。那我们通过帮助用户去记忆留存,再在合适的机会调用显示,会提高他们在使用过程中的轻松和愉快感。比如对历史登录账户号的保留,秘钥储存功能,再到短信验证的直接不用密码即可登录,验证码还可以直接复制到剪贴板,这都是为了降低他们的记忆成本。



      随着业务的发展,平台菜单数越来越多,对用户来说非目标菜单的数量增加,用户需要更长时间来记忆所选项目的位置,到最后完全只能选择上方的搜索框进行菜单搜索。Google对用户的测试表明,没有一个人始终会把搜索作为第一选择。相反,他发现只有在网站没有提供有效导航的情况下,用户才会使用搜索。搜索需要输入关键词,即使有模糊匹配,还要进行选择,而且这个过程不一定顺利,可能需要反复操作才能顺利找到才能找到自己心中的目标。我们小组设计师通过竞品分析和用户访谈得到的一个验证性的问题,就是平台存在菜单设计命名不合理的情况,急需优化。优化思路一个是合理菜单命名与菜单结构,但这个不是一蹴而就的事情,需要从产品整个角度去整理和长远排期,持续迭代。为此我们先选择了帮助用户记忆的思路,即做一个菜单收藏的功能。用户可以手动把常用菜单直接收藏在首页,如果在没有收藏或者收藏未满限制数量时,会根据记录的用户访问次数提供最常用的菜单(以用户为导向,自定义功能;以首页为核心提供业务线支持),无需去记忆菜单位置,不断寻找菜单。




4、信息可对照 


      在处理信息的时候,提供信息的对照,减少了跳转,增强关联信息的对比,可以很大程度提升用户处理信息的效率。从系统上讲就是分屏,处理多任务事件(苹果和Windows系统均很好的使用了分屏功能)。从页面角度来讲,其实就是合理化信息模块展示,一个页面不止展示一个信息层级的内容。信息内容有从属关系(避免跳转)、因果关系(显示结果)、并列关系(同级对比)。



      同样具有审批功能的B端项目可能审批流程的设计会完全不同。我负责的另一个项目主要任务是对重大任务的监控,保障日间重点工作按时完成,审批必然严格,且需要单条仔细处理。所以我们设计的是树菜单的形式,让用户可以将待处理信息的条目和内容可以直接对照来处理,提高效率。



三、智能化操作设计


      随着B端行业日益成熟,越来越多的C端设计师转型成B端设计师,B端行业的设计思维也不断的融合和革新,如今B端产品也越来越重视产品的情感化建设、整体的用户体验、简约高效的智能化提升。

      首先让大家了解一个概念,那就是泰斯勒定律,也就是我们常说的复杂性守恒定律。泰斯勒定律认为每一个过程都有其固有的复杂性,这个复杂性存在一个临界点,超过了这个点就不能再简化了,你只能将固有的复杂性从一个地方移动到另外一个地方。



      对于我所负责的项目来说,最能体现产品日趋智能化的交互设计就是清算流程的设计。以往的清算流程是分大流程,点击流程步骤跳转至相关操作页,再进行子模块的操作与检验。完成后,切换回住流程去执行下一个模块的操作。操作员的操作连续性差且操作步骤多,完全由操作员手动操作触发,体验繁琐及不流畅。为此我们重新梳理了所有清算流程步骤,精间可合并的操作步骤,然后将所有步骤按照时间节点顺序排列,完成先前步骤才能进行下一个步骤。流程下方就是对应的执行模块,只需一键执行便可完成当前清算步骤。极大的提高了用户清算的操作成本。



      后续我们UE小组也会针对平台进行用户调研,建立了用户画像。对于运维人员痛点分析后,提出清算流程自动化设计,用定时任务直接去执行相关的流程操作,用户不用进行操作,即可完成结算,只需要关注状态和处理错误信息。



       自动化智能设计的最大缺陷就是无法遇到极致的准确率。实际处理过程中,还是会有清算错误信息存在。为了解决这个问题,我们保留了执行按钮(不手动操作时,自动跑完),运维人员也可以手动执行,处理问题。除了将操作日志信息模块,作为组件,分屏来显示错误信息,我们还按照商户维度来计算状态,以便于运维人员发现具体的错误位置。帮助操作员去查看和解决错误信息。智能化的设计解放了很大一部分的重复劳动,让用户更聚焦有意义的工作。

        智能化已然成为了设计趋势,这将会对系统的性能提升和信息处理精准化提出更高的要求。


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:站酷  作者:上仙修行

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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


B端选择录入类组件的使用辨析

资深UI设计者

编辑导读:在很多设计中,选择录入类组件的理解和使用都比较模棱两可,很多其他产品在实际应用中往往也不够规范,使产品体验的一致性受到影响。本文将具体探究下这几种组件的特性和适用场景,与你分享。

一、前言

不久前在进行一个Web端HRM系统的需求设计,场景是对于从企业离职的员工,HR可以根据员工能力和表现选择是否将其设置为优秀离职人才,对于优秀离职人才将进行定期关怀,以便后续重新返聘的可能。在设计过程中,对于设置优秀离职人才这个交互,感觉使用单选框、多选框、开关都能达到目的,究竟哪一种组件才是最合理的选择呢?

这个问题让我回想起之前在很多设计中对于这几种选择录入类组件的理解和使用都比较模棱两可,很多其他产品在实际应用中往往也不够规范,使产品体验的一致性受到影响。本文将具体探究下这几种组件的特性和适用场景:

二、单选框(Radio)和多选框(Checkbox)

1. 来源

1)单选框

单选框一般被认为来源于收音机(Radio)上的物理按钮,当一个按钮被按下时,另一个按钮将会被弹起,使得永远只有一个按钮处于被按下的状态。

这种说法可能也不够严谨,因为收音机上的按钮在被按下后,不仅呈现出了“按下”的状态,同时也会立马触发收音机的广播,即立即生效。实际上绝大多数UI界面中无论单选框还是多选框一般都是仅作为录入,触发生效往往需要配合“提交”操作来进行。

2)多选框

多选框来源于生活中常见的各种多项选择场景,如饭店菜单、考试多选题等。多选框一般也是作为内容录入的组件,一般在进行选择后同样需要配合后续的“提交”动作,就像选择菜品后下单,选择答案后交卷,这种“选择类”场景多用在表单或者表格中。

多选框还有另一种“设置类”场景,这种场景下多选框用于启用某种模式、应用某项设置,与开关(Switch)非常类似,这也使得多选框在实际产品中的应用要比单选框复杂得多,后文将详细阐述多选框与开关的使用区别。

2. 简单定义及外观样式

1)单选框

可以概括为从最少两个或两个以上的互斥关系选项之中选择一项的组件,外观样式通常由“圆形外框+文字标签”组成,选中时圆形外框样式发生改变表明选中状态。

2)多选框

可以概括为从多个并列关系的选项中选择多个的组件,多选框最少可以一个都不选。外观样式通常由“圆形或方形外框+文字标签”组成,选中时一般在外框中出现√表明选中状态。与单选框相比多选框还有一种特殊的“半选中状态”(half-selected),一般出现在表格(Table)或者树选择(Tree select)中。

3. 交互细节

1)触发区域

单选框和多选框本身外框尺寸都比较小,因此需要将触发区域增大至整个标签范围,方便用户点击

2)排版

单选框和多选框在B端各类表单中应用较多,在页面空间允许的范围内,最好将选项纵向对齐排列,方便用户直观比较,需要横向排布时,选项间应该设置清晰明显的间隔。

3)单选框的容错机制

单选框在选择过后一定要有一个选中项,因此就不能恢复至“空状态”。在比较典型的社交场景中,一些涉及隐私的信息比如婚姻状态选择,可以给用户提供诸如“保密”“不展示”之类的选项,防止用户在选择之后无法回退。

4. 单选框、多选框和下拉选择(Select)的使用辨析

对比单选框、多选框和下拉选择的外观样式不难发现,它们之间最重要的区别在于信息传达效率和包容度的不同。

1)单选框和多选框的特点

单选框和多选框的所有选项信息都是直接暴露出来,如果选项过多将占用较多界面空间并且影响用户的阅读效率和界面整体规整度,信息包容度低但信息传达直观高效;

2)下拉选择的特点

下拉选择则是收在下拉菜单里,只有选择值是用户一眼能看到的,信息包容度高,节省空间,与其他输入类组件并用时能保持整体界面的规整度,但每次都得点开再进行选择也牺牲了一定的信息传达效率和操作便利性。

3)适用单选框和多选框的场景

因此,单选框和多选框更适用于选项数量较少(一般不超过5个),有一定界面编排空间,且用户需要直观看到不同选项内容并进行比较选择的场景,如选择会员购买方案。

4)适用下拉选择的场景

相反,下拉选择更适用于选项数量较多,表单配置复杂、包含各类不同样式组件或界面空间不足,且用户对于被隐藏的选项内容有一定预期的场景,比如选择省份。同时下拉器扩展性更高,下拉菜单可以进行多种类型的变体设计,满足不同业务场景的需求。

三、开关(Switch)

1. 来源

开关(Switch)这个组件就是模仿现实生活中的开关而设计的,现实生活中灯的开关一按,灯马上就亮了,因此开关有一个最大的特征:即时性。这在Ant Design设计系统的全局规则中也给出了注释:“当用户切换「开关」按钮将直接触发状态改变“,因此不同于单选框和多选框这种录入型组件,开关同时兼备录入和触发两种属性。

2. 简单定义及样式

开关是一种特殊的选择组件,只能从“开启/关闭”两种状态选择其一,并且选择的结果会立即生效,通常点击后页面或者开关本身会有加载效果,或者点击后给出反馈,告知用户操作已生效。

3. 开关和多选框的使用辨析

上面提到复选框也经常作为开启某种模式或者应用某类设置使用,在这种场景下它与开关的逻辑十分相似,让人容易混淆。对于这两种组件的使用区别当前已有很多讨论,说法各异,这里根据我自己的探究和经验,从以下几点阐述下自己的看法:

1)开关的即时性

开关的即时性决定了当开关与需要提交的表单一起出现时会存在矛盾,因此在表单中进行状态选择时,尽量选择单选框、多选框,避免使用开关。

2)开关更适合控制一组设置吗

苹果官方人机界面指南中指出“开关比复选框具有更多的视觉权重,因此当它控制的功能比复选框通常更多时,它看起来更好。例如,您可以使用开关让人们打开或关闭一组设置”,然而在复选框的设计指南中又举了用复选框控制一组设置的例子。

再来看一个飞书的例子,飞书管理后台中使用了开关来控制一组设置的开启,而在飞书客户端的设置里用的都是复选框。

对于这个问题,个人认为苹果官方人机指南所说的因为开关比复选框具有更多视觉权重,所以更适合用来控制一组设置的说法并不准确,复选框本身也具有明显的选中和非选中状态,尽管开关组件自身大小以及在视觉效果上可进行设计的空间都更大,但是好像并不足以成为决定性的因素。

同时因为开关的即时性,如果是在需要提交的表单或者模态弹窗中用开关控制一组设置,反而是多选框更合适。

3)从组件的来源分析

从组件的来源及发展历史来看,勾选的交互是基于PC键鼠操作设计的,单选框和多选框组件本身尺寸较小,因而触发区域会扩大至整体标签区域,方便鼠标点击;而开关是诞生于移动设备触控交互的组件,在移动端界面本身配置就比较简化,这时候配合开关自身相对较大的触发区域,用手指点击起来非常方便顺畅。

而在PC端,因为屏幕尺寸更大,同时很多B端系统配置项多、界面布局相较移动端要复杂很多,这时候要把鼠标移至开关热区去点击,反而没有勾选框来得方便,这种操作体验在一个纵列中有多个连续的开关时尤为明显。

4)我的观点

依据开关的即时生效特性,开关更适合用在不需要提交操作的页面中,用来控制功能或设置的开启/关闭,在需要提交操作的表单或者弹窗中,建议使用多选框。

开关和勾选框都可以用来控制一组设置的开启/关闭,使用开关进行控制时,最好将它控制的下属组件都设置为立即生效,这取决于设置本身对于系统的影响,如果设置对于系统重要功能影响较大,则建议改用多选框去控制,让用户多一步“提交”操作进行确认,提升容错性。

四、总结

回到开头设置优秀离职人才场景中的组件问题,这个需求流程涉及到的不只是在离职人员的编辑弹窗中操作,还涉及到在离职人员表格中的状态展示和设置优秀人才的单独操作。首先弹窗中的编辑操作是需要提交的,用开关比较矛盾;单选框和多选框在弹窗中都可以适用,但考虑还需要在离职人员表格中的状态展示和单独编辑,为了保持整体的交互一致性,最后选用了单选框。

总的来说,这几种选择录入类组件在B端系统中应用非常广泛,可能正是因为太司空见惯了,所以容易忽略它们细节上的特性和区别。尽管有时候这些组件的使用问题并不会对用户体验产生决定性的影响,但对细节的探究正是设计师严谨的工作态度和工匠精神的体现,只有秉持着这种对细节的打磨和追求才能不断提升产品的用户体验。

另外虽然文中做了一些各个组件的特性和适用总结,但可能在不同产品和系统中情况会更加复杂,需要设计师根据实际情况灵活处理。

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码ben_lanlan,报下信息,会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

文章来源:人人都是产品经理   作者:齐治设计

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

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

日历

链接

个人资料

蓝蓝设计的小编 http://www.lanlanwork.com

存档