UI 對話框 的設計大有學問,看設計師如何思考

作者 usagimaru 目前在 Goodpatch 身兼 Application Designer 和 Interface developer,對於 UI 設計和 Interaction 都有涉略,並將其應用在 App 設計開發當中。在 Goodpatch 經手過「さんちの手帖」「VEGERY」「JINS MEME OFFICE v1」等三隻 iOS App 的開發。

本篇作者平時就常撰寫以開發者角度來觀察使用者介面的文章,這次將以「文字用語」為主題,試著剖析 iOS 中的 對話框 設計。大舌頭強烈建議讀者可以從頭到尾看完喔,對初階設計師來說,可以讓思考更加全面;對於非設計師而言,可以了解為什麼設計真的是門專業,以及為什麼需要花那麼多時間囉~

原文由 Goodpatch 投稿提供 -從「取消的取消」問題思考如何設計對話框

何謂 對話框

” 對話框 ” 是一種以文字與使用者對話的使用者介面。其中,「警告對話框」(Alerts,以下簡稱警告框)通常用於通知使用者發生了錯誤或警告,並詢問接下來的操作(同意、不同意等等)。使用警告框時必須十分注意,因為使用者並不希望正在進行中的工作受到打擾。

「確定 ” 執行取消 “」和「取消 ” 執行取消 “」

首先請看以下的圖片:

對話框

這是一個警告框的例子,首先以說明文字詢問使用者是否要中斷目前的操作,接著給了「取消」和「好」兩個作為行動的選項。看了這個例子之後有沒有覺得哪裡怪怪的?

文字內容 意思
問句 確定要取消編輯中的內容嗎? 確認是否要捨棄編輯中的內容(兩個選項)
同意 捨棄編輯中的內容
不同意 取消 保留編輯中的內容

在這個語境中,系統向使用者確認是否同意執行「取消編輯中的內容」。大部分同意執行的使用者,可能會直覺地按下相同文字的「取消」按鈕。可是這樣的話並不會取消編輯。

因為這個取消按鈕指的是「取消『取消編輯中的內容』」。也就是說,若想要如使用者所想的捨棄編輯中的內容的話,必須選擇另外一邊的按鈕。像是「取消執行取消 」這種具有雙重否定意思的對話框,會讓文字的意思變得複雜,應該要避免使用。


那麼我們試著改變按鈕的用詞來避免「取消執行取消」。

alert_02

這樣應該就不會造成混亂了吧……?

但這樣的修正方式並不好。只從「是」、「否」的文字,很難想像按下按鈕後的結果,用在對話框的按鈕並不適當。

接著我們來試試看大家一定都看過的警告框。為了防止被大家吐槽說明不夠清楚,我們加長說明文字,如同以下的圖片:

alert_03

!咦,等等,

因為這個警告框在最後說了「建議您事先儲存」,想要這麼做的使用者想必會直覺地按下「是」。然而,若是選了「是」的話,就會執行原本詢問的問題「取消編輯中的內容」,這樣不要說儲存了,編輯中的內容反而會被刪除,對使用者來說是最糟的情況。

設計簡短、有邏輯且適當的文案

剛才的例子可以說是因不適當的文案而造成的:「文字bug」。在 UI 設計的過程中,往往容易忽視文案的設計,若是能夠注意幾個重點,「文字bug」是能夠避免的。

我們再看一次最初的警告框:

alert_01

 

這個警告框的說明文字並不恰當,並且選項的按鈕用語也是錯誤的。

為什麼都不對呢?首先,在說明文字中直接使用「取消」這樣的字眼並不好,因為「取消」這個詞經常用於表示否定意涵的按鈕上,應該避免使用在問句中,以免造成混亂。另外,按鈕的文字應該要能對應說明文字要求的動詞。在前面的例子中使用的「是」、「否」不是動詞,使用者很難想像按下按鈕後的結果是什麼。為了理解意思所需的時間會比以直接以動詞表示(例如「刪除」、「捨棄」)的按鈕還要久。

