0文章
0评论
0获赞

设计规范 | 详解组件控件结构体系-提示类

814 0

@Echo本篇文章讲解功能分类之提示类,如果我是写信息的提示类,那么里面涉及到的会有toast、警示框、介面内嵌、loading加载、tips提示、空数据介面、卡片等等,这就和之前讲的有重复。所以,这里写的提示类是消息的提示类,而不是信息的提示类。

提示性类型一共有四类:

  • 红点提示
  • 数字提示
  • 系统推送提示
  • 弹框提示

依旧附上一张脑图,组件控件分类(如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节。)

设计规范 | 详解组件控件结构体系-提示类
设计规范 | 详解组件控件结构体系-提示类

红点提示

用途

通过红点引导用户点击,从而达到要给用户传达的信息。

使用场景

1. 以产品的目标来说,新功能更新想让用户知道并去使用,从而使用红点提示用户。

2. 新消息的提示,通过红点让用户直观的知道有信息。

3. 因为业务需要,通过红点让用户去点击操作。

举例说明

微信读书,列表关注栏出现红点,点击进去,新增微信好友出现红点。这样的使用是为了让用户加微信读书好友从而增加微信读书的社交化和粘度。这个属于使用场景第三条。

QQ日迹列表出现红点,在日迹介面,有新增动态,故通过红点提示。这个属入使用场景第二条。

MIX商店有新的更新,通过红点引导用户点击消费,从而满足业务目标。这个属于使用场景第三条。

设计规范 | 详解组件控件结构体系-提示类
设计规范 | 详解组件控件结构体系-提示类

数字提示

用途

通过数字让用户知道新更新的信息数量,同时引导用户去点击,从而达到要给用户传达的信息。

使用场景

1. 通过数字来提示用户新功能的数量。

2. 通过数字来提示用户收到信息的数量。

3. 桌面图标的数量让用户在进去App之前就知道收到的信息数量。

举例说明

Messenger在tab 我通过数字提示,让用户知道列表功能的数量。这属于使用场景的第一条。

微信消息列表通过数字让用户知道,收到对方多少条消息。这属于使用场景的第二条。

iOS 桌面图标的数量让用户在进去App之前就知道收到的信息数量。这属于使用场景的第三条。

设计规范 | 详解组件控件结构体系-提示类
设计规范 | 详解组件控件结构体系-提示类

红点和数字提示两者既有相同点又有不同点

  • 相同点:都是提示用户,从而引导用户去点击达到信息传导的作用。
  • 不同点:数字提示相对于红点提示,提示强度更大。同时数字传达用户的信息更完整,具体到数量。

系统推送提示

用途

前提是iOS和安卓系统推送权限打开,通过系统推送让用户获取到APP要传达的信息,属于强提示类。用户通过推送消息进入App获取消息,提高产品的活跃度和使用粘性。

使用场景

1. 重要信息需要提示用户,例如邮件,IM。当用户收到新消息时,系统自动推送。

2. 满足运营需求,通过系统推送消息给用户传达运营促销活动,吸引用户去消费。

举例说明

1. 如果网易邮箱的系统权限打开时,会收到系统推送,属于使用场景第一条

2. 猫眼有新电影上映时,会有系统推送消息,引导用户去点击消费,这样的行为也提高了用户粘度。属于使用场景第二条。

设计规范 | 详解组件控件结构体系-提示类
设计规范 | 详解组件控件结构体系-提示类

弹框提示

用途

弹框可以让用户知道一些重要的消息,同时通过弹框为某些业务提供一个流量入口。

使用场景

1. 运营需求,通过弹框的提示语和入口,从而达到流量导入的效果

2. 重要功能重要信息的入口。

3. 用于重要信息的提示,单纯的提示信息的作用。

举例说明

支付宝的信用生活介面,用户进入后会给出一个弹框提示,引导用户去抢红包。满足运营需求。这属于使用场景的第一条。

QQ的H5页面通过弹框引导用户去下载使用QQ音乐,这属于使用场景的第二条。

QQ的服务号升级,通过弹框让用户知晓,这属于使用场景的第三条。

设计规范 | 详解组件控件结构体系-提示类
设计规范 | 详解组件控件结构体系-提示类

相关文章:

《》

《》

《》

《》

《》

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-提示类
设计规范 | 详解组件控件结构体系-提示类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | 详解组件控件结构体系-空数据类

421 0

UI设计师或产品经理在设计产品原型时,大部分情况都是先设计主流程的主介面,然后设计其他各个场景的介面,最后设计异常介面、空数据介面等等。那么,空数据介面一共有哪几种类型呢?这篇文章我们来看一下设计规范中的空数据类型。

空数据类型一共有三类:

  1. 初始状态
  2. 清空状态
  3. 出错状态

依旧附上一张脑图,组件控件分类(如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节。)

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类

初始状态

定义:初始化状态,没有任何内容,需要用户进行某种操作才能产生内容的介面。

用途:提示用户需要进行某种操作才会出现内容,并不是没有内容。

例如京东App,当用户没有把商品加入购物车时,进入购物车介面,会给出提示购物车介面为空,给出用户提示后,给出相对应的入口按钮,引导用户操作。如果直接给出一个空白介面,那样的话用户可能以为该介面出bug了,不知所措。

Gmail直接用一个插画提示用户收件箱为空。

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类

初始状态的组成部分:

  • 相关插画/图片
  • 解说文案
  • 操作入口按钮或可点击文字(非必须)

一般对于初始状态的设计,常规做法是简单的插画配合简洁的文案,必要的时候给出引导用户操作行为的按钮。

现在流行的设计趋势是插画越轻量越简单越好,以免抢夺了文案信息。

清空状态

定义:通过删除或其他用户操作,清空当前的页面内容,产生了空介面,这时候需要有明确的提示,且告知用户该如何处理。

用途:提示用户该介面为空数据的原因是用户删除了内容。

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类

清空状态是对初始状态的进一步细化。清空状态的介面和初始状态设计很相似,唯一不同的是文案的提示。

清空状态的组成部分:

  • 相关插画/图片
  • 宣传解说文案的
  • 操作入口按钮或可点击文字(非必须)

有的产品设计直接把清空状态的介面按照初始状态来设计,这样也是可以的,缺点就是没有告知用户产生空状态原因是初始化还是清空所致。

出错状态

定义:由于网络、服务器或者没有找他其他结果等原因导致无法加载内容,产生了空介面,这时候需要有明确的提示,且告知用户该如何处理。用户操作反馈的无结果介面也可以用这样的思路来设计。

用途:告知用户当前产生的空介面是由于某些原因出错所致。

例如知乎在网络异常时,页面加载不出来,出现空数据页面,给出文案提示和点击重试按钮。微博国际版也给出文案提示,小插画和点击按钮

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类

在对信息进行搜索,无法获取数据时,产生的空数据介面。例如iOS原生邮件在搜索不到内容时,产生的空数据状态介面。而网易考拉在搜索无结果时,给出新的解决方案。

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类

