視覺設計 與 UI 設計 邏輯相違背時，該如何取捨？

文章節錄自：Medium
作者：Ani Hsieh

台北客家主視覺新突破，及為何與UI產生脈絡衝突？

本文除了一起欣賞2017台北客家主視覺外，也用UIUX的角度分析：『當平面設計和使用者介面的習慣產生衝突時，設計師該如何做取捨呢？』

『你係不係客家人？ (你是不是客家人？)

            後生人，擎手喊有！(年輕人舉手達有！) 』

2017年，老師與義民嘉年節的第三次合作。和以往最不同的是此次加入了問答式的標語，增加了互動性和號召力。

這次2017的海報設計出自台灣設計師李根在老師之手，這已經是老師第三次和臺北客家義民節合作。標語結合了客家語，既有文化基底又充滿現代感。

老師說他希望藉此設計，激發台北年輕族群的興趣，透過現場打卡，網路分享圖片等方式，勇敢告訴別人自己是客家人或是支持客家文化！

一個成功簡報的結尾，通常有強而有力的Call to action：清楚表達講師訴求，讓聽眾族群得以為此改變思維、採取實際行動。這次2017客家的主視覺，我認為有相同的力度存在。

過往油桐花的主視覺大氾濫，是當時的設計師不想新梗？還是出於大環境造成的無奈？
以往相關單位可能為了促進客家觀光，大力行銷油桐花，久而久之社會大眾便經常將花和花布的『鮮豔紅色』，和客家文化做很直覺強烈的連結。因此不難看出以前台北義民嘉年華的活動主視覺：海報及社群Banner設計，大多以紅金搭配或油桐花為主。

當時鎖定的客群可能不是年輕族群、或是有許多不成文規定和無法改動的限制。在這些枷鎖下，設計師再有想法，也經常只能當手當腳。

但是，當社會結構或限制框架得以轉變，就會帶來巨大的創新和突破，2015後我想就是變革的時間點。

2015年，客家義民節視覺新突破，兩大原因：

1.更深入客家文化 2.拆解新元素加入設計。

1.更深入客家文化

2015年，李根在開始和台北客家義民節合作後，主視覺開始出現了以『藍染』為發想的深藍及淺水藍用色，打破以往紅花框架。

2.拆解新元素加入設計

早期客家人來台灣時，因祖籍地緣多習慣住在山地，因此到台定居後也多選擇依山傍水的居住環境。在2015的主視覺，設計上使用了客家人居住型態的意象，將其拆解成新的視覺元素：將山、水、衣服纖維、三合院的符號簡化後重新組合，相較於以往的花系列主視覺，多了不少現代感！

---

以UI設計師眼光探討：『當平面設計遇上介面設計出現脈絡衝突，該如何取捨呢？』
第三次主視覺我很喜歡，但裡頭我唯一一個比較有意見的部分，來自我身為UI介面設計師的思考脈絡：『在社群閱讀介面設計上的時候，使用者習慣從左側往右邊閱讀。』

所以依照標語『你係不係客家人? 後生人，擎手喊有！』的先後順序，從UX出發，若宣傳的平台是在手機介面上的話，我可能會偏向讓圖片『左側放？右邊放！』，不然會出現文字和圖片閱讀方向不同的情形。

現在的2017主視覺圖示意圖都是『左！右？』，包括市政府的模擬示意圖：台北市政府的扛棒也是從左側讀來，但是主視覺卻是相反的閱讀方向，我自己曾經一度誤解：以為標語是『後生人，擎手喊有！你係不係客家人? 』

但是若以寫作或春聯當出發點，直式閱讀是習慣從右側開始讀起的其實也沒有錯！我相信領域不同，一定有很多眉角不是身在其產業就不盡了解的。

平面和介面設計關注眉角大不同，與其『假設』誰的觀點正確，『有效的數據調查結果』或許才能洞察使用族群真正觀點。

上述意見，純屬以我『個人』觀點出發：在TA年輕族群已經相當習慣社群網路從左側閱讀的基礎上，我會投『左？右！』一票，但大家又是怎麼想的呢？

畢竟UIUX最忌諱的就是：介面設計師沒有透過真實的訪談和調查，就以『使用者』自居。

拋出這個疑問，一方面也是想透過此文章知道其他人的想法。如果大家看完這篇文章可以給我一些回饋：『左！右？』VS『左？右！』或其他意見回覆在文章或是我的FB發文底下，我會萬分感謝！（我的個人臉書本文連結）

