介面上，你應該常使用到 可拖曳元件 (drag and drop)，例如拖拉 Gmail 的信件到資料夾中、移動 Trello 的卡片或是把 Chrome 瀏覽器上的分頁重新排列等。雖然操作很簡單，但這些互動的設計複雜度超過你的想像。本文就來分享在 VMware 中設計 “可拖曳的元件” 的經驗。
可拖曳元件 的互動細節往往會被使用者忽視，有時自然到你根本沒意識到。但如果你仔細觀察比較下述三個例子，它們皆有非常不同的 UX 標準。
這些元件有不同的操作定義，但這沒有對錯，因為每個產品都可能因為某些原因而選擇不同的模式。例如，Trello 在拖拉卡片時，卡片會呈現傾斜狀，可能是因為符合他們表示對使用者友善的設計語言。
不過最大的問題在於是否套用一致及清晰的 UX 設計標準，否則你有可能在不同頁面使用可拖曳元件的體驗都不一樣。例如 Salesforce 所設計的可拖曳元件庫，裡頭有五種模式，每種操作方式差異都相當大。
雖然都可以運作，但不幸的，在這五種操作模式中存在著不一致，利如使用不同的游標樣式，及三種不同的拖曳處樣式（drag and drop handle），如下：
猜猜看，那個是可拖曳時的游標狀態？答案：全部都是
三條線的 icon 能代表可拖曳？或是三個點的才能？究竟那五種哪個才能代表可拖拉呢？想像一下，如果介面上出現五種表示方式，使用者會有多困惑！在設計系統中，元件彼此間應該看起來或感覺上是一體的，而元件間可拖曳的互動方式也應具一致性。
Design systems 不僅僅要讓 UI 元件一致性，最重要的是提供一致的體驗
可拖曳元件 的案例
以下是我在研究與設計 Clarity（VMware 的設計系統）中“ 可拖曳元件 ”的案例，Clarity 是一個開放源，所以不只是內部員工可使用，外部想利用的人也能使用。
我們的使用者需要透過拖曳來操作一些元件，如樹狀視圖（tree view）、資料表格及卡片，而我的任務即是統一使用者在操作這類功能時的體驗。
- 重新排列與疊組樹狀結點
- 重新排列表格的資料欄（columns）
- 重新排列表格的資料列（rows）
- 在樹狀結構與表格之間拖曳
- 重新排列與合併卡片
對於如 VMware 有著大量數據（data heavy）的企業， 拖曳能讓我們的用戶組織複雜且大量數據的關鍵功能。
創造一個可被理解使用的元件庫
首先，我建了一個簡單且小型的元件庫，讓拖曳功能可有效的被理解感知如何使用，並能應用於不同的專案中。如果你正打造設計系統，以下也許可以幫助你開始思考如何傳達可拖曳元件的模式。
1. 適當的顏色
使用可區別且不是設計系統中常出現的顏色來表示可拖曳的互動，且避免使用已經在介面中定義代表某些意義的顏色（如紅色表示不可逆的行為）。
我們選擇了非系統主要色彩的紫色應用於拖曳的行為上，所以使用者一看到紫色，就會產生可拖曳的期待與體驗。我們避免使用藍色（常用於表示拖曳功能），因為在 Clarity 中，它代表著可互動的按鈕或可點擊的元素。
2. 拖曳狀態的樣式
設計元件被拖曳時的各種狀態，以視覺的方式非常具體的表現“可被拖曳”、“拖曳後”等的樣式。
當元件可被拖曳，它應該有以下的樣式：
另外我們也替“被移動元件”的初始位置加入一個狀態 （ Previous state）。
這個初始狀態可以提醒使用者元件之前的位置，但要注意的是，這個狀態並不適用於要表達“自然拖曳”行為的動作（如拖移圖形化菜單）。
3. 系統原生游標
使用系統原生游標來告知這個元件可被拖曳，這似乎只是小改變，但會大大的提升這些元件的可發現性。
在 Mac 上，我們使用“要抓”（打開 Mickey Mouse 的手） 及“抓住”（Mickey Mouse 的手握緊) 的游標來表示“可被抓”與“已被抓”的狀態。如果那個元件不能被抓，則顯示無效的游標（unavailable cursor）。
在 Windows 上，我們使用“移動”游標（十字雙箭頭）來表示可被拖曳，另也有顯示無效的游標。
4. 放置目標區
應該要設計預計放置位置的模式，讓使用者可看出這個區域是可放置已拖曳元件的。如同上述提到的狀態樣式，放置目標區也應該訂出規範。
既然重新安排元件是一個拖拉過程的關鍵互動，我們應該具體的規劃元件將被放下的位置。
我們在目標區的左邊加個小圓，做出與普通的線或外框的區隔。這是一個非常重要的設計細節，對色盲用戶來說，更能提供一個除了顏色外可辨識的管道。
5. 視情況使用的案例（ affordances）
其中一個視情況使用的案例就是拖曳把手（drag handles）。拖曳手把是透過小 icon 來表示元件可被拖曳。Gmail 選擇了12個小點的 icon，而我們選擇了 6 個小點的icon來表示拖曳手把：
需不需要放置拖曳手把很大程度依賴於使用者心中的模型，如果這組元件通常不會有拖曳功能，這時候放置手把將具有提示效果；但這組元件本來就被預計有這樣的功能，就不需要放上手把了。
例如，我們並沒有在樹狀結構的元件中加入手把，因為樹狀結構本身在使用者心中就有預期是可被移動的。相反的，我們在可拖曳的卡片上加了手把，因為並非所有的卡片都可被拖曳。
最後有個重點，雖然有許多 icon 皆能表示元件可被拖曳，但我們應該選擇與使用其中一款就好。
整合
本文提到的可協助大家建立可拖曳元件的基礎，但還有更多方法來建構這個準則。無論如何，建立可拖曳元件的 UX 準則後，將可以與其他互動的體驗一致，不會覺得突兀。而最後的成品，我放到 inVision 上供大家參考。
參考文章
本文經作者 Grace Noh 授權翻譯，原文：Drag and Drop for Design Systems
本文章所屬設計大舌頭與作者所有，未經授權，不得轉載！如需轉載，煩請通知。