原有介面内容被删除时,用户点击进入时出现的出错状态。例如QQ浏览器,通过新闻列表点击,进入新闻详情,由于文章被删除,会出现出错状态的提示。

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类

相关文章:

《》

《》

《》

《》

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-空数据类
设计规范 | 详解组件控件结构体系-空数据类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | 详解组件控件结构体系-网络异常类

309 0

@Echo 从用户使用情况来说,在用户在使用APP过程中,任何操作都可能出现网络异常的情况。那么,针对网络异常情况一共有哪几种设计呢?哪些情况使用全局组件,哪些情况使用局部组件呢?本文作者就按照三种网络情况,总结了对应设计形式。

网络异常无非就3种情况:第一种是网络切换:WiFi网络环境切换到了移动数据网络环境。第二种是断网情况:完全没有网络。第三种就是弱网情况:2G/E时无法加载或者上数据。

本篇文章,按照三种网络情况,总结对应设计形式。

  1. 网络切换:警示框、介面内嵌
  2. 断网情况:整页提示、占位符、toast提示、警示框提示、介面内嵌、tips提示
  3. 弱网情况:整页提示、占位符、介面内嵌、tips提示

依旧附上一张脑图,组件控件分类(如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节。)

设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

网络切换

定义

一些需要消耗大量流量的APP的操作,例如开启视频、直播、音乐等,为保证l同时节省用户流量会给予用户友好的提示。

使用场景

当网络状态从WIFI切换到3G/4G时,为了防止用户操作大量流量,APP会采用一定的设计形式来告诉用户,网络状态切换了,请小心,防止用户浪费流量(土豪除外)。当然从非WIFI状态下开启消耗大量流量操作时,也会使用警示框、介面内嵌设计形式,但这不在今天讨论网络切换范围之内。

常用的设计形式

1. 警示框

阻断式操作,告知用户当前网络情况,继续使用的话会浪费大量流量。用户点击警示框上的操作才可以继续使用。

(1)定义

警告框传达应用或设备某种状态的重要信息,并且常常需要用户来进行操作。

规范中,对警告框包含的元素做出了如下规定:标题(必选)、描述信息(可选)、输入框(可选)、按钮(必选)。同时,警告框的样式都是磨砂效果的圆角白框,不可更改。

(2)建议

  1. 必须包含标题,有时候会包含正文文本
  2. 包含一个或多个按钮
设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

2. 介面内嵌

将需要消耗的移动数据提示内嵌到视频、直播介面里面,给予用户提示。这样的好处是非强阻断式,在告知用户的同时还说明消耗的流量数据。

(1)定义

将提示性文案内嵌到介面中,以此达到告知用户的目的。介面内嵌的好处是减少介面层级干扰,让用户更专注的获取信息。

(2)建议

  1. 文案简洁,易懂
  2. 内嵌文案应该放在介面用户关注的布局介面中
设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

断网情况

定义

移动设备没有网络数据,导致无法上传和下载数据,从而无法正常的使用产品。

使用场景

用户在使用APP的时候,进行操作时,无法正常的使用产品。

常用的设计形式

  • Tips提示
  • 警示框提示
  • 介面内
  • 位符
  • toast提示
  • 整页提示

1. Tips提示

(1)定义

一般出现在首页导航栏或搜索栏之下。通过tips提示告知用户网络异常。

(2)形式

  • 有的Tips一直存在;
  • 有的Tips出现1-2s后消失,用户操作后再次出现;
  • 有的Tips点击会跳转到系统网络设置介面

例如,微信的Tips就是一直存在,点击跳转到提示的新介面。Instagtam出现1-2s后消失。

设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

2. 警示框

阻断式操作,告知用户如何通过操作获得正常使用的提示

(1)定义

规范中,对警告框包含的元素做出了如下规定:标题(必选)、描述信息(可选)、输入框(可选)、按钮(必选)。同时,警告框的样式都是磨砂效果的圆角白框,不可更改。

(2)建议

  1. 弹框按钮提供前往设置的跳转按钮
  2. 文案可清晰简洁的提供解决方案
设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

3. 介面内嵌

当整个页面内容都因为网络异常导致未加载成功,采用介面内嵌的提示的方式。

相对于整页提示的优点在于保留了介面的大致结构。

介面内嵌的设计样式包括:网络异常提示文案、重新连接网络的button(非必需)。

设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

4. 占位符

(1)定义

当由于网络信号不好或网络中断等原因引起页面数据无法调取状态时,我们可以事先在App预设好图标或者占位符来代替加载的文字、数字、图片等数据。

(2)用途

  1. 告知用户此处有内容,只是还没有加载出来
  2. 占位符可以从样式上看出介面布局大概是那些内容
设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

5. Toast提示

(1)使用场景

当网络中断时,用户点击介面进行操作时,出现Toast响应。t提示用户网络异常。让用户的行为即使在网络异常时得到反馈。

设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

6. 整页提示

(1)定义

整页异常的设计样式包括三部分:icon或者插画形式;网络异常文案;重新连接刷新网络的button。

(2)用途

使用过程中网络突然中断无法正常静载时给出的提示。

(3)建议

  • 当前场景相关的插画/图片
  • 当前场景解说文案
  • 当前场景的操作引导
设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类

弱网情况

弱网情况和断网情况的场景基本一致,常见的有:整页提示、占位符、介面内嵌、tips提示,故不做讨论介绍。

相关文章:

《》

《》

《》

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-网络异常类
设计规范 | 详解组件控件结构体系-网络异常类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | 详解组件控件结构体系-加载类

922 0

本文作者将加载划分为6种类型,分别适用于不同的场景,各有优缺点。设计师在设计时,可以根据用户的使用场景和环境设计适合的加载。

@Echo 设计师在进行APP设计时,往往会更加专注于介面的布局、介面和介面之间怎么跳转、操作反馈,却往往忽略掉一个比较重要的环节,就是APP数据加载中的设计。那么我们怎么处理好介面交互中的加载设计,保证体验无缝衔接,保证用户没有漫长的等待感呢?

依旧附上一张脑图,组件控件分类(如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节。)

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类

么是加载?

用户在客户端的介面上进行操作,客户端发送请求到服务器,服务器处理请求,返回数据给客户端,并显示给用户。这一过程成为加载。区别于缓存,缓存是主动的,加载为被动的。

全屏加载

这种加载比较简单,一般运用在页面内容比较单一的情况下,所以直接一次性加载完所有数据后再显示内容。

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类

1、优点

能保证内容的整体性,全部加载完才能够系统化的阅读。

2、缺点

比较明显,就是有非常强烈的等待感,3s以上会产生焦躁情绪。所以,在地铁等信号不好的地方,使用手机网页获取内容实在是比较灾难的一件事情。

3、使用场景

常见的是从上一级介面进入下一级介面;或者H5中常使用。

一般这种情况会配合有明确进度标识的加载loading。

