整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
頭條創作挑戰賽#
本文同步本人掘金平臺的文章：https://juejin.cn/post/7082241253819023397
一起養成寫作習慣！這是我參與「掘金日新計劃 · 4 月更文挑戰」的第3天，點擊查看活動詳情。
Yeah，關注我的讀者應該知道，上一篇文章了解 Angular 開發的內容，我們已經概覽了 Angular 的相關內容。在自定義指令的部分，我們已經能夠實現編寫，但是，在實際場景中，我們還需要標準化的管理。
Angular 是 Angular.js 的升版
So，本文，我們就以 Tooltip 來講解下自定義指令的內容。
線上效果圖，如下：
在上一篇文章的實現的代碼項目基礎上，執行命令行：
# 進入 directives 文件夾
$ cd directives
# 創建 tooltip 文件夾
$ mkdir tooltip
# 進入 tooltip 文件夾
$ cd tooltip
# 創建 tooltip 組件
$ ng generate component tooltip
# 創建 tooltip 指令
$ ng generate directive tooltip
復制代碼執行完上面的命令行之后，你會得到 app/directive/tooltip 的文件目錄結構如下：
tooltip
├── tooltip // tooltip 組件
│ ├── user-list.component.html // 頁面骨架
│ ├── user-list.component.scss // 頁面獨有樣式
│ ├── user-list.component.spec.ts // 測試文件
│ └── user-list.component.ts // javascript 文件
├── tooltip.directive.spec.ts // 測試文件
└── tooltip.directive.ts // 指令文件
復制代碼嗯，這里我將組件放在 tooltip 的同級，主要是方便管理。當然，這個因人而異，你可以放在公共組件 components 文件夾內。
在 html 文件中，有：
<div class="caret"></div>
<div class="tooltip-content">{{data.content}}</div>
復制代碼在樣式文件 .scss 中，有：
$black: #000000;
$white: #ffffff;
$caret-size: 6px;
$tooltip-bg: transparentize($black, 0.25); // transparentize 是 sass 的語法
$grid-gutter-width: 30px;
$body-bg-color: $white;
$app-anim-time: 200ms;
$app-anim-curve: ease-out;
$std-border-radius: 5px;
$zindex-max: 100;
// :host 偽類選擇器，給組件元素本身設置樣式
:host {
position: fixed;
padding: $grid-gutter-width/3 $grid-gutter-width/2;
background-color: $tooltip-bg;
color: $body-bg-color;
opacity: 0;
transition: all $app-anim-time $app-anim-curve;
text-align: center;
border-radius: $std-border-radius;
z-index: $zindex-max;
}
.caret { // 脫字符
width: 0;
height: 0;
border-left: 6px solid transparent;
border-right: 6px solid transparent;
border-bottom: 6px solid $tooltip-bg;
position: absolute;
top: -$caret-size;
left: 50%;
margin-left: -$caret-size/2;
border-bottom-color: $tooltip-bg;
}
復制代碼嗯～，css 是一個神奇的東西，之后會安排一篇文章來講解下 sass 相關的內容...
然后，在 javascript 文件 tooltip.component.ts 內容如下：
import {
Component,
ElementRef, // 元素指向
HostBinding,
OnDestroy,
OnInit
} from '@angular/core';
@Component({
selector: 'app-tooltip', // 標識符，表明我這個組件叫做啥，這里是 app-tooltip
templateUrl: './tooltip.component.html', // 本組件的骨架
styleUrls: ['./tooltip.component.scss'] // 本組件的私有樣式
})
export class TooltipComponent implements OnInit {
public data: any; // 在 directive 上賦值
private displayTimeOut:any;
// 組件本身 host 綁定相關的裝飾器
@HostBinding('style.top') hostStyleTop!: string;
@HostBinding('style.left') hostStyleLeft!: string;
@HostBinding('style.opacity') hostStyleOpacity!: string;
constructor(
private elementRef: ElementRef
) { }
ngOnInit(): void {
this.hostStyleTop = this.data.elementPosition.bottom + 'px';
if(this.displayTimeOut) {
clearTimeout(this.displayTimeOut)
}
this.displayTimeOut = setTimeout((_: any) => {
// 這里計算 tooltip 距離左側的距離，這里計算公式是：tooltip.left + 目標元素的.width - (tooltip.width/2)
this.hostStyleLeft = this.data.elementPosition.left + this.data.element.clientWidth / 2 - this.elementRef.nativeElement.clientWidth / 2 + 'px'
this.hostStyleOpacity = '1';
this.hostStyleTop = this.data.elementPosition.bottom + 10 + 'px'
}, 500)
}
// 組件銷毀
ngOnDestroy() {
// 組件銷毀后，清除定時器，防止內存泄露
if(this.displayTimeOut) {
clearTimeout(this.displayTimeOut)
}
}
}
復制代碼這是本文的重點，具體的說明，我在代碼上標注出來～
相關的文件 tooltip.directive.ts 內容如下：
import {
ApplicationRef, // 全局性調用檢測
ComponentFactoryResolver, // 創建組件對象
ComponentRef, // 組件實例的關聯和指引，指向 ComponentFactory 創建的元素
Directive, ElementRef,
EmbeddedViewRef, // EmbeddedViewRef 繼承于 ViewRef，用于表示模板元素中定義的 UI 元素。
HostListener, // DOM 事件監聽
Injector, // 依賴注入
Input
} from '@angular/core';
import { TooltipComponent } from './tooltip/tooltip.component';
@Directive({
selector: '[appTooltip]'
})
export class TooltipDirective {
@Input("appTooltip") appTooltip!: string;
private componentRef!: ComponentRef<TooltipComponent>;
// 獲取目標元素的相關位置，比如 left, right, top, bottom
get elementPosition() {
return this.elementRef.nativeElement.getBoundingClientRect();
}
constructor(
protected elementRef: ElementRef,
protected appRef: ApplicationRef,
protected componentFactoryResolver: ComponentFactoryResolver,
protected injector: Injector
) { }
// 創建 tooltip
protected createTooltip() {
this.componentRef = this.componentFactoryResolver
.resolveComponentFactory(TooltipComponent) // 綁定 tooltip 組件
.create(this.injector);
this.componentRef.instance.data = { // 綁定 data 數據
content: this.appTooltip,
element: this.elementRef.nativeElement,
elementPosition: this.elementPosition
}
this.appRef.attachView(this.componentRef.hostView); // 添加視圖
const domElem = (this.componentRef.hostView as EmbeddedViewRef<any>).rootNodes[0] as HTMLElement;
document.body.appendChild(domElem);
}
// 刪除 tooltip
protected destroyTooltip() {
if(this.componentRef) {
this.appRef.detachView(this.componentRef.hostView); // 移除視圖
this.componentRef.destroy();
}
}
// 監聽鼠標移入
@HostListener('mouseover')
OnEnter() {
this.createTooltip();
}
// 監聽鼠標移出
@HostListener('mouseout')
OnOut() {
this.destroyTooltip();
}
}
復制代碼到這里，已經完成了 99% 的功能了，下面我們在頁面上調用即可。
我們在 user-list.component.html 上添加下面的內容：
<p style="margin-top: 100px;">
<!-- [appTooltip]="'Hello Jimmy'" 是重點 -->
<span
[appTooltip]="'Hello Jimmy'"
style="margin-left: 200px; width: 160px; text-align: center; padding: 20px 0; display: inline-block; border: 1px solid #999;"
>Jimmy</span>
</p>
復制代碼TooltipDirective 這個指令我們已經在 app.module.ts 上進行聲明，我們直接調用即可。目前的效果如下：
我們實現的 tooltip 是底部居中展示，也就是我們平常使用框架，比如 angular ant design 中 tooltip 的 bottom 屬性。對于其他屬性，讀者感興趣的話，可以進行擴展。
至此，我們可以很好的維護自己編寫的指令文件了。
【完】?
輯導語：一些復雜的B端系統，在用戶用起來時會比較困難，總能聽到用戶說學不會，不會用，為了減低用戶的使用成本，搭建一個全局的幫助系統是很有必要，本文從三大幫助系統類型出發，進行詳細拆解。
一些復雜的B端產品，因為其特殊的業務屬性和復雜度操作使用上門檻不低，總是會聽到用戶反饋不會用、學不會、記不住。為了降低用戶使用成本，保證用戶在一個大型業務系統的可用性，引入一個在全局系統層面用戶幫助體系對于提升用戶體驗是非常有必要的。
Jakob Nielsen于1994年提出的十大可用性原則中，其最后一條原則Help and documentation（幫助性指導原則）是搭建B端用戶幫助體系的核心準則，在理想情況下，沒有幫助文檔就可以使用系統是最好的，但在某些情況下（尤其是B端系統），提供一些引導性的幫助其實是必要的。本文從三種 B 端幫助體系的三種類型主動式幫助、被動式幫助、自動式幫助進行詳細拆解說明。
什么是主動式幫助呢？回歸到生活的場景中，進入地鐵站的方向指示牌，馬路上的路標，都是讓行人們可以根據指示找到想去的地方；剛剛參加工作，一般都會有前輩帶著你學習工作流程，進行教學指導；機場和車站的展示大屏，告訴我們目前車次的檢票口和車輛狀況，這些都是我們生活中主動幫助的例子。
沿用到互聯網產品中也是一樣的，同樣也是主動幫助向用戶提供幫助，讓用戶盡快熟悉系統。
對于第一次接觸系統或者第一次接觸系統中某個模塊的新用戶，剛開始使用產品的時候，需要快速熟悉并嘗試系統中的某一功能，這個時候系統提供一些主動的功能介紹或者操作引導可以讓用戶快速了解。
下面是一款室內裝修設計師畫圖使用的系統，屬于操作復雜的工具類型，對于新用戶來說在第一次進入系統主動出現一個彈窗介紹完成渲染出圖的步驟，可以讓用戶快速學習到什么使用這款產品做一個設計效果圖，也讓用戶清楚了解每個步驟之間的先后順序。
對于老用戶當系統新上線了功能需要告知哪里更新了，更新了什么內容。花瓣更新了點擊頭像下拉后展示更多信息的功能，在改版后第一次進入系統，出現了提示引導，引導用戶快速點擊進行體驗，當然也可以選擇關閉。
使用主動幫助有 2 個核心場景，「對新用戶幫助教學」和「新功能上線后對老用戶的提示」； 總結 5 種交互形式：引導頁、模態彈窗、向導形式、工具提示、文字提示，需要設計師根據不同的場景，去適配不同的引導方式。
在用戶首次進入產品或者產品中某個獨立功能的時候，將產品最核心的功能加入一些品牌基調展示給用戶，可以加入一些插畫或者視頻吸引用戶，另外需要注意在文字部分不要長篇大論，提煉最核心的內容傳達給用戶。
讓用戶聚焦當前內容，在用戶第一次打開某個特定頁面時出現，缺點是用戶容易忽略或者無視，直接關掉，引導的效果差一點，所以彈窗教程建議保留二次進入的入口，當用戶需要的時候可以順利找到。應用場景有「版本更新提示」「新功能介紹」「常規通告」。
設計形式上可以在文本的基礎上加入圖片、插畫、動畫、視頻講解和實例演示等視覺表現形式，不管用什么形式，其目的都是幫助用戶快速理解系統的功能特性。也可以使用一些視覺元素烘托氛圍，并在文案上注入情緒化的表達，從而提升用戶的關注度。
承載內容上可以師簡單業務邏輯的功能說明或單頁面功能，采用讓用戶一次性進行學習。復雜業務邏輯的功能說明或多頁面功能聯動，通常會進行分步講解，通過循序漸進的形式將所有知識點逐漸披露出來，讓用戶有充裕時間進行信息的接收和理解。
在用戶首次進入相關頁面，且無操作時出現。有明確的指向性，提前告知用戶具體功能的使用場景，因此它會具體指向界面中的某些特定區域，同時會隨著具體操作的具體位置發生變化，讓用戶實際感知到功能的整個運轉邏輯和流程。針對局部功能升級的提示說明，一般與元素綁定關系較強，可讓用戶直觀了解關注點，提升功能觸達率。
設計組成元素蒙層（可選）+ 文字 + 插圖/GIF（可選）。向導主要圍繞某個操作的引導說明，與元素綁定關系較強，核心功能和操作在視覺上突出顯示。
為了讓用戶高效獲取信息，一次僅顯示一條。如果需要用戶聚焦了解功能或說明，不被頁面中其他元素干擾使用蒙層，注意蒙層的透明度要比彈窗蒙層淺，向導的蒙層需要用戶可以看到元素在頁面中的位置。具體使用過程中有三種交互方式隨著提示強度由強到弱依次是：「分布引導」「氣泡提示」「閃點提示」
分步式引導（重）：常用于頁面多個功能升級的引導組。當頁面有多個升級點，直接平鋪會讓頁面臃腫不聚焦。通過「下一步」操作，逐步喚出剩余引導。為避免步驟過多導致用戶疲勞，建議最多不超過5步。
氣泡式（輕）：相對輕量的引導，有足夠的提示性但不影響其他功能操作。
閃點提示（弱）：微輔助型提示，常與氣泡引導配合使用。在需要關注的地方閃爍，點擊閃點后喚出關聯氣泡提示。不對用戶造成視覺干擾，又能引起一定的關注。
文字提示作為最直觀的信息展示，一般會采用直接平鋪的展示方式，針對一些功能較多邏輯較為復雜的頁面，將對用戶有幫助的信息直接放在頁面上從而指導用戶的行為不失為一種簡單粗暴的設計方法。對重點或復雜功能提供直觀描述或建議。
帶有引導性的文案處理，會促進用戶優化填寫方案，輸入更合適的內容。關于文案設計的詳細延展查看https://www.zcool.com.cn/work/ZNjA3NzU1ODA=.html這篇文章非常詳細的拆解了文案設計原則以及使用場景。具體的使用場景有：「頁面功能輔助說明」「占位提示」。
工具提示比文字直接展示要更簡潔降噪，沒有直接進行展示，在用戶需要的時候通過懸浮或者點擊元素以氣泡的形式呼出，Material Design在對工具提示（Tooltip）的官方定義是這樣的：“When activated, tooltips display a text label identifying an element, such as a description of its function.”工具提示僅僅起到提示的作用，它會出現在當用戶激活某一控件的時候，針對某一特定的元素通過簡要的文字來闡述其功能特性。
在設計形式上有短暫性、匹配性、簡明性的特點：短暫性指工具提示出現和消失的時機需要恰當和短暫；匹配性指工具提示需要出現在與之關聯的元素附近；簡明性則是對工具提示承載的文本內容提出了要求，要盡可能具備簡短性和描述性。
被動引導映射到我們生活中的場景下可以看作是手機地圖導航軟件，當你不知道該怎么走或者迷路的時候才會主動去打開地圖軟件進行導航。
另一個生活中的場景是產品說明書，在使用前或者再遇到不會用的功能的時候才會去查閱說明書，無論是導航軟件還是說明書它不會自動把全部內容展示在你眼前，都需要你去進行查找。沿用到互聯網產品中是指用戶遇到問題的時候系統能夠提供一些幫助，去指導用戶接下來怎么做。
被動式幫助一般會依托于主動式幫助，產品發展的初期階段，主動式幫助是必須的，當產品發展到一定規模具備一定成熟度后，被動式幫助的引入就可以極大的提高整體產品的使用體驗。常用的被動引導有：幫助中心/幫助文檔、客服支持、全局常駐性功能。
重點信息的匯總或提示。此類提示完美融合于頁面，醒目且對操作無干擾，用戶可根據披露內容判斷是否處理。常用的交互形式是全局提示、徽標，向用戶傳達信息的變化并提供快速觸達的能力，無形中提升用戶響應效率。
全局提示：不同顏色的提示條。常作為前置提示存在于頁面或模塊頂部，為用戶順利操作提供指引性幫助。既不打斷用戶當前操作，又足夠明顯，一般需手動關閉或事件結束后自行消失。不同顏色屬性不同：一般藍色代表消息通知、綠色代表成功、橙色代表警示、紅色代表錯誤或異常等情況。
徽標：形態各異的小紅點。常出現在圖標、按鈕右上角的紅色圓點、數字或文字，簡單且醒目。表示內容更新或有待處理的信息，此類提示符合用戶心智，無需教育就能向用戶精準傳達提示意圖。使用時注意無數字與有數字的應用場景。有數字的徽標給用戶帶來的心理壓力會更大，也會更吸引用戶注意力，同時需注意數字長度控制。
客服中心是B端產品的服務團隊和客戶建立聯系的平臺，目前大部分客服采用智能客服+人工客服的組合，通過智能客服先過濾已經在幫助中心的問題，可以解決 80%以上的共性簡單的問題，剩下沒有辦法通過智能客服解決的問題會轉接到人工客服。
在設計上通常懸浮在右下角以入口或者懸浮窗口的形式，可以加入品牌形象IP、情感化來提升存在感，吸引用戶關注拉近平臺與用戶的距離。
幫助中心是全平臺信息文檔的匯總，提供一個快捷入口，幫助用戶了解他想了解的問題，在幫助文檔中需要注意方便用戶直接進行搜索。文檔內容要針對用戶的核心任務，描述要盡量步驟化和流程化，另外由于大部分用戶實際上都不喜歡閱讀大篇幅文字，如何在文檔中直接傳達重要的信息也很重要。
在設計上為保證用戶高效獲取信息，需突出內容本身，不要度裝飾。框架設計清晰將頁面氛圍導航區和內容展示區，讓用戶通過導航快速定位到想要查找的內容。一般幫助中心會由三部分組成：產品介紹，產品入門和使用，常見問題的匯總。
自助式幫助就就像我們去吃自助餐，不用自己買菜、處理食材、烹飪，飯店直接把我們可能會喜歡的食物準備好了，直接來選擇自己喜歡的食物就可以了。在系統中也是一樣提前預判用戶的預期，直接為用戶提供建議和幫助，或者直接幫用戶自動執行一些任務，減少用戶的決策壓力，不過前提是需要產品設計師考慮非常周全并配合大量數據支撐。
針對一些用戶操作風險較小且系統能力能夠支持的場景，可以直接交付系統來自動完成。一些用戶操作風險較大且系統能力也能夠勉強支持的場景，可以提供部分選項供用戶進行選擇，同時提供必要的容錯能力。常用的自助式幫助引導有智能推薦、錯誤校驗。
系統自動提供內容供用戶進行選擇，幫助用戶做出決策，不過這種設計的前提是平臺有足夠的數據積累，系統通過字段自動為用戶預置內容。
用戶新建每一個內容都需要從頭到尾重新填寫一遍內容，成本極高，可以把高頻的類型變為模版進行選擇。
當操作出現輸入錯誤時，為用戶展示明確的提示性消息，糾正和引導用戶的修改內容。設計的時候需要注意反饋的時機做到及時反饋，將發生了什么，接下來怎么調整告知用戶。常見的有以下類型：toast、表單錯誤校驗、模態彈窗、根據不同的場景適配不同的交互方式。
任何的引導都要注意任何事情都是過尤不及，適當的給用戶提供幫助當然是好的，但是在用戶不需的時候過多的進行引導和幫助反而會適得其反，我們在使用引導和幫助的時候一定要合理的進行判斷，避免適得其反。
本文由@郭大毛毛設計筆記 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
鈕是最常使用的組件之一，但是在與人交流時，還是會覺得大家存在很多誤區，所以本文將圍繞如何使用按鈕展開分析，希望能給大家帶來一些新的思考。
按鈕是任何用戶界面當中（無論是桌面還是移動用戶界面）必備的交互元素：甚至可以說，如果頁面中沒有一個按鈕，整個頁面設計將是不完整的。在日常生活中，按鈕也是隨處可見的，一個電燈開關、遙控器按鈕，現實生活中按鈕反復的出現也可以幫助我們不斷去理解屏幕世界中按鈕應該如何操作，從而衍生出屏幕世界中的按鈕的具體形態。
人機交互中最重要的就是把我們從小到大對于這個世界的認識映射到屏幕世界中，比如蘋果最為經典iOS的滑動解鎖。
而到了屏幕世界中，控件的設計更應該與物理世界保持相對的一致，這也是按鈕設計中，尤為重要的一個環節。
最近常問身邊的朋友，按鈕究竟是什么？
他們多數的回答：“按鈕就是按鈕唄，還能是什么～”
因為對于他們而言，按鈕不就是一個操作區域加上文字，沒什么特別的，也正因如此，對于按鈕的具體構造也不太了解。這篇文章主要是根據自身的工作經驗，結合當下對于按鈕設計的理解，去分析如何進行更合理的按鈕設計。
對于每個設計師來說按鈕并不陌生，在每天的設計中，都會使用按鈕進行頁面設計；但又不是每一個設計師都能夠將按鈕設計好，因為它存在三個方面的復雜性：
因此一個看上去小小的按鈕，其實經常會困擾著我們，如果剛開始沒有將按鈕進行整體的梳理，那么在你的設計過程中，按鈕會經常打斷自己的設計思維，為了讓大家能夠對按鈕有更深的理解，我將按鈕進行系統的拆解，結合實際案例，能夠使按鈕更淺顯易懂。
在文章按鈕類型的分析中，我將按鈕分為兩大類、十小類，將其分類也是為了更好的為大家去分析每一個按鈕所涉及到的狀態，當我們理解按鈕之前，你需要了解它的內部構造。
首先，拋出一個問題給大家，下圖中，共有幾種按鈕形式？分別是什么？給大家五秒鐘時間思考。
如果你對上圖的按鈕形式并不完全了解，建議你拿好小本本，做好筆記～
在開始講常見按鈕類型前，我們必須要搞清楚一個重要的知識點：按鈕狀態。
按鈕狀態，可以讓用戶知道這個按鈕當前是在進行哪一種操作，方便幫助用戶進行判斷。
常見的按鈕狀態分為：正常狀態(Normal)、聚焦狀態(Focus)、懸停狀態(Hover)、激活狀態(Active)、加載狀態(Loading)、禁用狀態(Disabled)，下面分別對這六大狀態進行拆解。
正常狀態 (Normal)：除了其他五種狀態外的情況都是正常狀態，它是按鈕最為常規的狀態形式，也是設計師必須設計的一種狀態。
聚焦狀態 (Focus)：主要是用于展示當前電腦光標所在的具體位置。聽起來有點玄乎，我來講他背后的原理，主要是方便一些鍵盤使用的用戶，可以使用Tab鍵或者方向鍵來對網頁進行訪問輸入。
比如在Mac OS 以及 Windows的使用中，通過點擊Tab，便展示出文件的Focus狀態。
Focus狀態是一個非常重要的交互形式，但是很多設計師都會忽略，甚至在很多網站，直接就是將這個樣式所去除，導致使用Tab鍵無法獲取聚焦的反饋，比如常見的百度、Google再到各大操作系統都會有這類反饋，去除這類反饋，會導致用戶無法用方向鍵控制光標位置，在很大程度上降低用戶使用的可能性。
懸停狀態 (Hover)：在桌面端的設計當中，即使用戶知道它是可以點擊的，但是你還是需要設計懸停狀態，表明鼠標現在正在按鈕上。平板電腦和移動端的設備上用永遠不會展示懸停狀態，因為你的手指是無法在屏幕上進行懸停的（雖然IPad OS 更新了13.4版本后，會有Hover態的出現，但是是通過鼠標進行操作，因此這里不予以討論）。
激活狀態 (Active)：激活狀態因為叫法不同，在有的地方也稱之為Press狀態，它的表現就是將按鈕按壓下，將顏色變深同時會涉及到內陰影等效果的出現。
禁用狀態 (Disable)：按鈕禁用狀態作為最難設計的狀態之一，主要在于禁用狀態的表現形式以及禁用狀態與激活狀態之間如何的切換，我具體來分析一下兩個難點。
難點一：禁用狀態在顏色上首先會給人灰色塊的感覺，行業里也稱之為置灰，在設計上，也需要注意光標移動時需要展示禁用光標，即讓前端大哥將Cursor的hover狀態更改為not-allowed，你可以優雅的在前端面前裝個X（之后會出一期，簡單聊聊我與前端如何協作如何裝X）。
難點二：禁用與激活狀態的切換，比如在一個注冊頁面中，需要姓名與電話必填，當用戶沒有填寫完成姓名與電話時，應該將按鈕置灰，提示用戶不可以點擊，當用戶填寫完成必填字段后，將禁用按鈕轉變為激活按鈕，提示用戶可以點擊登錄。
加載狀態/Loading：按鈕需要時間進行加載的一種狀態，通常會被用戶忽略，但是在B端產品中，Loading狀態尤為重要，這里有很多細節和小技巧，展開講篇幅太大，在文中4.3（按鈕細節）會詳細解答。
主按鈕為頁面中按鈕區最為核心的操作，在日常場景中，主要按鈕一般都為新建、編輯、保存這一類正向的操作，強調頁面中最為核心的功能，能夠讓用戶一看到主按鈕就明白大致在頁面中需要如何操作。
但在主按鈕的使用中，要遵循以下兩個原則：
1）在頁面當中，按鈕區域的主按鈕最好只有一個，否則會對頁面的主要功能造成干擾。
2）并不是每一個頁面都需要有主按鈕，不要因為頁面缺失主按鈕而強行加上。因為在實際使用中，時常遇到按鈕之間為平級的關系，強行添加，容易造成頁面層級混亂。
在主按鈕中，按鈕狀態的設計也會跟隨物理世界進行相應的映射，因此在設計時需考慮現實生活中的狀態。
比如用戶的Hover時，一般都將按鈕抬起并亮度增加，其目的是為了提示用戶可以點擊，而用戶在按下時，用加黑來表示用戶按下的狀態，與現實生活中按鈕的狀態類似，因此按鈕狀態應該映射物理世界。
次按鈕在頁面中出現最為頻繁，在日常使用中，如果你不太確定使用何種按鈕時，那使用它，大概率沒有錯。因為它運用廣泛，出現頻率也最高，因此也被人們稱為標準按鈕。
在次按鈕的設計形式中，我們團隊將設計形式分為兩類：
第一類 字線型
此按鈕整體以文字+邊框的形式，這類形式在視覺層面上感知較弱，適合幾個按鈕同時展示，在B端項目中，字線型也是在使用中最為頻繁的形式。
第二種 字面型
字面型更偏向表達按鈕整體，常見于各類移動端的按鈕當中，整體的表達也更適合移動端這類屏幕尺寸較少的設備當中，更符合卡片化設計的思路，反而不太適合桌面端的設計。
文字按鈕為頁面中視覺層級較低的按鈕形式，因而可以在頁面中大面積的重復使用，文字按鈕與鏈接（Link）基本一致，且沒有太多區分，所以在設計上，文字按鈕與鏈接基本相同。
文字按鈕重復的出現，以表格頁面當中的操作列表最為突出，因為表格當中常用的操作最好能夠直接展示出來，因此表格中基本都采取文字按鈕的形式。
圖標按鈕為頁面中控件占比最小的按鈕，所以在頁面中的使用也是最為高效的。因為沒有了文字元素，會導致用戶在圖標的理解上出現偏差。為了解決這一問題，主要是通過用戶在Hover時使用展示Tooltip提示按鈕的含義，同時建議在圖標按鈕的使用上多為高頻且易理解的圖標。
我舉一個簡單例子，在桌面端產品中，幫助文檔一定是非常重要的一個入口，當用戶對頁面中的功能有所疑惑時，可以通過此來幫助用戶進行理解，通常需要在大多數頁面當中展示幫助中心的入口，這時圖標按鈕就變得最為合適。
因此，我們可以得出圖標按鈕的應用場景通常為：當頁面中需要高效的展示一個或幾個圖標時，同時圖標按鈕的展示最為頻繁時，當同時滿足以上兩點，使用圖標按鈕就是一個更優的解決方案方案。
按鈕菜單為頁面中許多操作的集合，通常是將高頻的操作以及一些低頻的操作進行整合，組成的按鈕菜單。這樣既能夠減少頁面元素的冗雜，同時也能夠滿足業務對于功能的需求。
舉個例子，在表格頁面當中，B端設計師最常見到的按鈕菜單就是新建，這類新建按鈕其實是必不可少的，同時業務需要，還需要多個業務按鈕進行展示，按鈕菜單的出現，幫助用戶進行按鈕的整理，同時也滿足業務需求。
這其實是主按鈕的一種衍生，通過圖標對主按鈕的含義進行解釋，從而幫助用戶提高這個按鈕的識別性。如果一個按鈕你想比主按鈕更加強調，那便可使用在按鈕中添加圖標，這樣既能夠強化圖標的含義，同時也加深了用戶對于按鈕的印象。
在六個常見按鈕形式中，我們根據重要的優先級，給常見按鈕進行一個簡單的排序：
圖標按鈕-按鈕菜單-主按鈕-次按鈕-文字按鈕-圖標按鈕
危險按鈕在刪除操作中最為常見，通常是為了警告用戶，這個數據刪除不可恢復，讓用戶謹慎考慮。在常見的刪除操作中，都需要用戶進行二次確認，避免用戶誤操作。
當然，在實際業務中，危險按鈕不宜過多，如果業務當中無法避免，需要展示多個刪除按鈕時，推薦采取圖標按鈕進行展示或者Hover過后將其呼出。
幽靈按鈕，看它的名字就能想到它的作用：像幽靈一般透明的存在。
它沒有使用復雜的顏色、樣式，而是用線條表示外部輪廓，證明它還是一個按鈕。同時內部只用文字展示按鈕名稱。它只出現在按鈕背景復雜的頁面當中，比如：漸變色、紋理、動態圖片背景的情況下，幽靈按鈕能夠完美融入到環境當中。
而現如今，傳統意義上的幽靈按鈕已經很少，畢竟在現如今的官網當中，幽靈按鈕已經不再流行，更多的是出現在復雜頁面的“實心按鈕”，而在某種意義上講，這類按鈕才是幽靈按鈕現在的狀態。
幽靈按鈕和次按鈕有何不同？
在形式上，幽靈按鈕和次按鈕看起來沒有并什么不同，因此會有很多疑惑，那我什么時候用幽靈按鈕什么時候用次按鈕呢？
首先幽靈按鈕是屬于特殊按鈕體系中，因此它不會受整個按鈕體系的束縛，比如我在一個設計系統中，分別定義了常規按鈕的尺寸分別是24px、32px、40px，但是我在一個官網落地頁當中需要有一個46px的按鈕出現，次按鈕就完全不合適。其次幽靈按鈕邊框粗細、字體大小都是和常規按鈕體系不同，因此幽靈按鈕就和次按鈕有所不同。
第二個方面在次按鈕的設計形式中，不僅僅只有描邊按鈕這一種形式，因此幽靈按鈕與次按鈕它們可能會有交集，但是屬于兩種不同類型的場景，因此也不能將它們混用。
在Material Design 出現之初，懸浮按鈕受到了很多人的追捧，它也是安卓設計的代名詞。主要是用于頁面當中最常用的操作，是整個APP中最核心的按鈕，能夠代表這個產品的核心功能，比如記賬軟件的添加賬單記錄，印象筆記的新增筆記（安卓）。
但沉浸式設計的出現，使得移動端寸土寸金的地方，需要固定一個按鈕的情況就變得更加少見。
而在B端的設計過程中，逐漸衍生出了B端行業特有的方式。
懸浮按鈕在B端場景中，主要是幫助用戶進行輔助咨詢的功能，例如在一些用戶需要得到幫助的頁面中，可以通過懸浮按鈕，使用戶的又疑問的頁面進行快速提問，幫助用戶能夠進行快速的跳轉，在飛書的應用列表中，其實用戶剛開始理解應用列表其實存在一個理解成本，就可以通過懸浮按鈕進行展示（后面有機會聊聊B端改版厭惡時也會提到）。
行為號召按鈕簡稱：CTA按鈕，主要目的是為了號召人們在某些特定的頁面中使用此按鈕來提高轉化，比如立即購買、聯系我們、立即訂閱等等…
大多數時候，CTA按鈕都是成對出現的。“是與否“ 、“登錄與注冊”、“確認與取消”等。因此，分析清楚CTA按鈕后設計出視覺層級合理的頁面稱為非常重要的點。在設計中，一般會采取漸變色、主題色、主題色的互補色等等，它經常獨立出現。
在B端軟件的場景中，官網是CTA按鈕出現最為重要的頁面，一般在官網中，使用CTA按鈕將用戶引導從潛在客戶向付費客戶進行轉變（點擊過后一般是一個聯系表單進行信息的填寫），這也是在B端產品中非常重要的指標：潛客向付費客戶轉變。可以引導用戶進入到下一個階段，如果CTA按鈕設計不好，人們對于官網只是瀏覽，不會有任何轉化。
因此，在設計CTA按鈕的形式與位置時，需要與產品、設計、運營等共同確定并討論使用，大家站在不同的立場希望得到一個完美的方案，因為設計出清晰的結構層次將直接引導用戶朝著理想的使用路徑前進，從而極大提高轉化率。
在我們日常設計中，常常會遇到一些棘手的文案問題：登陸、登錄、確認、確定、發送、發布，在許許多多的工作場景中，猶豫究竟應該在按鈕上使用哪種文案，這就需要我們通過具體的案例場景進行展示相應文案。
這些細節的文案就是幫助用戶去理解頁面中所傳達的真正含義，多將文字放置到場景中，文案也更好的輔佐他們作出選擇
圓角在每一個軟件中，隨處可見。圓角大小所帶來的不僅僅是視覺表現，還更多影響著用戶的使用體驗以及對于產品而言的整體的認知，如果在開始設計之前，沒有對按鈕圓角有具體的規劃，很容易踩坑，如何設計好圓角，我們來進行系統分析
在下文中我們將按鈕的圓角大小，分為以下三類：直角、圓角、半圓。
直角：
按鈕四角的方向，具有很強烈的引導性，看上去也會更加刺眼，使得在頁面當中注意力會減弱。同時，直角在按鈕排列當中看上去更加統一，相同的東西在視覺上不太能引起我們的注意。
圓角：
相比與直角按鈕，在使用圓角的按鈕中，視覺上總是給人一種柔和親近的感覺，當幾個圓角按鈕進行排列時，能夠感受到圓角按鈕更容易被點擊。因此在使用的按鈕中，建議添加圓角的細節元素。
為何直角的物體會給人更嚴肅的感受——每一個人都認為圓角會更好，但是并不是每一個人都能夠解答為什么圓角更好。
在巴羅神經病學研究所對拐角的科學研究發現，“拐角的感知程度隨著角度線性變化。銳角比鈍角產生更強的幻覺顯著性”。換句話說，拐角越尖，則出現越亮。拐角越多，越難看。
圓角還有另一種解釋，是因為現實生活中有圓角的物體會更友好。從小，我們就知道尖角的物體會讓人受傷，圓角的物體會更安全。這就是小孩在玩皮球與刀的時候，家長的反應完全不同。
小朋友玩刀會讓家長十分的緊張，趕緊讓孩子放下；而小朋友玩皮球時，家長則是非常的放心。這激起了神經科學所謂的尖銳邊緣“回避反應”。因此，我們傾向于“避免鋒利的邊緣，因為在自然界中它們可能會構成危險”。
圓角是不是越大越好？
通常在移動端場景中，半圓按鈕隨處可見，移動端手指觸摸操作上，對于圓角的影響小之又小；而到了桌面端的場景下，鼠標的使用，半圓按鈕就會有所不妥。
如果相同面積中，按鈕的圓角增大，相應的對于按鈕的可操作區域就會隨之減小，在同等尺寸下的按鈕中，小圓角的按鈕明顯比大圓角的按鈕更容易操作。
當然，麻煩事還不僅僅于操作區域，在結合實際業務，我們的按鈕常常作為原子（原子設計理論）用來組成為下拉菜單進行聯動，半圓按鈕在下拉菜單的設計中，也會因為半圓的局限，使下拉菜單的設計會更加困難，同樣在設計上，半圓角對于下拉菜單的適配也會相當突兀，因此在考慮這方面設計時，需要你多去思考之后的業務場景。
按鈕的狀態中，Loading狀態通常不會對用戶進行直接展示，因為大多數情況下，Loading狀態就發生在一秒鐘以內，但是對于B端場景中有很多重要操作，在長時間等待中不展示loading狀態，會導致用戶在使用時犯下錯誤。
需要在合理的時間進行反饋
舉個例子：比如一個確認提交的按鈕，由于網絡或者服務器等原因，需要長時間加載資源，而用戶不知道我剛才按下的按鈕是否有效，這時用戶慌張，想要多按下幾次這個按鈕，系統就會不停提交數據，最后網絡變好時，窗口就會一瞬間瘋狂展示，導致用戶體驗下降。
為了防止這類事情的發生，需要在設計師考慮到按鈕在加載一秒以后的狀態，應當提示用戶在網頁已經收到請求，正在加載，同時在按鈕狀態中應該為不可操作狀態。同時會給出加載轉圈的動畫，緩解用戶的焦慮。
當你完成了第一步的設計后，想想在按鈕的狀態中，是否更能夠幫助用戶進行體驗上的提升呢？
這也是在面試某大型互聯網公司時，被問到過的一個問題～敲黑板。
對用戶操作的適當反饋是用戶界面設計的最基本準則。讓用戶了解當前狀態、位置、是否成功、進度如何，減少不確定性；并引導他們在正確的方向上交互，而不是浪費精力在重復操作上。
在Loading的加載過程中，等待焦慮一直是用戶想要了解到的，為了緩解類似情況，可以將等待的進度狀態進行展示，使的用戶在等待的過程中，能夠清晰的清楚自己的按鈕目前處于何種狀態，我大概還需要等待多久，緩解用戶在等待過程中的焦慮。
以上兩個方式均是尼爾森十大原則的內容，能夠在按鈕Loading狀態中，緩解用戶在按鈕加載過程中、重復提交、等待焦慮的問題，通過一些設計小細節，幫助產品提升用戶體驗。
通過上文對于按鈕的解釋，大致明白按鈕在設計中的作用，接下來我結合一個工作中的實際案例，來看看我們應該如何優化常見按鈕在頁面當中的設計。
項目背景：在桌面端，我們需要對整個導航欄進行設計改版，但其中涉及到對于導航的一個整體優化，主要是由于業務功能發生變化，我們需要在導航欄上增加快捷添加入口和通知中心，來滿足導航的后續的功能需求，由于保密協議的原因，就不放自家產品。
在桌面端中，瀏覽模式大致分為兩類，F型瀏覽模式、Z型瀏覽模式（下方知識拓展會有講到）。
首先，因為導航在整個頁面的頂部，結合兩種瀏覽模式在頂部時統一都為從左到右的瀏覽順序。
因此確定整個導航按鈕初步的按鈕重要層級排序。
我們對于用戶的按鈕層級有著明顯的劃分，因為在整個導航右側，又因為其的特殊性，我們把操作空間分為三部分：
左側為操作路徑最短的區域，因為桌面端的產品需要通過鼠標進行交互操作，而其中移動鼠標的長短直接決定用戶是否愿意點擊這個按鈕，因此，靠左的按鈕適合放置用戶最常使用的操作。
中部為按鈕內部區，可以放置一些低頻，但是又必須出現在這個區域的按鈕操作（比如：幫助中心、通知中心等等…）。
右側為按鈕最為重要層級最弱的區域，同時它也有一些特殊性。
一般在瀏覽器的右側，為用戶最容易定位的操作區域，因為靠近邊緣導致在用戶定位當中能夠幫助用戶進行快速選擇。
回到頁面中信息層級較高、同時需要精準定位的按鈕就會將個人中心放置在最右側，方便用戶進行快速定位。
因此我們講導航當中按鈕重要層級進行簡單排序，得到下圖：
通過親密性原則，我們將除去左右兩側確定好的按鈕之外的按鈕進行簡單分類，將有關聯的按鈕進行組合，形成較強的關聯性～
視覺調整作為最重要的一步，主要是為了在最后的按鈕重要層級上，將一部分按鈕突出、一部分按鈕弱化，達到我們想要的整個層級效果。
通過團隊內部討論，將我們的新增按鈕定位CTA按鈕，因為它關聯到我們每個使用系統的人都會用到，屬于最高頻的操作按鈕，也因此將其突出。
F型瀏覽模式：
是新聞平臺、博客等文字為主的網站布局所采取的閱讀模式。
該閱讀模式由尼爾森團隊的眼動追蹤研究結果從而進行普及，在這個研究中記錄了超過200位用戶瀏覽網頁時，發現用戶的主要閱讀行為在許多網站和場景中表現得相當一致。這個閱讀模式看起來有點像字母F，因此也被叫做F型瀏覽模式。
首先用戶以水平方向進行閱讀，通常是在閱讀區域的上半部分。
接下來，他們在屏幕左側垂直瀏覽，尋找段落開篇幾句中感興趣的內容。當他們找到感興趣的內容時，他們在第二個水平方向上快速瀏覽，通常這塊內容區比上一個內容區更短小、更簡潔。這部分元素形成了F的下半部分。
最后，用戶在垂直方向上瀏覽內容的左側區域。
Z型瀏覽模式：
是掃描滾動的網站的典型模式。
正如你所期望的，“z”型模式的布局遵循字母Z的形狀。“Z”型模式的設計跟蹤了人眼掃描頁面時的路線——從左到右，從上到下：
當觀眾的視角以這種模式移動時，它形成一個虛構的“Z”字形。
在實際工作中，經常遇到自己設計的按鈕與開發實際還原的按鈕差距很大，一些沒有經驗的設計師會和開發說，你看我設計稿，每一個按鈕都要按照設計稿的來，這樣設計師與前端開發之間的矛盾就會越來越深。其實在按鈕設計的細節中，開發怎么完美的還原，里面還有很多細節。
首先要想讓開發完全還原你的設計稿，就必須了解開發實現的思維方式，針對它的思維方式進行相應的思考。
又由于Sketch與開發常使用的VScode之間邏輯上存在較大差異，導致設計師設計出來的很多設計稿開發根本無法實現，這也是B端設計師擺在你面前的第一個問題。
對你沒看錯，無法實現，我舉一個例子：
這是一位同學問我的一個問題，他說我這個按鈕為啥實現不了，前端不就是多幾個代碼去適配我的設計稿就可以了嗎？
如果你也有很多疑問，那就接著看下去～
什么是Padding
在按鈕當中，通俗的理解Padding就是文字與按鈕之間的間距。
因為Sketch等軟件在按鈕的設計中，只有圖形位置的概念，沒有內間距Padding的概念，因此需要對按鈕還原要明確的描述。
比如上圖，前端同學在開發就會將Padding設置為24px，所以整個按鈕長度便為24px*2+20px（文本寬度）=68px。
而為什么說上面的設計規范實現不了，因為對于前端而言，Padding通常都是統一且固定的，只會根據按鈕文字長度進行相應的調整，比如我上面舉的錯誤栗子，其實在前端同學面前這類設計是不能夠被共用，而且對前端同學項目會變得越來越不能維護，所以按鈕設計應該更規劃。
但是如果真的需要去實現兩個文字按鈕長度和四個字的一樣怎么辦，需要去設定按鈕的最小寬度。
按鈕最小寬度的設定一般為4個字文字的長度，假設字體大小為16px，左右的Paddung為24px。
最小寬度為：88px，因此在按鈕的標注中，需要展示最小間距為102px，方便前端進行CSS開發。
在我們的sketch中，按鈕邊框有三種，內邊框、居中邊框、外邊框，默認為居中，但是在前端的CSS代碼中沒有居中邊框，沒有居中邊框，沒有居中邊框（重要的事情說三遍），默認為內邊框，如果需要調整為外邊框，最好能夠標注。
按鈕雖然作為一個最基礎的元素，但是在整個設計體系中，它一直都扮演著一個十分重要的位置，在思維中，任何組件都可以通過上面按鈕的思維，對每個組件進行拆解分析，無論是組件的狀態、組件的類型，在實際工作中，都需要你去深入思考。關于我呢， 也因為踩了很多坑，因此想分享給大家。
https://blog.prototypr.io/8-rules-for-perfect-button-design-185d1202ee9c
https://medium.com/@uxmovement/when-you-need-to-show-a-buttons-loading-state-41fc4d5e3c65
https://atlassian.design/guidelines/product/components/buttons
https://uxmovement.com/thinking/why-rounded-corners-are-easier-on-the-eyes/
B端設計：盤點篩選控件的基本知識
B端設計：導航菜單的設計5步法
作者：CE，2B行業的2B設計師～。公眾號：CeDesign
本文由 @CE 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