為什麼介面設計中，使用者的個人頭像大多是圓形的？

越來越多的平台或 App 喜歡使用「圓形」作為使用者的「個人頭像」形狀。

是近期的設計風潮？還是大部分介面設計師的愛好？或有其他特別的原因呢？

「個人頭像」的定義與發展

隨著網路用戶族群快速增加，他們對於藉由平台與其他用戶互動的需求就越高，

也因此發展出許多可互動的平台類型，例如論壇、信箱、聊天室、部落格到社群等。

其中每個用戶都代表著一個獨特個體（無論是真實身份或虛擬角色），

這些個體會有相對應的資訊，以及代表個體的個人頭像。

而個人頭像通常是具個性化（用戶覺得能代表自我）的標誌，

大多以平面或 3D 圖像的方式呈現。

UI 上的個人頭像英文為 Profile Picture 或 Avatar ，

其中 Profile Picture 在字義上較容易理解，反倒是 Avatar，各位讀者可能會充滿問號，

因為大家對 Avatar 的印象應該都是阿凡達電影。

根據 techpedia 平台上的描述，Avatar 一詞出現於 1985 年，

由盧卡斯電影公司（Lucas Film）內發展線上角色扮演遊戲（Habitat）專案人員（Chip Morningstar & Joseph Romero）首先提出。

此詞源自於印度教對「聖人降臨（a descent of the Supreme Being）」的描述，

在英文裡有「化身 （incarnation）」或「代表（manifestation）」之義。

感受與認知

方形太無趣了。

大腦可較輕易的處理圓形內的訊息，減少認知的壓力。

相較於方形，圓形更柔性、有機、安全、順眼、現代與友善，也更能與他人情感交流。

更有關注的感覺，例如想到望遠鏡或放大鏡的視野。

大多照片的四周都是無意義的背景或訊息，圓形可以將其切除。

通常拍照會把「人」擺在中心，而圓形中心到四周距離都一致，可讓臉更突出。

視覺

視線在方形的焦點有 5 個（四個角 + 中心），而圓形只有一個（中心）。

圓潤的線條或角度，可讓視線自然的追隨與運動，不會像看到 90度角 而停頓下來。

在掃視的情況下，使用圓形可協助使用者辨識或區分是否為內容，

因為內容通常會置於用方型容器，例如文字、照片或專輯等。

其他

行動裝置普及後，因圓形與手指按壓在螢幕上的形狀類似，而被廣泛的使用。

其實人類早就有這樣的應用，例如將人物應用於圓形硬幣與圓形藝術畫中。

只是一個設計的風潮，剛好流行到”圓形”這個週期。

很多準則或模板都只提供圓形版本。

現在的 CSS3 技術讓圓角（圓形）輕易實現且各瀏覽器也幾乎都有支援。

作者 Anthony 於 UX movement 上提出了相關觀點

角度的邊緣，看起來較明顯

通常方形的銳利四角，因為對比（顏色或形狀）的關係，

在視覺上會更明顯，造成干擾。使用圓形並無此問題，所以更可強調重點 –「臉部」。

方形對角線較長

方形的對角線比邊緣還長，用戶目光易延伸出去；

圓形半徑長皆一致，用戶可花更少時間在理解內容，眼球也較不需要移動。

圓型用於非人物圖片，效果也是一樣的嗎？

雖然使用圓形的個人頭像可排除不相關的背景，更聚焦於人臉上，

但非人物的圖片（風景或食物等）也有同樣效果嗎？

Anthony 認為不一定，因為可能因此失去了該圖片要傳達的資訊，如景深或細節等。

上面已整理了許多專家的觀點，大部分是相當的認同的。

不過，也有一些觀點是以上未提到的，補充給大家做參考，如下：

較強的設計感

圓形的個人頭像，能讓介面傳遞較強的設計感。

不過這點會受設計師應用的手法，或使用者的主觀感受影響。

此外，平台無法限制使用者上傳圖片的品質，若上傳圖片的品質、構圖或美感較差，

將其套用在圓形的遮罩裡，介面的設計感會比方形的好。

高度親和力

就如同人與人的交際，在初次見面時，

會認為帶有嚴肅表情的人較難相處，而微笑滿面的人可馬上聊起來。

為什麼會有這種先入為主的觀念呢？這就是「親和力」高低層度的差異所致。

而曲線與圓在人們的印象中，就是親和力的象徵。

若介面上使用圓形的元素（個人頭像等），使用者可能會產生，

此產品學習曲線較低的印象。