分步加载

当有文字和图片时,图片会比文字加载的慢,这个时候往往文字先加载出来,图片在加载过程中使用占位符,直到图片加载成功。当加载的页面内容有固定的框架时,可以先加载框架,再加载框架内的内容。通过先加载页面框架,设计占位符等形式可以提前让用户知道整个介面的架构,提高产品的体验感。

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类

1、优点

可以帮助用户快速了解整个介面的信息布局。

2、缺点

开始瞬间会丢失掉重要的关键信息,用户初次感知会认为产品出问题了

3、使用场景

适用于多图片布局的介面。比较消耗流量的介面

下拉加载

用户下拉时,出现loading动画,对整个页面的重新加载刷新。现在很多的产品重新设计loading加载动画,使得加载过程更加具有情感化,人性化和品牌化。

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类

1、优点

方便用户刷新当前介面,获取新数据。

2、缺点

非首屏时,无法进行该手势操作。

3、使用场景

介面信息可以刷新加载时使用。

上拉加载

用户在浏览介面的过程中,对于未加载的信息,上拉过程中自动加载。

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类

1、优点

把用户代入无尽浏览模式,让用户一直向下滚动,不需要手动点击下一页。

2、缺点

没有尽头,容易迷失,不方便快速索引定位到某个内容。

3、使用场景

适用于瀑布流、长列表、商品列表等情况。

预加载

当用户在停留个介面时候,将对应当前介面通向下一介面的所有信息都加载出来。使用这个加载方式会使得使用过程中很快减少时间等待。

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类

1、优点

用户进入下一级页面无需加载过程,使用给用户流畅之感。

2、缺点

在非WiFi情况下,浪费用户流量。

3、使用场景

信息需要即时刷新,同时预加载后消耗流量较少的场景,例如IM或邮件。这种加载机制的好处就是进入下一页无需加载,使用流程。

智能加载

根据用户的网络情况,加载不同质量的图片内容。例如在WiFi情况下,加载出来的图片是高清,在非WiFi情况下加载出来的图片是标清的。

1、优点

是根据具体场景来控制流量和加载速度。

2、缺点

不一定是真实有效的命中用户需求

3、使用场景

适用于有大量图片或视频的APP,如电商类或在线视频类APP

上述一共将加载划分为6种类型。6种类型适用于不同的场景,各有优缺点。设计师在设计时,可以根据用户的使用场景和环境设计适合的加载。

相关文章:

《》

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-加载类
设计规范 | 详解组件控件结构体系-加载类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | 详解组件控件结构体系-引导类

334 0

@Echo 本文是系列文章之详解组件控件结构体系的第三篇——引导类。enjoy~

引导是带领用户更快速更愉悦地达到目标的过程,能在用户使用产品功能前或遇到障碍之前给予及时的引导提示。

为了业务或者产品目标的需要,有时候需要给予一些适当的提示方便用户去理解产品。

为了完成不同的引导内容和引导的目标,移动端的引导设计会根据需求进行不同的多样化处理。常见的引导有:引导页(幻灯片)式引导,浮层式引导,嵌入式引导。

3种类型的引导各有各自的特点以及使用场景,本篇文章详解组件控件结构体系—引导类

