你是不是覺得設計指導方針是多此一舉？
別傻了！不遵守它，設計出來的介面不是醜就是難用。
想知道為什麼？繼續看下去吧！
強調再強調，一定要先看過 Guideline 後再來做介面設計，卻被人嗤之以鼻，說不用看一樣可以產出啊幹嘛要花這種時間。
- 如果不是你的產品太簡單、就是都用內建元素或抄襲湊合了事。
- 你同事人太好，幫忙擦屁股了。
- 你同事程度跟你一樣，搞不清楚狀況。
別說很多 UI 高手們也老是跳脫 Guideline 設計啊，他們哪位不是對 Guideline 熟到可以朗朗上口到幾乎可以報頁碼的？不懂 Guideline 的就只能當美工用，連視覺設計都稱不上。
易用性
人家說情、理、法，法律是道德的最後底限，只要依法行事、頂多被嫌冷血，道德上仍然站得住腳。
我認為 Guideline 也一樣，最優良的介面設計會顧及到使用者的情感、次一點的會用理論（或數據）去實證易用性，最後才是 Guideline，它是介面設計的最後底限。
基本照 Guideline 設計，就算長得醜也不至於很難用。十大易用性原則 中至少就有 3 點和 Guideline 有關。
一致性和標準 Consistency and standards
使用者不應該猜測不同的字彙、狀態、動作是不是代表同一件事。
比如使用者已經習慣用手指點擊 Table View 進入下一頁，在 List 上左右滑動會出現刪除控件，就別把使用滑鼠的習慣硬套到手持裝置上，像是點一下是選中、快速連點兩下是開啟某項程式…包準沒人搞得懂這款 App 要怎麼操作。
（Interactivity and Feedback
）
預防錯誤 Error prevention
比起提供使用者明確易懂的錯誤訊息，更重要的是如何防止使用者發生錯誤。
防止錯誤有很大一部份可以靠照「使用者的習性做設計」來迴避。
Guideline 就是個系統性、有條理、已經整理好的「使用者習性」。試想使用者老是按錯，會覺得是自己的操作問題還是這個 App 有問題？老是讓自己操作不順的 App 是否會降低信賴感？
辨識而非記憶 Recognition rather than recall
盡量減少使用者需要記憶的事情、行動以及可見的選項。
繼承上一點，如果非得要使用這個 App 操作不可，是否就得記住這個 App 特別（難用）的地方？大部份的情況下讓人有感的介面通常不會是個好介面，使用者在流暢操作下的介面往往一點感覺也沒有，等到卡住或不知怎麼使用時、介面易用性的問題就會冒出來。
所以我一直覺得易用性跟保險套之間有很大的共通點：越無感越好。
雖不至於一有狀況就是鬧出人命，但對介面有感通常常是易用性問題大條了的時候…
確保團隊合作順利
扣掉校長兼掃地撞鐘那樣子的分工，一個專案最最少也會有 PM、UI/UX、RD 三個人，表示一個專案會被切成三人份、各自有各自負責處理的專長範圍，必須討論溝通交流結合三人之力才能完成這份專案。
只要是溝通就一定會有誤差，這個誤差就是成本，無論是時間或是人力。
統一口徑是很重要的事，Guideline 能確保你們談論的是同一件事。
PM：「這裡可以加一下點點點嗎？」
UI：「什麼點點點？更多的那個點點點？」
PM：「就是會放在圖片下面那個點點點。」
RD：「拜託那個是 Page Control 好不好…」
每次聽到這種對話，我想到 PowerPoint「強而有力的一個小點兒」，乾脆把 Page Control 叫「強而有力的三個小點兒」算了。
RD 的時程通常是被壓縮得最慘、突發狀況和意外以及客戶亂加功能下最可憐的犧牲品，包含和搞不清楚狀況的 UI 合作都會成為他們內心的痛。
RD：「這三小？131x245 尺寸的 @2x.png？你出 1x 檔給我看看啊！」
（圖片尺寸沒有 0.5px 的，退件重做！）
RD：「App Store 上架要用的 icon 最好有 112px 這種尺寸啦！」
（退件重做！）
RD：「Navigation Bar 高度哪來 100px？」
（退件重做！）
PM：「大爺您別玩啦，時程來不及了…」
UI：「是 RD 看我不順眼一直退我件啊！」
iOS RD：「給這垃圾我是可以用喔？」
Android RD：「你圖忘了點 9-patch 了。」
UI：「9-patch？那是什麼？可以吃嗎？」
Android RD：「…把圖切好給我就好，剩下我自己處理。」
以上還是真人真事，一個專案結束換下一個…新 UI 補進來接手，繼續輪迴無限退件地獄。搞的 RD 人人自危，急著學 Photoshop 怎麼修圖。
建立 Guideline
剛剛提到的都只是「跟隨」一份現有的 Guideline，公司若開發自有產品，就會需要自己的 Guideline。
什麼色碼、尺寸、字體字級、間距…這都還可以算是 VI 的範圍。
如果加上「策略」面的話…好吧先不提這麼抽象的，來講講為什麼要建立 Guideline 好了。
它能確保不管是誰接手都能有相同的產出，而不至於換個人處理就換了個長相。
也可以把它當成系統規格書、屬於文件的一種，條列式分章節，明確告訴你什麼可以做、什麼不能做、某種特定情況下該怎麼處理。
書諸圖文要學習要教育總是比較省成本、上手快。
不能老靠師徒純粹口耳相傳吧？萬一中途有人離職或出意外怎麼了，這門技藝不就失傳？
「你為什麼要這樣做？有什麼理由嗎？」
「我不知道耶，就、前面的人這樣做啊。」
恭喜你又跳入一個坑裡，這真是個仰頭無語問蒼天的好時機。
補充說明：讓大家好做事
通常 Guideline 裡有的，就表示 RD 有內建元素可以套，不用自己硬刻，就算拿別人寫好的套件模組、也是要修改一下才能用，多少會有 bug 。
用內建的原生控件製作的 App 通常 Bug 會比較少，不只 PM 溝通方便、UI製作快速、RD Code 也好寫、QA 測試時 Bug 少他也省事。
所以 Guideline 重不重要？
當然重要啊！
人力就是成本、時間就是金錢，UX 沒做好會扯多少人下水、多耗多少成本、多燒多少錢啊～