將「是」、「否」這種沒有邏輯性的文字用於按鈕並不適當。具有否定意涵的動作名稱,請盡可能地統一稱作「取消」。在各作業系統中(iOS、macOS等),「取消」也是用來表示否定意涵的統一用詞。至於具有同意意涵的按鈕,若是使用「好」這個字在語境上讀起來不會覺得奇怪的話,則可以放心使用;需要更具體地傳達意思的話,將「能夠對應說明文字內容的動詞」直接用於按鈕的文字是最好的。

簡潔地敘述說明文字

在說明文字中,盡量不要頻繁地使用太過禮貌但不直接的句子。例如剛才的例子中「確定要~嗎?」的問句,從使用情境來看,決定要捨棄編輯中的內容的是使用者自己,因此我們可把說明文字再縮短成「要~嗎?」的形式。

使用者並不是想要閱讀文章,而是想要盡快地獲得自己想要的內容,太拐彎抹角的說明只會讓使用者跟內容之間的距離變得更遠。

看過上面這些討論,我們可將這個警告框的說明文字中的「確定要取消編輯中的內容嗎?」改寫成「要捨棄編輯中的內容嗎?」

alert_04

讀者覺得如何呢?雖然跟最初的警告框比起來已變得比較好懂了,但似乎還有改善的空間。

考慮到破壞性操作

在警告框上的同意操作「捨棄」同時也是破壞性操作,因此我們將它的按鈕樣式改成 Destructive Style(紅色的文字)

如此一來就成為下圖這樣:

alert_05

因為「捨棄」除了是破壞性操作,在這個說明的語境中也具有同意的意思,我們遵照 HIG(Human Interface Guideline)將它放在右邊,表示不同意的「取消」則放在左邊。(在舊版的iOS HIG中,規定若是具有破壞性操作的按鈕,應該放在左邊,而取消則放在右邊,但在 iOS 10中只規定將使用者最有可能選擇的動作放在右邊。因此,像是在主畫面刪除 App 時會出現的警告框,也像上圖一樣把取消放在左邊,並把套用了Destructive Style 的破壞性操作放在右邊。)

alert_06

看起來很像一回事了吧?不過其實還有一個大問題。

Action Sheet 的功能

上面的警告框看起來似乎很完美了,但其實一開始使用警告框可能就是不對的。警告框是在使用者不經意觸發事件(錯誤等)時,用來詢問使用者的判斷的一種 Modal View(模態視圖)。考慮到這點後,這次的內容「捨棄編輯中的內容」並不符合這種情境。這個警告框是因為使用者主動地按下關閉按鈕才出現的,不能說是「使用者不經意觸發的事件」。

在這裡,Action Sheet 登場了。Action Sheet 也是一種對話框,它能夠提供兩種以上的操作選項,適合在使用者主動操作的情境中用來詢問是否要刪除內容。另外,即使適合使用警告框的情境,若是選項很多的話,也可以考慮改用 Action Sheet。

在 Action Sheet 中,一定至少有一個同等於取消的按鈕,因此選項包含了取消按鈕後,總是有兩個以上。使用者隨時都有中斷即將執行的動作的權力。

alert_07

是不是看起來更像一回事了呢。

考慮 Action Sheet 的按鈕配置

在剛才完成的 Action Sheet 中,進一步詢問使用者是否要儲存內容似乎也不錯。因此我們需要增加一個按鈕,如下面的表格,我們有兩種增加的方式:

alert_08

為了知道將「捨棄」按鈕放在上面比較好,還是下面比較好,我們參考 Apple 的 Mail、Twitter、Facebbok 的例子來比較看看。如下面的表格:

alert_09

Apple 的 Mail 與 Twitter 都將刪除(破壞性操作)放在離取消最遠的位置(同時也是離手指最遠的位置)。然而,Facebook 則相當不同,除了互換了儲存與刪除的位置,按鈕文字也不是「取消」而是「返回」。

雖然不清楚為什麼 Facbook 要這麼做,但一般來說,這種具有刪除與儲存選項的 Action Sheet,按照 Apple 的做法是比較正確的。取消按鈕也不要採用自創的「Go Back」,而是乖乖使用「取消」比較安全。我在看到 Facebook 的這個 Action Sheet 時,覺得不太對勁而稍微思考了一下,造成這種「不對勁」的感覺的原因,其實就是因為採用與標準的 Mail 以及 Twitter不同的按鈕配置,特別是在關係到「刪除」這種危險的動作時,實在不得不謹慎思考。