雖然矩形可讓空間利用最佳化，但應用圓形又可多一點留白空間

若不考慮使用者體驗與美學，將不同的內容以方形排列，將最具有效能，

但這樣的產品絕對不會受到用戶歡迎的。

因此，設計師都應了解留白帶來的效益，

例如降低視覺負擔、增加閱讀性、區隔不同內容與更具美感等。

適當的留白對產品來說相當重要，同時也考驗設計師的基礎訓練是否扎實。

就個人圖像而言，同樣尺寸下，圓形又能比方形多一些留白空間（在四角處），

除了增加與其他內容的區隔性外，也能讓介面帶點趣味性。

使用圓形個人頭像的小撇步

css 怎麼做？該注意什麼？

只需要針對個人頭像的 HTML tag or class 寫一行 border-radius: 100%; 的 css 屬性就可以達到！

給予使用者上傳圖片的建議

不知道大家有沒有這樣的經驗，就是當你挑好圖片並上傳後，

發現圓形的形狀外框遮住了許多重點（例如臉的一角），效果不如預期。

其實，設計師可以在上傳圖片的介面上，提供給使用者一些建議。

例如，畫出一個人臉可在圓形裡完整呈現的區域，這樣使用者就會比對自己的圖片，

並挑選較符合者；或是提醒圖片上有字的話，建議的大小為何（可看的清楚）；

提示不能使用非法圖片等。

提供多種預設圖片，及更完善的圖片編輯器

有些使用者手上剛好沒有適合的圖片，或認為不重要，可能就不會設定個人頭像了。

不過，平台若是希望呈現出多種角色互動的氛圍（如社群網站），

或有協作辨識的需求（如 trello）。

設計師可在設定流程的頁面上，

提供多種預設個人頭像供使用者快速選擇（如多款顏色或企業識別的變形應用），

或設計某種自動機制（如帳號的第一個字母）。

另外，利用第三方社群登入方式，也能自動載入在該平台上傳的頭像，

是個對使用者較便捷的方式。

再者，若能提供完善的圖片編輯器，

也能吸引使用者做出更符合自我形象與品質更好的頭像，

例如挑選濾鏡、色相與明度調整等。

不過，圖片編輯器的有無，應該要取決於平台服務的本質。

同尺寸下，圓形看起來比方形小

某一圓形的直徑與正方形的邊長一致，

若將兩者放在一起，視覺上會認為圓形的較小（如下圖左）。

如果排版有將兩者放在一起的需要，可將圓形放大一點，以達到視覺的平衡（如下圖右）。

使用 gif

有越來越多的平台允許使用者放上 Gif 檔作為個人頭像，

以呈現動態效果，這讓使用者更可彰顯其特色或品味。

世大運的網站和行動應用你給幾分？

行動應用的UI/UX設計，是近年智慧型手機發展下才誕生的學問。我們不要求政府學習公用元件、不同系統使用者（iOS/Android）的使用習慣與兩大平台的設計準則（Design Guide） ，而希望政府把手上的資訊放出來，讓民間取用。

前陣子我才寫了數位政府喊得震天作響，但有些網站還是做得很差！最近因為想要看荷蘭小鮮肉，喔不，是支持世大運，所以用手機上網購票，卻得到一個痛苦的經驗：沒法看到當天賽程。不論是用瀏覽器查網站的手機版，還是裝行動應用 （APP)都沒辦法。

三個次網域各自為政

既然在捷運通勤時沒法購票，只好回家打開電腦看官網。雖然主網域在2017.taipei，但官網、活動跟合作的購票網站卻分開。 只是互相放個連結，此種設計，讓人感覺到權責單位不同。

要購票得先在官網裡頭查好賽程，比對賽程場地的縮寫，例如想看8月25日的中華台北對賽爾維亞的籃球比賽（如圖一）。

圖一

2017台北世大運官網

滑鼠要點到場地的英文縮寫HMG，游標才會顯示地點在Hsinchu Municipal Gymnasium，點下去看場地縮寫表，才會顯示出地點在新竹市立體育館（如圖二）。什麼？你看不懂英文！請你一定要看得懂隊伍和場地的英文名稱，不然自己去google吧！

圖二

2017台北世大運官網

購票時怎麼辦？一般購票的習慣，就是按下場次付費，但世大運的官網和購票系統，兩者分開，因此要點上方圓形的Ticket才能前往購票網站。

