鸥米

一，消息概述

1.总体规范

高效的消息提示能增强系统的可信度，提供相关信息和为用户创造愉悦。

如何在Y发生时为X设计合适的消息呢？

·依据用户与应用的交互来选择合适的消息类型（？）

·选择合适的消息控件，基于：在用户行为流中和UI的背景下是有意义的；有合适的重要性层级

·选择合适的消息状态

2.原则
·适时 Timely，不要打扰用户

在合适的时间推送消息，而不是每个交互动作都提示

·提供有用信息 Necessary，不要啰嗦

仅说明必要内容

·可操作 Actionable，不要纯静态

提供相关操作快捷入口，提高效率

·跨平台 Cross device，不要重复

合适的情况下，在所有的平台上给用户提示，一旦已读就全部移除。

3.图标

4.用例

销售员刚刚聊完电话，是有关和ACME进行的一笔100份小玩具的交易，这笔交易已经记录一段时间了，最终成交。于此同时一些交易数据也发生了变化。销售员在应用中更新了这一记录。此时，应用应当作出怎样的反应以表明记录已成功保存呢？

首先，了解用户在这一行动流中的交互行为，来确定消息类型。

·用户发起这一交互

·由于是用户发起的，可能的消息类型就是“主动接入”和“反馈”

·记录是可以获取的，并且用户成功地保存了改动。基于此，我们只剩下一个选择。（？？）

·此消息类型为：反馈

然后，我们来看一下消息控件。

·基于规范，我们有几种反馈消息的控件可以使用：文案，弹出框，吐司及模态弹窗。

    ·内部文案 Inline Text 多用于某条信息、卡片、关联列表的为空或不可用状态，字段级别的错误提示或一些中间状态（保存中、加载中等）。我们需要的是更适用于展示成功消息的控件。

    ·弹出框 Popover要么用于“吸引或促使用户做出某种行为”，要么用于“在用户提交数据后传递错误消息”。任何一种都不适于这一用例。

    ·吐司 Toast 作为一种“用户做出某一行为后的确认机制…以及紧接着创造、编辑、删除行为出现。”

    ·模态 Modal 作为“一种保证用户的行为是有意识的而非误操作的警示机制。”在这一案例中，行为是完全主动有意识的（编辑记录）并且不需要警示。

·根据以上分析，吐司是合适的选择。进一步去了解它在UI中是否具有合适的重要层级。

·消息控件：吐司。

 

最终，决定消息的状态：已成功。

因此，综上所述，应采用：成功的吐司提示。

二，消息类型

从一个更高的视角来看，我们根据用户的交互本质来进行消息类型划分。

·系统消息 System messaging 警示用户系统相关的事件或状态。可以由系统或另一用户发起。

例如，本周将进行系统维护。

·用户参与消息 Engagement messaging 促使用户进入或更新系统数据。可以由系统或另一用户发起。

例如，过去一个月，在Opportunity x中都没有任何变动。创建一个项目任务或计划。（？？）

·主动接入消息 Access messaging 当用户想要接入某一超出他使用权限的项目时出现。可能是该条记录已经被删除或用户没有接入权限等。

·反馈消息Feedback messaging 是当用户与应用进行交互时应用给出的反馈。大部分的新建、阅读、更新、删除行为都会带来反馈消息。

例如，创建账户x。

三，控件

1.概述

每种控件都拥有特性以决定它的重要层级。例如：

这些特性适用于每个控件。

2.横幅banners

传递影响整个系统的状态，在某个板块上方持续存在，不需要用户主动发起操作。

注：仅适用于salesforce

(1)用法：

传递系统级别的消息，与用户在应用中所处位置无关。

横幅展示以下状态：

·错误：告知用户无法继续在salesforce中的操作体验，例如浏览器待更新。

·报告信息：展示管理相关状态（如已以用户身份登录），进行系统维护等。

·断线：告知用户他们已断线

·警告：警告用户在salesforce中的可能事件，如浏览器未更新导致。

当用户登录后，以通栏形式在所有头部呈现。在用户登录状态下持续展示，通常无法被移除。横幅只在特定情况下可以移除，即传递的信息是对将来有影响但当前不会有任何问题的时候，例如告知用户计划要进行的的系统维护。

(2)做什么和不做什么

做：

·尽可能少使用

·让UI和文案简洁。需要的话，提供链接让用户得以获取更多详情。

不做：

·不要做为反馈机制。反馈时使用文案、弹出框、吐司或模态窗口。