依旧附上一张脑图,组件控件分类(如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节

设计规范 | 详解组件控件结构体系-引导类
设计规范 | 详解组件控件结构体系-引导类

引导页(幻灯片)式引导

定义:一般出现在app首次启动的时候,是一系列宣传、解说、帮助等页面的组合。

在移动互联网的产品的设计中,引导页的设计则是在用户初次使用该移动产品时,给予的一些必须性的帮助以使得用户能快速愉悦地了解这个产品的功能与具体操作方式。

一方面从产品的角度考虑,产品希望用户能够方便得理解产品的特性,减少对产品的陌生感;另一方面,从用户角度来看,一个应用里好的引导不仅能使他们对一个应用有好感,也可能更容易得留住他们。

设计规范 | 详解组件控件结构体系-引导类
设计规范 | 详解组件控件结构体系-引导类

用途

1. 让用户快速了解是一个什么样的产品。

2. 让用户快速了解该产品的主功能、或者要重点宣传的特色、重大更换功能。

建议

1. 文案简单易懂,重点突出

2. 内容可以是图片、视频、插画漫画等,且内容和文案要有一定的关联性。

3. 分页符一般是2-5个。

4. 提供可以直接跳过引导页的操作。不强制用户一定全部浏览。

使用场景

1. 用户第一次使用时,产品通过引导页让用户快速了解产品的主功能。

2. 用户更新产品时,产品通过引导页给用户传导更新的新功能。

浮层式引导

定义:一种轻量级单目标性很强的引导方式,一般是浮层结合文案的,样式类似气泡的引导方式。

设计规范 | 详解组件控件结构体系-引导类
设计规范 | 详解组件控件结构体系-引导类

用途

1. 提示用户新增功能或页面调整,或如何使用该功能。

2. 提示用户重要功能或一些隐藏操作。

建议

1. 特有文案、带有指示箭头的类似气泡设计。

2. 一般为非模态浮层,大概显示3秒左右自动消失,对用户干扰较小。

3. 文案上尽量简洁,表意清晰,建议控制20字以内。

使用场景

1. 有些新增功能不易让用户察觉同时这些功能对产品本身来说显得比较重要,这时候需要浮层引导,让用户知道该功能或者使用方法。

2. 用于新手引导

嵌入式引导

定义:将引导内容直接嵌入到介面中的引导方式,可以嵌入到状态栏、导航栏、工具栏,比较常见的是嵌入到主题内容介面中。

设计规范 | 详解组件控件结构体系-引导类
设计规范 | 详解组件控件结构体系-引导类

用途

1. 让用户了解当前介面或者操作处于何种状态,并指导接下来如何操作使用。

2. 保留当前介面的内同同时,增加引导提示。

建议

文案简短表述当前状态并告知用户如何操作。

使用场景

1. 异常状态时使用嵌入式引导,目的是提示用户异常状态。

2. 初始状态时,由于介面数据为空,这时候通过嵌入式引导提示用户操作。

3种引导类型按照重要度依次为:引导页(幻灯片)式引导>浮层式引导>嵌入式引导。3种引导可相互组合使用。到底使用哪个?则根据业务和对产品的定位来判断。

相关文章:

《》

《》

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-引导类
设计规范 | 详解组件控件结构体系-引导类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | 详解组件控件结构体系-导航类

233 0

@Echo 本文作者将详细阐述组件控件结构体系中的导航系统,分别为7类:底部标签式导航、分段控制式导航、列表式导航、下拉菜单式导航、抽屉式导航、宫格式导航和卡片式导航。enjoy~

什么是控件?什么组件?两者的区别是什么?

Control翻译为控件,Component翻译为组件。

通俗的解释说法就是组件为多个元素组合而成。控件为单一元素组合而成。

如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节

如下脑图是设计规范的重点,这个是系统的学习组件控件和功能分类的目录。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

导航

导航的作用有哪些?

1. 结构化产品内容和功能

导航系统相当于APP的骨架,支撑着内容和功能组成的血肉,导航系统起着组织内容和功能的作用,让它们按照产品的信息架构图进行连接,展现在在用户面前,导航将零散的内容和功能组织成了一个完成的有结构的系统。

2. 突出核心功能

导航就起到了突出核心功能,适度隐藏次要功能的作用。核心功能对目标用户来说是最重要的。

3. 扁平化用户任务路径

可以很好的扁平化信息层级,并同时提供了进入不同信息分类或入口。用户可以迅速实现不同模块之间的切换且不会迷失方向。

底部签式导航

定义

用于一级目录的导航,位于页面底部,能告诉用户当前位置及用户切换统一层级之间的不同模块,一般最多不超过五个标签。

特点

标签导航是目前最常见的导航形式。最常见的原因是标签式导航可以让流量更大化,分化流量,使得各个模块都有机会获取流量提高页面流量的转化。

将常用的导航放在底部,无论用户单手还是双手操作都能轻松点击,从而实现各功能模块之间的跳转。

标签式导航有底部导航和顶部导航两种,底部导航用于全局导航,顶部导航用于二级导航(遵循Material Design规范的除外)。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

优点

1. 它可以承载重要性和频率处于同一级别的功能模块、信息或任务。

2. 他能在第一时间支持使用者获取重要性最高、频率最大的信息或任务。

3. 它能支持用户在不同模块、信息和任务之间快速切换。

4. 他具有包容性,可以将其他信息的框架溶解掉,构建出容量更大的模块、信息或任务架构。也就是说,很多app的整体架构都是标签式结构,然后又使用其他的架构去承载介面中的具体信息。

缺点

1. 由于尺寸限制,标签式导航的数量上限最好是5个,超过5个就要考虑产品的需求分组是否合适或考虑更换框架。

2. 标签栏占用了一定的空间,所以减少了页面的信息承载量。有些产品为了更好地展示页面信息,会使用一种隐藏的标签栏,这种标签栏会在用户上滑阅读时隐藏,下滑返回时再显示。这种做法确实照顾了页面的信息展示,但是也要具体产品慎重看待,因为他可能会让导航失去便捷性从而降低切换效率。

舵式导航

底部标签式导航的变种。为了突出中间的功能,将中间标签图标设计的比较突出,鼓励用户多使用该功能。

除去两侧4个标签之外,其他重要的标签都隐藏在舵式导航中,或者将那些重要性高、使用相当频繁的功能入口放在里面。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

但是,舵式导航本身是存在设计矛盾的。在舵式导航中位置的应该是重要性和使用频率高的功能,既然他如此重要,为什么要隐藏在舵式导航中?这些功能放在二级介面中相当于被埋起来了,会增加用户的记忆负担和操作负荷。

分段控制式导航

定义

通常用于展示同意模块下不同类别的信息或者筛选不用模块的信息。

特点

一般为二级导航。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

优点

1. 可以很好地扁平化信息层级,并同时提供了进入不容信息分类或模态的入口。

2. 用户可以迅速实现同一模块下不同类别信息之间的切换并且不会迷失方向。

缺点

1. 分段控制式导航位于顶部,切换起来不方便,虽然ios有左右滑动手势,但是很多用户并不知道。

2. 占据空间,导致屏幕可展现区域变少。

列表式导航

定义

通常针对具体某个模块内容的信息进行分类,以列表的形式去呈现。

特点

1. 将具体的某个模块的结构以列表的形式进行分类展现,结构清晰,便于用户理解。

2. 多用于辅助主导航来展现耳机甚至更多层次的内容。

3. 适用于大量的信息分类展现,空间利用效率高,可以展示大量的条目。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

优点

1. 列表式结构具有很强的延展性,可以不断地增强信息。而且一般来讲,它的信息格式都比较一致,调整的弹性高,抗信息冲击力也很强。

2. 它的导航效率高,可以引入字母索引。

3. 它可以很方便的进行分组分类。

4. 适合宽而深的信息层级。

缺点

1. 功能重于形式,承载的信息种类也比较单一,容易引起用户的单调感,很难让用户长时间停留。

2. 如果列表中蕴含的信息量比较庞大,往往需要加入搜索功能或者索引,否则用户会遇到寻找信息的困难。

下拉菜单式导航

定义

通常用于筛选同一模块下的不同类别的信息,或者是快速启动某些常用的功能模块。

特点

1. 为了能让更多用户在有限的屏幕空间上做更多的动作,减少干扰用户查看信息。

2. 能将同一模块的信息做个分类,让用户更清晰地了解这个模块都为我们提供哪些信息或分类。

这种导航形式一般不会用于全局导航,多用于浏览类的APP的二级导航,用户一般每次只浏览一种类型的内容,像刷微博,女生们刷美妆时就会一直刷下去。菜单式导航还有一个好处就是节省屏幕空间,它用一个展开的图标,将几个甚至几十个分类都集合在一起,在寸土寸金的移动端屏幕显得尤为重要。

微博国际版和无秘的二级导航都采用菜单式导航的形式。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

抽屉式导航

定义

通常针对产品偏沉浸式阅读的情况下,其他模块切换频率低,可采用此导航形式。

特点

1. 常与底部标签式导航组合使用,将一级页面内的信息再细分,给人以清晰的呈现方式。

2. 若该产品追求核心内容的突出。可弱化其他信息的展示时,即可采用此导航形式。

抽屉,是整理收起的意思,就是把除了核心功能以外的低频操作都放到一个抽屉里,使得用户获得沉浸式的体验,而且能够集中用户的注意力,让用户去更好的完成核心功能,不被打扰。我们可以把抽屉式导航类比成极简的生活方式,只把必须的东西展现出来,其余的东西要么丢掉,要么整理后收起来。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

优点

1. 用户可以将注意力放在首页,减少其他类型的导航带来分散用户注意力的情况,给用户更沉浸式的操作感和阅读感。

2. 最大限度的利用屏幕空间。

缺点

1. 浪费流量,其他模块的流量会被遏制。不利于整个产品的页面流量最大化。

2. 如果产品框架比较大,需要多功能同时推广的话。不适合用该导航。

宫格式导航

定义

类似于手机桌面各个应用入口的导航方式。每个入口往往是比较独立的信息内容,用户进入一个入口后,只处理与此入口相关的内容,如果要跳转至其他入口,必须要先回到入口总介面。

特点

信息的呈现内容比较少,但是多个项目选取的效率比较高。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

1. 宫格式结构可以作为信息或平台的入口,为产品或项目信息提供聚合的载体。

2. 他适合承载订阅类产品或众多属性差异非常明显的分类信息。

3. 他可以划分多个内容、多个模式,由不同团队独立开发每个模块再聚合。

4. 在具有较强的延展性,可以无限扩展内容。

缺点

1. 用户选择压力大。

2. 用户无法第一时间看到信息,由于宫格式结构是信息或平台的入口,所以具体的信息往往隐藏在下一级介面。

卡片式导航

定义

一种更加可视化的导航,它能根据页面内容的变化及时更新图片,适合以图片为主的内容,像新闻、美食、旅行、视频图片等经常使用,常作为二级导航。

特点

宫格式导航的一种延展形式。每个条目可以呈现更多的信息。

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类

优点

对运营量的要求比较低,而且单个条目的转发率会相应的提高,如果产品的运营量较低或需要较高的条目转化率,可以使用这种设计。

缺点

当运营量较大的时候,这种结构会降低用户寻找信息的效率。

后记:下一篇文章将讲解引导类。

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-导航类
设计规范 | 详解组件控件结构体系-导航类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | Web端设计组件篇-树和日期时间选择器

432 0

根据组件的用途,可以分为六大类:Feedback 反馈、form 表单、basic 基础、data 数据 、navigation 导航、other 其他。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

表单在网页中主要负责信息数据采集功能;用户需要填写输入信息数据并且提交到后端数据库,以此完成信息的采集。则这种组件就是表单组件。

本文主要讲解表单中的treeselect树选择、datepicker日期选择器和timepicker时间选择器。

treeselect树选择

定义:具有层级关系的选择器。

使用场景:

  • 1.需要使用选择器,同时可以提供层级结构的枚举项时。
  • 2.弹出一个下拉选项给用户选择操作
  • 3.具有单选和多选的功能

例如用户搜索关键词时,需要对搜索结果进行二次筛选,常见的使用树选择有城市、组织架构等。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

基础样式:只能选择枚举,不支持在选择框中进行关键词搜索。且为单选。用户选择选项后,浮层收起,表单为完成态。

对于选项中层级结构是否展开收起,则根据父子层级架构来看待,例如省市比较多,默认展开的话,查找起来会变得很困难,收起的话则可以快速找到省,再次点击可快速找到市。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

含有搜索样式:选择框支持搜索,在用户输入字符串过程中,枚举项动态匹配,且匹配的子集展开。当搜索无结果时出现搜索无结果提示,点击无交互效果。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

含有搜索样式(可选择空选项):用户如果选择空值,则提交数据为城市为空。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

含有搜索样式(可清空已选项):如果用户已选择,可提供用户清空已选择的机会。用户如果已选择选项,则鼠标hover,出现叉号,点击叉号,清空选择框。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

含有搜索样式(多选):用户在输入字符串时,选项中出现匹配选项,点击复选框,输入框出现选项tag同时清空输入框。选择框支持搜索,在用户输入字符串过程中,枚举项动态匹配,且匹配的子集展开。点击选择器和选择浮层以外其他区域,则浮层收起,树选择器为完成态。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

datepicker日期选择器

定义:选择日期的组件。

使用场景:

  • 1.当用户需要填写年月日/年月时
  • 2.点击选择框,出现日期选择浮层

例如在boss直聘填写工作经理的表单中,需要填写在职时间。这里使用的就是datepicker日期选择器。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

基础样式:非时间段日期选择器。点击选择框,出现日期选择浮层,默认停留在用户当天日期。用户未选择时,清空按钮默认置灰,已选清空按钮恢复正常状态。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

年月样式:只能选择年月,用户激活输入框,出现年月选择浮层。默认停留在用户当月,清空按钮默认置灰。用户点击选择时,浮层收起,选择框出现已选择当年月。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

时间段样式:时间段日期组件在结束时会多一个选项为至今。用户选择至今,则结束时间一直持续到未来。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

timepicker时间选择器

定义:于用户具体选择时间点时。

使用场景:

  • 1.当用户需要选择具体时/分
  • 2.点击选择框,出现时间选择浮层。

例如微信公众后台定时群发时,可选择具体时间发送。点击出现下拉选项。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

基础样式:点击选择框,出现时间选择浮层,用户可以用户鼠标上下滚动滑轮选择具体的时间点。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

分钟刻度样式有的场景,不需要具体的分钟,具体的分钟在选择起来因为选项太多而变得麻烦,用户更多的使用场景是按照刻度来设置。点击选择框,出现时间选择浮层,用户可以用户鼠标上下滚动滑轮选择大概的的时间点。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

日期和时间组合样式:有的表单,既要提交日期也要提交时间,这种情况可以用两个表单设计,datepiecker和timepicker两者组合,也可以在一个表单上完成,如下所示,用户在选择了日期后,出现时间选择浮层。

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

作者:Echo(微信公众号:UEDC)

设计规范 | Web端设计组件篇-树和日期时间选择器
设计规范 | Web端设计组件篇-树和日期时间选择器

评论 (0)
请登录以参与评论。
立即登录

设计规范 | Web端设计组件篇-反馈类

860 0

设计规范中最重要的部分就是组件规范了,制定组件的规范有哪些好处呢?

1.高效简单:熟悉了解组件的用法之后,在做介面设计时,只需要合理运用组件就可以快速搭建web端介面,高效无差错。由于有成套的组件规范,所以在交互设计视觉设计过程中无需每次都重复劳动。

2.统一用户体验由于使用了统一的组件规范,所以保证了的视觉和交互设计统一性,保证整体的用户体验性。

3.提升设计综合能力:由于减少了做组件重复性劳动,交互设计师/PM 可以将更多时间和精力放在讨论业务、设计方法、设计思维、定义产品等综合能力方面。从而驱动业务创新。

根据组件的用途,可以分为六大类:

  • Feedback 反馈
  • from 表单
  • basic 基础
  • data 数据
  • navigation 导航
  • other 其他
设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

本篇讲述的是feedback反馈类;反馈就是用户做了某项操作之后,系统给用户的一个响应。这个响应根据场景的不同会有不同的响应形式和不同作用。

toast

定义:用户产生操作,出现toast提示,一般2-3s消失;通过toast中的提示语告知用户需要了解的信息。让用户的行为在使用过程中得到反馈和帮助。

使用场景:

  • 1.可提供成功、警告或错误等反馈信息。
  • 2.顶部居中显示并自动消失,是一种不打断用户操作的轻量级提示方式。

例如:简书在没有上传专题封面时就点击创建专题按钮,出现toast提示,提示用户要先上传专题封面才能创建专题。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

toast的消息提示分类一共有三种类型:成功类、失败类、常规类。

组件样式有两种:可以点击操作使其消失、不可点击操作使其消失。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

alert警示提示

定义:当用户进行某种操作时,网站会出现对应的警告信息提示用户,该提示信息的状态不会主动消失。

使用场景:

  • 1.当某个页面需要向用户显示警告的信息时。
  • 2.非浮层的静态展现形式,始终展现,不会自动消失,有的组件用户可以点击关闭。

例如:淘宝购物车,删除之后,会出现alert警示提示,淘宝的例子属于alert的变种,用户可以点击“撤销本次删除 ”进行还原之前的毁灭性操作。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

alert警示提示的消息分类一共有三种类型:成功类、失败类、常规类。当然也可以不含有icon操作,含有icon操作的话警示性会更强。

alert警示组件样式有两种:带有删除操作,不带有删除操作。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

dialog对话框

定义:用于提示用户当前操作,或是完成某个任务时需要的一些其他额外的信息。对话框可以用确定/取消的简单的应答模式,也可以是自定义复杂的模式,例如表单的填写。

使用场景:

  • 1.用户在进行重要操作的时,需要进行二次确认。
  • 2.用于重要的反馈提示,让用户知道信息提示。
  • 3.承载少量的表单填写类,减少页面的跳转。

windows系统的确定按钮一般在左边,而Mac OS的确定一般在右边。因为这个原因,导致我们平时看到的确定有时候在左边,有时候在右边。

微博和微信公众号后台的的对话框,确定在左边,而淘宝的对话框在右边。微信公众号的对话框是小浮层弹窗,避免了遮罩出现,同时对话框也出现在操作按钮的附近,对用户的干扰性也是最弱的。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

dialog对话框,有三种常见的使用场景。其中表单对话框、提示类、轻量级提示类、表单类样式都是基于二次确认类对话框样式的改变而得到不同的样式。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

Notification通知提醒框

定义:悬浮出现在网页右上角,用于全局的提醒式通知。常见于服务器异常、操作失败等

使用场景:

  • 1.较为复杂的通知内容。
  • 2.带有交互的通知,给出用户下一步的行动点。
  • 3.系统主动推送。

Notification通知提醒框出现在网页右上角,一般4-5s消失,也可以点击叉号进行关闭。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

tooltip文字提示

定义:简单轻量的的文字提示。

使用场景:

  • 1.鼠标移入则立即显示提示,移出则立即消失,不承载复杂文本和操作。
  • 2.常用于解释操作按钮的文字说明。

还有一种tooltip是浏览器自带的,浏览器自带的和本篇的tooltip的区别是:浏览器自带的鼠标移入一般2s才显示,多用于折行打点的文字提示。例如简书,而本篇的tooltip鼠标移入就出现,切组件风格和浏览器自带完全不一样。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

tooltip组件按照需要解释说明的对象位置不同,可以有以下不同的样式。

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类

作者:Echo(微信公众号:UEDC)

设计规范 | Web端设计组件篇-反馈类
设计规范 | Web端设计组件篇-反馈类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | Web端设计组件篇-文本与选择器

644 0

根据组件的用途,可以分为六大类:Feedback 反馈、form 表单、basic 基础、data 数据 、navigation 导航、other 其他。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

表单在网页中主要负责数据采集功能;用户需要填写输入数据并且提交到数据库,则这种组件就是表单类。

本文主要讲解表单中的文本和选择器,其中文本分为input短文本、InputAutocomplete 短文本联想和InputMultiline 长文本。

input 短文本

义:用于用户文本输入,并以字符串的方式提交到数据库。

使用场景:

  • 1.用户需要输入字符时
  • 2.通过鼠标键盘输入内容
  • 3.输入的文本通常置于输入框

例如网易考拉优惠券兑换的表单填写,就是短文本输入组件,前面是标题,后面是文本输入框。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

input短文本组件的展示形式可以分为三类。

  • 第一类是标题和输入框左右排列;
  • 第二类是标题和输入框上下排列;
  • 第三类不需要标题的排列

标题和输入框左右排列时,短文本组件存在的状态有:初始态、激活态、报错态、完成态和禁用态。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

常见的表单类排版都是左右排版,同时表单之间,标题采用左对齐,输入框左对齐的情况比较多。有时候标题名字过长这样话 左右排列就不够好,这时候需要采用上下排列。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

标题和输入框上下排版时,存在状态和左右排列是一致的。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

当没有标题时,存在状态同左右排列的规则和逻辑。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

InputAutocomplete 短文本联想

定义:用户用于文本输入,在输入过程中会联想匹配文本选项,并以字符串的方式提交到数据库。

使用场景:

  • 1.需要用户输入文本时。
  • 2.提供联想匹配文本,减少用户输入成本。
  • 3.在输入过程中根据用户输入的内容,出现匹配选项,提交的数据是文本而非枚举项。

例如百度搜索,在输入框输入关键词时会出现对应的联想匹配文本。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

input短文本组件相比,短文本联想唯一的不同就是新增了联想匹配选项,并且提交的是文本而非枚举项

标题和输入框左右排列时,短文本联想组件存在的状态有:初始态、激活态、报错态、完成态和禁用态。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

上下排列的状态和规则逻辑同左右排列。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

不含标题的状态和规则逻辑同左右排列。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

InputMultiline 长文本

定义:用户用于长文本输入,并以文本的方式提交到数据库。

使用场景:

  • 1.多段文字输入
  • 2.需要换行
  • 3.输入的文本通常置于输入框中

例如新浪微博,在输入框发微博时,就是长文本输入,可以换行。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

标题和输入框左右排列时,InputMultiline 长文本存在的状态有:初始态、激活态、报错态、完成态和禁用态。在输入过程中一般有字数统计,超过限制字数,不允许用户输入。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

上下排列逻辑和规则同左右排列。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

不含标题的逻辑同左右排列。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

select 选择器

定义:用户通过选择枚举项,提交到服务器。后端存储为枚举项。

使用场景:

  • 1.弹出一个下拉选项给用户选择操作
  • 2.当选项少时(少于 5 项),建议直接将选项平铺,使用Radio是更好的选择。

例如淘宝卖家后台筛选订单的状态时,点击选择器,出现下拉列表。这就是一个常见的选择器,选择器分为多选和单选两大类,

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

下图为选择器基本样式,就是简单的下拉选项,不可进行关键词的搜索。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

下图是可以搜索的选择器,当输入框处于激活态时,浮出下拉列表。在输入过程中,出现匹配枚举项,点击枚举项,则输入的关键词清空,同时下拉选项收起。输入框出现选择的选项。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

有时候存在一个场景。用户对需要填写的选项设为空选项,则需要空值的选项。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

有时候存在一个场景,用户选择了一个选项,但是后面想去掉选择的选项,不进行选择。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

选择器多选组件中需要注意的一点就是:用户在输入关键词中,选择对应下拉选项,则输入的字符串清空,同时出现该选项tag。

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器

相关阅读

封面作者:Kateryna Musayeva

作者:Echo(微信公众号:UEDC)

设计规范 | Web端设计组件篇-文本与选择器
设计规范 | Web端设计组件篇-文本与选择器
评论 (0)
请登录以参与评论。
立即登录

设计规范 | Web端设计理念篇

943 0

以什么而设计?这是设计理念的基础。这需要去明确并坚守它,我总结了两条:

1.以业务需求为基础的设计

1.设计脱离业务就失去了设计存在的意义,设计本身就应该将业务思维转化为设计思维。

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

2.在做设计满足业务的需求基础上,就要更加主动的去思考用户完成这个基础场景后的下一步,再下一步应该是什么,思考解决方案的延伸面。

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

3.设计师对业务的理解很重要,但在持续深入理解业务之余,有意识地去建立独立于业务的通用跨界思维、框架和方法论,我们不能满足于逐一解决单一、鼓励的业务问题。

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

2.以用户为中心的设计

1.产品设计是从用户需求和用户的感受出发,围绕用户为中心设计产品,而不是让用户去适应产品。无论产品的使用流程、产品的信息架构、人机交互方式等,都需要考虑用户的使用习惯、预期的交互方式、视觉感受等方面。

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

2.当我们关注用户时,除了关注用户要完成的任务,即产品将提供的功能及操作流程,也应该充分关注其完成任务时的目标,即用户为什么要执行这个行动、任务或操作。

不同端的设计理念

不同的使用对象(B端、C端)设计理念也有所区别。

B端产品一般架构复杂且较定制化,以业务为导向。可能有很多高级功能,突出高效易用,导致易学性打折扣。

C端产品一般考虑绝大部分用户使用场景和诉求,高级功能会相对少点。突出易学性。

C端产品需要关注用户的使用时长、是否容易上手并顺利使用。产品做得越好,用户越愿意为它花时间。但在B端市场,效率才是产品的目标,因为B端产品的价值恰恰在于在尽量短的时间内抓住用户痛点,如果用户需要在你产品上花费很多时间,那说明你的产品太难用了。

对C端用户来说,易学/易用>功能齐全

易学/易用即保持了介面结构简单、明了、设计清晰、易理解,操作简单,通过介面元素的表意和介面提供的线索就能让用户清楚的知道其操作方式。

易学/易用的产品易于缩小新用户和专家用户的差距,减少用户的认知成功,提升用户体验

提升易学易用可以从以下方面来处理;

1.恰当的引导:通过文字提示或浮层提示来告知用户,使新用户对该产品/新增功能一目了然。

2.场景指示:在相应的场景下给予用户一定的指示让用户更清晰的知道下一步操作方向。

例如下图的浮层和文字提示:

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

遵循已有用户习惯:用户习惯是由用户长期适应和积累的习惯,很难改变。所以尽量遵循现有主流设计习惯可提高产品的易学/易用性。

对B端用户来说,功能齐全/高效>好用

高效是通过设计帮助用户可以精准、快速的完成目标任务。

在做b端产品时,由于使用的场景相当复杂,同时选择性可能很多,如何在复杂操作里面高效,这对于设计师来说是一个挑战。

提升高效可以从以下方面来处理;

  • 功能齐全:通过齐全的功能来保证高效。
  • 减少操作路径:优化用户操作路径,尽可能的少步骤的完成用户要完成的操作路径。
  • 减少页面跳转:更少的页面跳转能增加介面的连贯性,减少用户的操作和记忆负担,让用户完成任务更具有连续性。

例如下图是b端的卖家介面,搜索功能异常强大,支持各种纬度的筛选。同时直接展示出来,没有将高级搜索隐藏,这样就避免页面的跳转同时增加操作路径。

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

例如下图是c端的买家介面,将搜索功能做的比较简洁(易用),同时将高级筛选功能做了隐藏处理。减少用户的认知和操作负担,让用户专注当前购买列表的主操作。

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

作者:Echo(微信公众号:UEDC)

设计规范 | Web端设计理念篇
设计规范 | Web端设计理念篇

评论 (0)
请登录以参与评论。
立即登录

设计规范 | 详解组件控件结构体系-单元控件类

542 0

@Echo 本篇文章是设计规范中的单元控件类,也是设计规范系列的最后一篇,继这个系列之后我会写一些超有意思的文章,敬请期待哦!

单元控件类一共含以下7类:

  1. 搜索
  2. 开关
  3. 页面控制
  4. 图标
  5. 滑块
  6. 进度
  7. 选框

依旧附上一张脑图,组件控件分类(如果单纯通过组件控件,难以满足功能划分的需求,所以我将这个范围扩大,分类里面不仅仅含有组件和控件,所以请不要在意细节。)

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

1. 搜

(1)定义

用户通过输入的关键词,搜索到用户想要的信息。

(2)用途

当应用内包含大量的信息的时候,用户通过搜索快速地定位到特定的内容。

(3)使用说明

微信两个版本的搜索,很好的遵循了两个平台的规范。对于搜索的规范,iOS 官方给出的是隐藏搜索栏,用户通过下拉展示搜索栏。Android是通过搜索图标控件引导用户点击出现搜索栏。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

2. 开关

(1)定义

开关按钮展示了两个互斥的选项和状态。

(2)用途

仅在列表中用,在列表中使用开关按钮来让用户从某一项的两个互斥状态中指定一个,比如是/否、开/关。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

特性:

  1. 含有开关的对象名称
  2. 开关按钮两种互斥状态

3. 页面控制器

(1)定义

页面控件告诉用户当前共打开了几个视图(多长的视图),还有它们正处在其中的哪一个(进度)。

(2)用途

告诉用户当前有多少个视图(多长的视图),还有它们处在其中哪一个(进度)。

(3)使用场景

例如知乎在浏览器中打开,用户浏览页面时,通过滑条用户很容易知晓当前介面的视图有多长,以及所处在哪里。京东的首页轮播,通过页面控制器诉用户当前共打开了几个视图,还有它们正处在其中的哪一个。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

特性:

  1. 包含一系列圆点,圆点的个数代表当前打开的视图数量(从左到右,这些圆点代表了视图打开的先后顺序)
  2. 避免显示太多点,建议不超过6个,一般超过6个很难让用户一目了然

PS:在iOS 规范中,把页面中的滑条(知乎移动网页端的举例)也当做页面控制器。

4. 图标

(1)定义

介面中的一种图形元素,用来执行应用程序中的定义的操作。

(2)用途

当单击它时,能执行指定的功能操作。

性:

  1. 由图标和/或文字组成
  2. 文字及图标必须能让人轻易的识别为按钮并轻易地点击后展示的内容联系起来
设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

5. 滑块

定义:滑块控件(Sliders,简称滑块)可以让我们通过在连续或间断的区间内滑动锚点来选择一个合适的数值。区间最小值放在左边,对应的,最大值放在右边。

滑块可以在滑动条的左右两端设定图标来反映数值的强度。这种交互特性使得它在设置诸如音量、亮度、色彩饱和度等需要反映强度等级的选项时成为一种极好的选择。

连续滑块在不要求精准、以主观感觉为主的设置中使用连续滑块,让使用者做出更有意义的调整。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

带有可编辑数值的滑块:用于使用者需要设定精确数值的设置项,可以通过点触缩略图、文本框来进行编辑。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

间续滑块:间续滑块会恰好咬合到在滑动条上平均分布的间续标记上。在要求精准、以客观设定为主的设置项中使用间续滑块,让使用者做出更有意义的调整。应当对每个间续标记(tick mark)设定一定的等级区间进行分割,使得其调整效果对于使用者来说显而易见。这些生成区间的值应当是预先设定好的,使用者不可对其进行编辑。

附带数值标签的滑块:用于使用者需要知晓精确数值的设置项。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

6. 进度

定义在刷新加载或者提交内容时,需要一个时间过度,在做这个过程中需要一个进度和动态的设计。

尽可能地减少视觉上的变化,尽量使应用加载过程令人愉快。每次操作只能由一个活动指示器呈现,例如,对于刷新操作,不能即用刷新条,又用动态圆圈来指示。

指示器的类型有两种:线形进度指示器和圆形进度指示器。可以使用其中任何一项来指示确定性和不确定性的操作。

在操作中,对于完成部分不确定的情况下,用户需要等待一定的时间,无需告知后用户台的情况以及所需时间,这时可以使用不确定的指示器。

线形进度条:应该放置在页眉或某块区域的边缘。线形进度指示器应始终从0%到100%显示,绝不能从高到低反着来。如果一个队列里有多个正在进行的操作,使用一个进度指示器来指示整体的所需要等待的时间。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

圆形进度指示器:

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

7.选框

定义:用户对单个/多个选项进行选择。

选框分为两类:单选框和复选框。

单选框:只允许用户从一组选项中选择一个。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

复选框:允许用户从一组选项中选择多个。

如果需要在一个列表中出现多个 on/off 选项,复选框是一种节省空间的好方式。

如果只有一个 on/off 选择,不要使用复选框,而应该替换成开关。

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类

相关文章:

《》

《》

《》

《》

《》

《》

《》

封面作者:Javier Crocco Mendez

作者:Echo(微信公众号:UEDC)

设计规范 | 详解组件控件结构体系-单元控件类
设计规范 | 详解组件控件结构体系-单元控件类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | Web端设计组件篇-数据类

902 0
设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

用户在使用网站过程中,数值可直观的提醒用户当前所处的状态,通过准确的量化数值让用户对当前的状态有更准确的感知。

Badge 微标数

定义:通过数字或者红点提示用户消息或状态等情况

使用场景:

1.一般出现在通知图标或头像的右上角,用于显示需要处理的消息条数,通过醒目视觉形式吸引用户处理。

2.提示用户有新更新关注的信息。

例如:知乎的消息提醒和私信,都是通过徽标数来提示用户待办处理事项数量。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

数字样式:较强提醒,让用户知道和用户相关提示信息数量,引导用户处理。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

红点样式:弱提示,告知用户有相关的提示消息,不告诉具体的数量,需要用户去手动通过查看详情消除。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

自定义:通过自定义样式提示用户以此达到设计目的。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

Uploading 上传

定义:通过点击或者把文件拖入指定区域,从而把本地文件上传到服务端。

使用场景:

1.需要上传一个或一些文件或图像

2.当需要展现上传的进度时。

点击上传:当鼠标hover在上传当列表上时,出现删除按钮,点击删除,无需二次确认。未上传完成不显示上传的时间。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

拖拽上传:可拖拽文件进入指定区域上传。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

图片上传:可以看预览态,当有图片数量显示时,达到限制时,添加操作隐藏。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

Progress 进度条

定义:用于展示操作进度,告知用户当前状态和预期。

使用场景:

1.上传、下载过程中由于需要较长时间的等待,需要一个进度表示当前情况。

2.当需要展现上传的进度时。

每次显示进度只能由一个活动指示器呈现,不能即使用线形进度条又用圆形进度器来指示。

线形进度条:应始终从0%到100%显示,绝不能从高到低反着来。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

圆形进度指示器:圆形加载样式,不含取消按钮操作。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

Loading 加载

定义:用户在网页上进行操作,网页发送请求到服务器,服务器处理请求,返回数据给网页并显示给用户,这一过程成为加载。由于加载过程会需要一定的时间,所以需要加载动效会有效缓解用户的焦虑,并起到提示用户正在加载。

使用场景:

1.页面局部处于等待异步数据或正在渲染过程时,合适的加载动效会有效缓解用户的焦虑。

全屏加载:整个介面整体加载,所有信息加载完成,页面才展示信息。加载loading可以含有进度,可不含进度。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

步加载:加载文字,文字加载完成之后再加载图片例如淘宝。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

组件加载:常见的是点击操作按钮,这时候需要一个加载提交过程,加载在组件中展示,减少页面的视觉的干扰。

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类

相关阅读:

原文地址:吴轶(公众号)

作者:Echo

设计规范 | Web端设计组件篇-数据类
设计规范 | Web端设计组件篇-数据类
评论 (0)
请登录以参与评论。
立即登录

设计规范 | Web端设计组件篇-其他类

726 0
设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

Tag标签

定义:用于标记和选择的组件

使用场景:

  • 1. 标记属性时
  • 2. 多选展示标记时

例如,大众点评首页结婚业务模块,标题除了给用户标记属性,还可以点击标签进入对应分类类目。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

基础样式:般有三种,面性标签、线性标签、可删除标签。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

筛选样式:通过点击标签,选择对应标签属性的筛选结果,可多选,点击选中,再次点击取消选中。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

添加tag样式:含有添加tag的按钮,点击激活输入框,输入完成鼠标点击其他区域/回车,完成添加。添加tag的按钮保持在添加tag之后。如果tag有数量限制,超过限制时,添加按钮消失。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

Table表格

定义:展示列表数据并可能附带操作的足迹啊

使用场景:

  • 1. 当有大量结构化数据时
  • 2. 结构化数据需要排序、筛选、操作等

操作样式:含有列表操作

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

批量样式:可以批量操作,当未点击批量勾选时,批量操作按钮置灰。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

链接样式:点击颜色文字按钮,可打开新tab,查看详情

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

筛选样式:第一次点击,下箭头被选中,列表逆序排列;再次点击上箭头被选中,列表正序排列再次点击,回复默认状态。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

List列表

定义:通过列表区分信息层级

使用场景:

  • 1. 通常展示主要的关键字段
  • 2. 详情页的上一级页面

例如:网易邮箱,邮件列表,鼠标hover列表,出现hover效果,点击进入邮件详情页。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

基础样式:通常展示详情的重要字段信息。鼠标hover出现hover效果,点击进入具体详情页。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

操作样式:可以在列表上进行操作。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

Card卡片

定义:信息聚合的容器

使用场景:

  • 1. 信息需要分组,需要区分层级时
  • 2. 展示关键字段信息

例如:淘宝搜索结果介面,展示不同商家的产品通过卡片展示给买家查看。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

文字样式:纯的文字聚合成卡片。

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

图文样式:含有图片和文字聚合的样式

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类

相关阅读:

原文地址:吴轶(公众号)

作者:Echo

设计规范 | Web端设计组件篇-其他类
设计规范 | Web端设计组件篇-其他类
评论 (0)
请登录以参与评论。
立即登录