作者 usagimaru 目前在 Goodpatch 身兼 Application Designer 和 Interface developer，對於 UI 設計和 Interaction 都有涉略，並將其應用在 App 設計開發當中。在 Goodpatch 經手過「さんちの手帖」「VEGERY」「JINS MEME OFFICE v1」等三隻 iOS App 的開發。
本篇作者平時就常撰寫以開發者角度來觀察使用者介面的文章，這次將以「文字用語」為主題，試著剖析 iOS 中的 對話框 設計。大舌頭強烈建議讀者可以從頭到尾看完喔，對初階設計師來說，可以讓思考更加全面；對於非設計師而言，可以了解為什麼設計真的是門專業，以及為什麼需要花那麼多時間囉～
原文由 Goodpatch 投稿提供 -從「取消的取消」問題思考如何設計對話框
何謂 對話框
" 對話框 " 是一種以文字與使用者對話的使用者介面。其中，「警告對話框」（Alerts，以下簡稱警告框）通常用於通知使用者發生了錯誤或警告，並詢問接下來的操作（同意、不同意等等）。使用警告框時必須十分注意，因為使用者並不希望正在進行中的工作受到打擾。
「確定 " 執行取消 “」和「取消 " 執行取消 “」
首先請看以下的圖片：
這是一個警告框的例子，首先以說明文字詢問使用者是否要中斷目前的操作，接著給了「取消」和「好」兩個作為行動的選項。看了這個例子之後有沒有覺得哪裡怪怪的？
| 文字內容 | 意思 | |
| 問句 | 確定要取消編輯中的內容嗎？ | 確認是否要捨棄編輯中的內容（兩個選項） |
| 同意 | 好 | 捨棄編輯中的內容 |
| 不同意 | 取消 | 保留編輯中的內容 |
在這個語境中，系統向使用者確認是否同意執行「取消編輯中的內容」。大部分同意執行的使用者，可能會直覺地按下相同文字的「取消」按鈕。可是這樣的話並不會取消編輯。
因為這個取消按鈕指的是「取消『取消編輯中的內容』」。也就是說，若想要如使用者所想的捨棄編輯中的內容的話，必須選擇另外一邊的按鈕。像是「取消執行取消 」這種具有雙重否定意思的對話框，會讓文字的意思變得複雜，應該要避免使用。
那麼我們試著改變按鈕的用詞來避免「取消執行取消」。
這樣應該就不會造成混亂了吧……？
但這樣的修正方式並不好。只從「是」、「否」的文字，很難想像按下按鈕後的結果，用在對話框的按鈕並不適當。
接著我們來試試看大家一定都看過的警告框。為了防止被大家吐槽說明不夠清楚，我們加長說明文字，如同以下的圖片：
是！咦，等等，否？
因為這個警告框在最後說了「建議您事先儲存」，想要這麼做的使用者想必會直覺地按下「是」。然而，若是選了「是」的話，就會執行原本詢問的問題「取消編輯中的內容」，這樣不要說儲存了，編輯中的內容反而會被刪除，對使用者來說是最糟的情況。
設計簡短、有邏輯且適當的文案
剛才的例子可以說是因不適當的文案而造成的：「文字bug」。在 UI 設計的過程中，往往容易忽視文案的設計，若是能夠注意幾個重點，「文字bug」是能夠避免的。
我們再看一次最初的警告框：
這個警告框的說明文字並不恰當，並且選項的按鈕用語也是錯誤的。
為什麼都不對呢？首先，在說明文字中直接使用「取消」這樣的字眼並不好，因為「取消」這個詞經常用於表示否定意涵的按鈕上，應該避免使用在問句中，以免造成混亂。另外，按鈕的文字應該要能對應說明文字要求的動詞。在前面的例子中使用的「是」、「否」不是動詞，使用者很難想像按下按鈕後的結果是什麼。為了理解意思所需的時間會比以直接以動詞表示（例如「刪除」、「捨棄」）的按鈕還要久。
將「是」、「否」這種沒有邏輯性的文字用於按鈕並不適當。具有否定意涵的動作名稱，請盡可能地統一稱作「取消」。在各作業系統中（iOS、macOS等），「取消」也是用來表示否定意涵的統一用詞。至於具有同意意涵的按鈕，若是使用「好」這個字在語境上讀起來不會覺得奇怪的話，則可以放心使用；需要更具體地傳達意思的話，將「能夠對應說明文字內容的動詞」直接用於按鈕的文字是最好的。
簡潔地敘述說明文字
在說明文字中，盡量不要頻繁地使用太過禮貌但不直接的句子。例如剛才的例子中「確定要～嗎？」的問句，從使用情境來看，決定要捨棄編輯中的內容的是使用者自己，因此我們可把說明文字再縮短成「要～嗎？」的形式。
使用者並不是想要閱讀文章，而是想要盡快地獲得自己想要的內容，太拐彎抹角的說明只會讓使用者跟內容之間的距離變得更遠。
看過上面這些討論，我們可將這個警告框的說明文字中的「確定要取消編輯中的內容嗎？」改寫成「要捨棄編輯中的內容嗎？」
讀者覺得如何呢？雖然跟最初的警告框比起來已變得比較好懂了，但似乎還有改善的空間。
考慮到破壞性操作
在警告框上的同意操作「捨棄」同時也是破壞性操作，因此我們將它的按鈕樣式改成 Destructive Style（紅色的文字）
如此一來就成為下圖這樣：
因為「捨棄」除了是破壞性操作，在這個說明的語境中也具有同意的意思，我們遵照 HIG（Human Interface Guideline）將它放在右邊，表示不同意的「取消」則放在左邊。（在舊版的iOS HIG中，規定若是具有破壞性操作的按鈕，應該放在左邊，而取消則放在右邊，但在 iOS 10中只規定將使用者最有可能選擇的動作放在右邊。因此，像是在主畫面刪除 App 時會出現的警告框，也像上圖一樣把取消放在左邊，並把套用了Destructive Style 的破壞性操作放在右邊。）
看起來很像一回事了吧？不過其實還有一個大問題。
Action Sheet 的功能
上面的警告框看起來似乎很完美了，但其實一開始使用警告框可能就是不對的。警告框是在使用者不經意觸發事件（錯誤等）時，用來詢問使用者的判斷的一種 Modal View（模態視圖）。考慮到這點後，這次的內容「捨棄編輯中的內容」並不符合這種情境。這個警告框是因為使用者主動地按下關閉按鈕才出現的，不能說是「使用者不經意觸發的事件」。
在這裡，Action Sheet 登場了。Action Sheet 也是一種對話框，它能夠提供兩種以上的操作選項，適合在使用者主動操作的情境中用來詢問是否要刪除內容。另外，即使適合使用警告框的情境，若是選項很多的話，也可以考慮改用 Action Sheet。
在 Action Sheet 中，一定至少有一個同等於取消的按鈕，因此選項包含了取消按鈕後，總是有兩個以上。使用者隨時都有中斷即將執行的動作的權力。
是不是看起來更像一回事了呢。
考慮 Action Sheet 的按鈕配置
在剛才完成的 Action Sheet 中，進一步詢問使用者是否要儲存內容似乎也不錯。因此我們需要增加一個按鈕，如下面的表格，我們有兩種增加的方式：
為了知道將「捨棄」按鈕放在上面比較好，還是下面比較好，我們參考 Apple 的 Mail、Twitter、Facebbok 的例子來比較看看。如下面的表格：
Apple 的 Mail 與 Twitter 都將刪除（破壞性操作）放在離取消最遠的位置（同時也是離手指最遠的位置）。然而，Facebook 則相當不同，除了互換了儲存與刪除的位置，按鈕文字也不是「取消」而是「返回」。
雖然不清楚為什麼 Facbook 要這麼做，但一般來說，這種具有刪除與儲存選項的 Action Sheet，按照 Apple 的做法是比較正確的。取消按鈕也不要採用自創的「Go Back」，而是乖乖使用「取消」比較安全。我在看到 Facebook 的這個 Action Sheet 時，覺得不太對勁而稍微思考了一下，造成這種「不對勁」的感覺的原因，其實就是因為採用與標準的 Mail 以及 Twitter不同的按鈕配置，特別是在關係到「刪除」這種危險的動作時，實在不得不謹慎思考。
經過以上的討論，這次 Action Sheet 的設計，A才是正確答案。當然定義 App 本身的設計語言並且展現出獨特的部分也很重要，但首先更應該遵照系統平台的設計語言。
思考沒有選項時，警告框的按鈕文字
有的時候警告框只是用來傳達訊息，比如在說明新功能的時候，會用到只有一個按鈕的警告框。我們可想想在這種時候該如何設計按鈕的文字。一般來說，使用「OK（好）」雖然沒有問題，但在不同的語境中也有可能需要改成其他文字。
另外，只有一個按鈕的時候，將按鈕設定為預設的樣式（粗體字）會比較好。
避免針對警告框本身的動作
請避免在按鈕上使用「關閉」或「返回」等用來表示跳出警告框意思的文字。
讀者可仔細想想「關閉」、「返回」所代表的語境，都是指涉「警告框」這個對象。用句子描述的話其實就是「關閉警告框」、「關閉警告框，並返回到之前的狀態」的意思。但其實「關閉警告框」這件事是理所當然的，沒有必要特別提供一個「關閉警告框」的選項給使用者去按。不管選項是代表同意或不同意的按鈕，只要按下就一定會關閉警告框，因此提供說明文字來說明按下按鈕後的結果是比較適當的。
如果想要在按鈕上使用「關閉」、「返回」等文字的話，請改用「OK（好）」就可以了。大部分的情況下使用「OK（好）」都不會有問題。
不要頻繁地使用對話框
對話框是在使用者進行操作時強行介入的一種「模式」。在 App 中盡量不要使用警告框，也不要毫不思考地使用對話框。例如在 App 開啟時跳出的「新消息」警告框，或者只是告知使用者操作的結果的警告框等，都應該避免使用。
結論
若是需要在 App 中使用對話框時，請注意以下要點來設計：
注意文字是否簡潔易懂並具一致性
- 避免使用像是「取消的取消」這樣的雙重否定表現。尊重在作業系統中使用的文字表現，並注意不要偏離。「取消」是在系統中經常用於表示對於問句的否定，如同「保留字」一般的詞，請不要在其他地方使用它。
- 在按鈕的文字上，建議使用能夠讓使用者預測到結果的動詞。
- 想要在警告框中加入標題以外的補充文字時，請將文字寫在 messageLabel（內文）中而不是 titleLabel（標題）。
遵守作業系統的規範
- 在 iOS 與 macOS 中，有「將表示同意的動作放在右邊，表示不同意的動作放在左邊」的定義，請遵守這個資訊的排列規則。但注意在 Windows 或者舊版的 Android 中，這個規則剛好是反過來的。
- 在 iOS 中，也有「請在破壞性操作的按鈕上使用 Destructive Style（紅色文字）」的規則，若使用了會執行刪除等操作的按鈕，請考慮使用 Destructive Style。
- 在使用者主動選擇行動時，使用 Action Sheet 而不是警告框。
主角是使用者與內容
- 不只是對話框，所有的使用者介面都不應該是主角。介面應該是連接使用者與內容之間的橋樑，並且要盡量保持透明，不干擾使用者。
- 避免讓使用者意識到「關閉對話框」這個行為。在使用者主動採取行動的同時，順便也關閉警告框才是正確的，而不是讓使用者去關閉警告框。
不要頻繁地使用
- 避免什麼訊息都用警告框表示。無論是跟 App 有關的新訊息，成功收藏內容時的通知，開啟 App 時的新功能介紹等等，在思考使用者的核心體驗之後，再考慮是否真的需要。
- 但在發生系統障礙、連線錯誤等無法預期的嚴重情況時，則可使用警告框。
沒有留言:
張貼留言