·如果在用户登录期间该消息与用户持续相关，则不要让它可移除。

（3）变体

（4）UI文案

每个案例的UI文案都不一样，取决于应用背景。下方规范可作为样例，但不要受限于此。

（5）建议代码

下落动效时长：0.4s

3.文案

用一种不会遮挡的方式传递信息。在内部展示但不遮挡界面。

（1）用法

根据情境选择可见性程度，但只在板块内部某一UI控件内部或其附近展示。文案应当融入UI中，除了错误状态。

文案可展示以下状态：

空白：无数据或不可用

错误：系统无法加载内容，或某一表格出错

报告：当某一项目出现反常，例如重复项目

临时：系统运行过程中，如保存中、加载中、邮件发送中等

当空白状态影响到整个页面时，考虑采用文案+图

对于表格错误，消息展示为红色，并通常与弹出框一起使用

（2）使用情境：多样

（3）做什么和不做什么

做

·尽量简短。对于大部分用例而言1-2句话即可。

·展示错误信息时使用另一种颜色。

不做

·如果消息紧急不要仅依赖于文案。如警告用户即将删除一个卡片。

·不要让文案与周边UI差异过大。避免太显著的变化，如很大的字号、对比强烈的颜色做背景等。最多为错误信息更改颜色。

·不要使用动画或动效。最多为过度状态的文案提供渐入渐出效果。

（4）变体-控件

文案、图标+文案

（5）变体-状态

为空、错误、报告、临时过渡、警告

（6）变体-屏幕大小：适合整体UI即可

（7）UI文案：根据具体情况变化，例子如下

（8）代码建议

错误文案色值：#c23934

4.图+文案

（1）用法

视觉：凸显

语气：报告的

动效：静止

持续性：永久

声音：柔和

展示状态：

·为空：没有内容时，或没有值得关注的项目时。

·报告：系统处于维护中时。

·错误：页面丢失，用户没有足够的权限或其他错误（通常与无法获得内容相关）。

（2）使用情境

做和不做

做

·使用图案减少对用户的消极影响。当用户想要获取某一项目内容而不得时，会有消极体验，而图案会减少这种影响。

·包含引导用户的文案。例如当用户看到的是空列表页时，给出链接文案引导用户创建新记录。

不做

·不要在列表或卡片内部使用图案。这种情况使用文案即可。

·不要在一个页面内展示1个以上的图。图案不应当相互抢夺用户的注意力。

·不要作为基本操作(CRUD, Create, Retrieve, Update, Delete)的反馈。这时应使用吐司或弹出框。

（3）变体

·控件

在整体页面、主要内容区或边栏中都能呈现

·状态（为空、报告或错误）

空白列表

空白消息feed

报告

错误

·屏幕大小

移动端

最宽300px

最高180px

较小文案

（4）UI文案

（5）建议代码

5.模态弹窗 Modals

展示某一动作正在进行中，确认某一用户动作，或告知某一错误。

（1）用法：

应用于消息时，模态可以有一下几个状态：

·过程中：当用户在上传文件时。

·警告：用户试图进行损坏性操作（如删除某一记录），进行影响很大的操作（如给100,000人发送邮件），或放弃某一未完成的行为（如离开一个为保存的表格）时。

无论被用于创建/编辑容器还是消息容器时，模态弹窗的行为动效等展示应保持一致，使用默认控件及动效代码即可。

（2）情境

做和不做

做

·当需要传递进度、确认或错误消息时使用模态弹窗。一个用户不应在某一流程中看到多个警告模态弹窗。

·在右下角放置按钮，所有模态保持一致。

·标题和行为按钮标签需保持一致。例如，模态标题为“删除文件么？”按钮标签为“删除”。

不做

·不要用模态展示成功状态，如“合同已成功添加”。请使用吐司。

·不要将鼠标箭头放在行为按钮上。一个乐于使用键盘的用户可能不小心确认该行为。

（3）变体

屏幕大小——移动端

较小标题

通栏按钮

除非有核心信息必须展示否则不要包含详情内容

（4）建议代码

6.通知公告Notice

警告用户系统相关的事项和更新。

注：Salsforce平台合作商户不要使用此控件。

（1）用法

当系统想要将消息传递给用户时出现；不是用户行为的结果。很少出现，不应成为用户典型行为流程的一个部分。

没有关闭（✖️）按钮。用户通过点击通知内部按钮关闭通知。

展示以下状态：

·错误：当系统出现无法让用户继续操作的问题时。