經過以上的討論,這次 Action Sheet 的設計,A才是正確答案。當然定義 App 本身的設計語言並且展現出獨特的部分也很重要,但首先更應該遵照系統平台的設計語言。

alert_10

思考沒有選項時,警告框的按鈕文字

alert_11

有的時候警告框只是用來傳達訊息,比如在說明新功能的時候,會用到只有一個按鈕的警告框。我們可想想在這種時候該如何設計按鈕的文字。一般來說,使用「OK(好)」雖然沒有問題,但在不同的語境中也有可能需要改成其他文字。

另外,只有一個按鈕的時候,將按鈕設定為預設的樣式(粗體字)會比較好。

避免針對警告框本身的動作

alert_12

請避免在按鈕上使用「關閉」或「返回」等用來表示跳出警告框意思的文字。

讀者可仔細想想「關閉」、「返回」所代表的語境,都是指涉「警告框」這個對象。用句子描述的話其實就是「關閉警告框」、「關閉警告框,並返回到之前的狀態」的意思。但其實「關閉警告框」這件事是理所當然的,沒有必要特別提供一個「關閉警告框」的選項給使用者去按。不管選項是代表同意或不同意的按鈕,只要按下就一定會關閉警告框,因此提供說明文字來說明按下按鈕後的結果是比較適當的。

如果想要在按鈕上使用「關閉」、「返回」等文字的話,請改用「OK(好)」就可以了。大部分的情況下使用「OK(好)」都不會有問題。

不要頻繁地使用對話框

對話框是在使用者進行操作時強行介入的一種「模式」。在 App 中盡量不要使用警告框,也不要毫不思考地使用對話框。例如在 App 開啟時跳出的「新消息」警告框,或者只是告知使用者操作的結果的警告框等,都應該避免使用。

結論

若是需要在 App 中使用對話框時,請注意以下要點來設計:

注意文字是否簡潔易懂並具一致性

  • 避免使用像是「取消的取消」這樣的雙重否定表現。尊重在作業系統中使用的文字表現,並注意不要偏離。「取消」是在系統中經常用於表示對於問句的否定,如同「保留字」一般的詞,請不要在其他地方使用它。
  • 在按鈕的文字上,建議使用能夠讓使用者預測到結果的動詞
  • 想要在警告框中加入標題以外的補充文字時,請將文字寫在 messageLabel(內文)中而不是 titleLabel(標題)。

遵守作業系統的規範

  • 在 iOS 與 macOS 中,有「將表示同意的動作放在右邊,表示不同意的動作放在左邊」的定義,請遵守這個資訊的排列規則。但注意在 Windows 或者舊版的 Android 中,這個規則剛好是反過來的。
  • 在 iOS 中,也有「請在破壞性操作的按鈕上使用 Destructive Style(紅色文字)」的規則,若使用了會執行刪除等操作的按鈕,請考慮使用 Destructive Style。
  • 在使用者主動選擇行動時,使用 Action Sheet 而不是警告框。

主角是使用者與內容

  • 不只是對話框,所有的使用者介面都不應該是主角。介面應該是連接使用者與內容之間的橋樑,並且要盡量保持透明,不干擾使用者。
  • 避免讓使用者意識到「關閉對話框」這個行為。在使用者主動採取行動的同時,順便也關閉警告框才是正確的,而不是讓使用者去關閉警告框。

不要頻繁地使用

  • 避免什麼訊息都用警告框表示。無論是跟 App 有關的新訊息,成功收藏內容時的通知,開啟 App 時的新功能介紹等等,在思考使用者的核心體驗之後,再考慮是否真的需要。
  • 但在發生系統障礙、連線錯誤等無法預期的嚴重情況時,則可使用警告框。

 

本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知

訂閱設計大舌頭

隨時關注第一手 UX、UI、科技、設計新知

Facebook
LinkedIn
Telegram
Twitter