購票網站也是用表格呈現場次和地點，千萬不要眼花按錯（圖三）。但至少頁面的中文介面是中文，英文介面是英文，行動版購票還算順暢。

圖三

2017台北世大運購票系統

App其實就是包起來的網頁，但比一般包起來的網頁還差。電腦版看得見隊伍名稱，但行動版網頁（圖四）與App（圖五）連隊伍名稱都看不見。

圖四

2017台北世大運行動版網頁

圖五

2017台北世大運APP

行動版網頁也有很多不及格之處，例如常需要把表格拖來拉去，若看不清楚，使用者還要放大（如圖六）。

圖六

2017台北世大運行動版網頁

各國選手會怎麼看台灣的軟體科技

我不想問去年就開始準備的世大運，為什麼會讓使用者的行動體驗這麼差？更不想問為什麼不做原生App？這些距離太遠的問題。

世大運有來自全球131個國家或地區代表隊、7,639名運動員、3,758職員，共計11,397人來到台北，不僅能增加國際交流，也能落實體育文化，這種極富教育意義的盛會，還可讓世界看見台北，是宣傳台灣觀光的一大機會。

結果選手來台北，下載App後就會發現「看不到賽程」，難道選手還要帶著筆電才能看賽事嗎？

真希望選手不知道這個App，整天跟著教練和隊友練習和參賽就好，不然台灣這樣的「軟實力」怎麼面對國際的眼光？

還好，台灣硬體廠商做了補強，宏碁、聯發科與悠遊卡聯手贈送1.3萬只「MIT」智慧手錶給選手，希望可以掩飾世大運行動應用的缺陷。

未來要怎麼強化？閃開讓專業的來

那未來要怎麼強化？國家發展委員會出了一份『行政院及所屬各機關行動化服務發展作業原則』，其中有一條至理名言可供地方政府參考，「各機關開發行動化服務前，宜優先評估將政府資訊開放民間加值創新應用之可行性；其經評估屬應由機關開發者，再由機關自行或委外開發。」

為什麼要優先評估民間加值創新應用的可行性？

因為民間專業人才很多，黑客松（Hackathon）裡面也有很多神級的工程師團隊，能在幾十個小時內做出高水準應用。

政府除非特別成立「行動應用開發」這種跨部會顧問組織，否則政府的知識和經驗，比不上專門開發的民間公司。政府開出來的需求常包山包海，但給的預算又有限，招標之下就砍到了品質，尤其世大運這類短期使用的軟體，更囿於時間限制，草草驗收，結果使用者用得辛苦，政府發包得痛苦。

行動應用的UI/UX設計，是近年智慧型手機發展下才誕生的學問，我們不要求政府要亦步亦趨地學習公用元件、不同系統使用者（iOS/Android）的使用習慣與兩大平台的設計準則（Design Guide） ，而希望政府把手上的資訊放出來，讓民間取用。

記取房地產實價登錄的教訓

近年最有名的例子，就是房地產實價登錄。當時政府網站常當掉，但不動產業者，需要這些資料，於是去爬資料，結果網站更常被爬掛。

同時，民間工程師的實價登錄地圖做得更棒，民間的資料怎麼來？全民實價登錄地圖的成功，竟是人民的悲哀。這篇文章說得明白。

政府的不開放資訊，浪費了兩萬一千個「資深工程師」的志願工時。上線兩年輿論紛擾，最後內政部終於把資料開放出來。

世大運也應記取教訓，把力氣花在怎麼公布資料。政府應該早早公布賽程API，初期放些假資料，讓想參與的民間企業或個人嘗試做App，然後針對合格的成品，串上真資料，做台北市政府的官方推薦，並且將門票利潤，拆分給這些導購的優秀軟體。若如此做，現在我們應該會看到更驚豔的行動應用。

文末，一姊還是在世大運電腦網頁完成購票，雖然沒買到中華台北參賽的場次（令人欣慰），但帶著家中小朋友去看比賽，還是一件寓教於樂的事，推薦給還沒買票的人。

《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。

（觀點文章呈現多元意見，不代表《數位時代》的立場。）

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

作者 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 時的新功能介紹等等，在思考使用者的核心體驗之後，再考慮是否真的需要。
• 但在發生系統障礙、連線錯誤等無法預期的嚴重情況時，則可使用警告框。

文章轉自：設計大舌頭
https://designtongue.me/%E5%B0%8D%E8%A9%B1%E6%A1%86-%E8%A8%AD%E8%A8%88%E5%A4%A7%E6%9C%89%E5%AD%B8%E5%95%8F/