报告：当系统需要重置系统相关信息但不用停止当前工作时。

（2）情境

（3）做和不做

做

·谨慎使用。不应作为展示系统消息的第一选择，因为会打断用户的操作。

·必要时让用户给出反馈。当意外系统故障时，例如，用户反馈会是发现问题的一个有效方式。

不做

·不要使用通知来确认用户的行为，例如在用户删除一个项目之前给予警告。这时使用标准模态弹窗。

·不要重叠通知。

（4）变体

·不同控件（一个按钮，多个按钮，一个按钮+输入框）

·不同状态（错误，报告）

·不同屏幕大小（移动端）

较小标题

通栏按钮

（5）UI文案

（6）建议代码

7.消息Notifications

通过展示可供点击的信息和快捷入口来告知用户平台内的相关动态。

（1）用法

消息让用户知悉相关项目的更新。包括如下：

·@ me 某一项目提到某一用户，或某一项目分派给某一用户。

·用户自定义 Custom criteria  一个项目满足了用户设定的标准。

·批准 Approval  用户需要批准某项目，或用户的请求得到批准。

·提醒 Reminder  某一活动临近或最后期限临近。

·流程更新 Process update  某一用户发起的流程成功完成或出现问题。

·产品发布 Product announcement  app需告知用户产品相关的新消息。

消息由两个元素构成：

·图标 Icon：展示未读消息的数字

·托盘 Tray：包含用户收取的所有消息项目

消息图标位于头部，点击展开和手气托盘。当有新消息时，图标上会出现一个数字；多个新消息时，数字会随之更新。托盘内的每个消息能链接到相关项目。

每个消息项目可以展示以下不同状态：

错误

报告

成功

（2）情境

（3）做与不做

做

·在项目内可以包含行为按钮，这样用户可立即处理；如记录需要用户的批准时，提供“同意”和“拒绝”。

·允许用户关闭消息提醒。

·聚合同一项目的多个消息以减少噪音。

不做

·不要将消息用作反馈机制。使用文案、弹出框、吐司或模态。

·不要将消息作为获取全部动态的唯一渠道。消息是高度自定义的，而用户可能选择关闭某些项目。

·不要让用户感觉过载。有选择地使用消息。

·不要在一个消息项目中包含多个行为步骤。只包含一步的行为，如同意或拒绝，已核查等。

（4）变体

·控件

·状态

无论是报告式还是成功式，都使用统一的控件状态（未读、悬浮等）。

·移动端

移动端的托盘形态与桌面端很不一样。他不是悬浮在页面上方，而是从右侧划入。

此外，用户没有在app中时，也可以收到OS系统级别的通知消息。

8.弹出框Popovers

因为问题或潜在问题吸引用户注意。

（1）用法

一个弹出框可展示以下状态：

·错误：告知用户在上传数据时出现错误

·警告：系统提醒用户某一记录已经很久没有动态了

弹出框包含标题和主体，主体可包含链接。

在错误情况下，行为按钮（通常是保存和取消）左方放置红色警告图标。弹出框也是红色的，出现在警告图标上方。它比内部消息更明显，同时也不阻碍其他控件。错误弹出框自动出现（当用户提交表格出现错误后）。对于多项错误，主体文案可以是一个列表。

在预约/警告场景中，相关项目出现一个黄色警告图标⚠️，弹出框通常出现在图标右侧。用户通过点击图标展示改弹出框，不要自动出现。

（2）情境

（3）做和不做

做

·在弹出和收起弹出框时使用动画。

·确保弹出框内的链接和关闭按钮可以通过键盘进行操作。

不做

·不要让错误弹出框超出表格

·不要随意使用警告弹框。确保使用警告弹框的标准相对灵活，让用户不要总是被打扰。（？）（Do not use warning popover liberally. Make sure the criteria for calling a warning popover is flexible enough so the user doesn’t constantly feel pestered.）

（4）变体

（5）不要在移动端使用

（6）文案

（7）代码

缓入缓出时长

滑动距离

9.吐司

吐司属于用户行为的反馈或确认机制。

（1）用法

用户进行创建、编辑、删除等行为后出现。例如，用户通过模态弹窗编辑了一个机会并保存。模态关闭后，吐司出现在新建机会详情页面的顶部。

吐司可以显示出以下状态：

·错误：当用户做出一个行为，但系统阻止此行为真正执行。

·报告：当用户做出一个行为，有一些附加信息需要呈现。

·成功：用户完成或执行完毕。

·警告：当用户因外部原因无法完成某一行为（例如许可）而不是某个他能立即修改的问题时（如表格内错误）。

无论页面如何滚动，吐司都能保持在页面顶部可见，直到用户移除或规定的持续时间已过去。他们可以呈现1-2句（不用缩短），包含链接，以及关闭按钮。桌面端吐司可包含一个图标以表明消息类型，移动端不需要图标。

吐司宽度取决于内容长度及内部空白，但至少需要480px且在页面居中。

吐司以以下方式呈现：

·持续：持续呈现直到被用户关闭。促使用户了解信息而不阻挡页面内其他交互，例如，10条消息未能传达。

·暂时：短时间展示，直到持续时间结束或用户关闭，显示某个很有用但是非核心的消息，例如，记录已被保存。

（2）情境

（3）做和不做

做

·将同类型吐司汇总以减少吐司个数

·不同类型的吐司并列展示，将最近的展示在顶部

不做

·当创建行为将用户带到新建项目时，不要使用吐司来确认成功。

·不要在内部编辑时使用吐司。回到查看状态就足够表明已成功修改了。如果表格未能成功保存，表格应仍处于编辑状态。

·不要在用户导航至其他页面后仍然保留吐司。吐司仅与当前页面相关。

（4）变体

·控件

·状态

·屏幕大小

移动端

90%宽度

没有图标

较小的居左文案

没有描述文案

（5）文案

（6）代码

四，消息状态

消息状态传递的是UI文案的语气语调。与消息原则保持一致，UI文案应当是报告式的和可执行的（可以的话）。

1.空白Empty

场景：

·某页面控件没有内容时——inline text

·页面没有内容时——illustration & inline text

2.错误Error

(1)表格错误

Error Inline Text, Error Popover

如果用户提交的表格中有错误，则展示提示文案或同时呈现弹出框。

字段级别(field-level)的提示文案位于字段附近（如，电话号码不能包含字母），二弹出框展示时错误汇总（如，重新表格以下字段：电话号码）。

Error Inline text (+ icon variant)

如果不能使用弹出框，则展示提示文案（+图标）。

(2)未完成

Error Toast

用户操作后，当系统相关问题阻止了该操作的真正执行，则展示吐司错误。

使用“标题和描述”来表述更多信息。这一交互方式应尽可能少出现，且通常不应属于某一典型用户行为流。

(3)卡片内容错误

Error Inline Text

卡片内容无法加载时，在卡片内部展示错误提示文案。

(4)系统错误（当前）

Banner

如果系统错误影响用户当前操作，则展示横幅。

(5)系统错误（随机）

Notice

如果系统错误是随机发送的，则使用公告通知用户。

(6)无法获取页面内容

Illustration & Inline Text

(7)流程错误

Notification

如果用户发起的流程（如导入数据）出现错误，则使用消息提醒用户

3.报告 informational

出现场景：

·项目出现异常状态，如重复项目（内容顶部出现icon + inline text）

·用户行为完成，带有附加信息（）

·用户当前板块有管理级别相关调整

·系统不可进入，如维护中

·系统需要更新信息但不用立即停止当前工作

·系统需要告知用户另一板块的相关活动

（1）异常项目

在异常项目内容上方展示，使用图标+文案

illustration & inline text

（2）成功行为附加信息

information toast

（3）管理相关状态

banner

（4）系统不可用

illustration & inline text

（5）系统消息

notice

（6）动态更新

notification

4.离线Offline

banner

直到用户上线一直展示

5.成功Success

出现场景：

·需要用户手动输入的行为成功完成（如上传一个表格）

·自动触发的行为成功完成（如自动保存的笔记）

·用户发起的行为成功完成（如数据导入）

（1）手动行为

success toast

（2）自动行为

inline text

用户行为持续的，提示可能频繁出现

（3）流程成功

notification

6.过渡

（1）系统正在进行某一行为，如保存、加载、发送邮件等。

inline text

（2）上传文件时

modal

7.警告

使用场景

·系统发现用户工作表格存在隐患（如重复）

·系统提醒用户处理某一长时间没动态的项目

·因为外部原因无法完成某一行为（如批准）

·系统相关问题影响到用户当前板块

·用户将要完成一个具有破坏性的，严重影响的，或放弃完成的行为

（1）表格警告

inline text(+icon variant)

（2）未更新项目

popover

（3）未完成警告

warning toast

（4）系统警告（当前板块）

banner

（5）用户确认

modal